Milestone map
Milestone map
3 milestones
Containerise a real application
1 week (1 hr/day)
Write a Dockerfile for a real application you run. Keep the image small, with no secrets baked in. Use a multi-stage build and run as a non-root user. A clean image is the base everything else stands on.
Proof required
Link the repository with the Dockerfile, the image size, and a screenshot of the container running and serving a request.
What gets checked
- Multi-stage build with a small final image
- No secrets in the image or its layers
- Runs as a non-root user
Common mistakes
- Copying the whole repo including .env into the image
- A 2 GB image from a full OS base
- Running as root by default
Powstik Guide
A small, secure image of a real app.
Steps
- Add a .dockerignore before writing the Dockerfile.
- Build in one stage, copy only the output to a slim stage.
- Pass config through environment variables.
- Add a non-root USER line.
- Run it and hit one real endpoint.
Template
Image checklist [ ] .dockerignore excludes .env, .git, node_modules [ ] Multi-stage build [ ] Final image size: ___ MB [ ] Non-root USER [ ] Config from env vars [ ] Serves a real request
What gets sent back
- Secrets baked into the image.
- Running as root.
- No proof the container serves requests.
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Check .dockerignore and image layers for secrets
- Check the USER instruction
- Run the image locally
You'll sign in first, then come straight back here.
Deploy to Kubernetes with probes and autoscaling
2–3 weeks (1 hr/day)
Deploy the app to a Kubernetes cluster. Add readiness and liveness probes, resource requests and limits, and an autoscaler. Then generate load and watch it scale. Probes and autoscaling are what make it production-grade rather than just running.
Proof required
Link the manifests (or Helm chart) and submit a short recording or screenshots showing pods scaling up under load and back down after.
What gets checked
- Readiness and liveness probes that check real health
- Requests and limits set on every container
- Autoscaler shown scaling up and down under real load
Common mistakes
- Probes that always pass
- No resource requests, so autoscaling can't work
- Claiming autoscaling without showing it happen
Powstik Guide
A deployment that heals and scales itself.
Steps
- Start a local cluster with kind or minikube.
- Write Deployment and Service manifests.
- Add a readiness probe that checks dependencies.
- Set CPU requests, then add an autoscaler.
- Load-test and record the pod count changing.
Template
Scaling test log Load tool and settings: Time | Replicas | CPU % | Notes -----|----------|-------|------ Probe endpoints and what they check:
What gets sent back
- Probes that return 200 no matter what.
- No resource requests.
- No scaling evidence.
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Read the probe endpoints
- Check requests/limits
- Watch the scaling evidence
You'll sign in first, then come straight back here.
Survive a failure drill with a reviewer
1 week
Run a failure drill with an experienced platform engineer watching. Let them kill pods, break a dependency or push a bad config. Show how the system responds and how you recover.
Proof required
Submit drill notes (250+ words): reviewer background, each failure injected, what the cluster did, how you recovered, and one change you made afterwards.
What gets checked
- Reviewer runs or operates Kubernetes in production
- At least two different failures injected
- A concrete fix committed after the drill
Common mistakes
- Only testing a pod restart
- Pre-scripted failures you rehearsed
- No change after the drill
Powstik Guide
A failure drill with notes and a fix.
Steps
- Write down what you expect each failure to do.
- Let the reviewer choose what to break.
- Watch events and logs as it happens.
- Recover, then note what surprised you.
- Commit one change that makes it more resilient.
Template
| Failure injected | Expected | What happened | Recovery | |------------------|----------|---------------|----------| Review session log Date: Duration: Reviewer name: Reviewer role and experience: Challenge 1 (a failure scenario): What they asked: My answer: Challenge 2: What they asked: My answer: Change I made after the session:
What gets sent back
- A single pod restart only.
- Failures you rehearsed.
- No follow-up fix.
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Confirm the reviewer's production experience
- Check two distinct failures
- See the fix commit
You'll sign in first, then come straight back here.