How to pass the Provyn Docker and Kubernetes assessment

What the assessment tests

The Docker/Kubernetes assessment is aimed at the engineer who needs to write Dockerfiles, debug containers, and configure workloads in a cluster — not the infrastructure team that stands up the cluster. Questions are practical: here is a Dockerfile, what is wrong with it? Here is a failing Pod, what is the most likely cause?

The highest-weighted area is Kubernetes primitives and their interaction. Know the difference between a Pod (the unit of scheduling), a Deployment (the unit of replicated Pods with rolling updates), and a Service (the unit of network access to a group of Pods).

Dockerfile best practices

Layer caching is the most tested Docker topic. COPY package.json and RUN npm install before COPY . so that the dependency install layer is cached and only re-runs when package.json changes. If you COPY . first, the install layer busts whenever any source file changes.

Multi-stage builds reduce final image size. Stage one installs build dependencies and compiles. Stage two is FROM a minimal base and copies only the compiled output. The assessment will ask you to identify a Dockerfile that should use multi-stage but doesn't, and what the consequence is (large image with build tools in production).

Kubernetes: Deployments and Services

A Deployment manages a ReplicaSet which manages Pods. When you update a Deployment, Kubernetes performs a rolling update by default: it brings up new Pods before terminating old ones, ensuring the service stays available. The assessment will ask about rollback — kubectl rollout undo deployment/<name>.

Services: ClusterIP for internal access, NodePort for external access via a static port on every node, LoadBalancer for cloud-managed external load balancing. Know which to use for an internal microservice (ClusterIP) versus a publicly accessible API (LoadBalancer).

Readiness vs liveness probes

A readiness probe tells Kubernetes when a Pod is ready to receive traffic. A failing readiness probe removes the Pod from the Service's endpoints — no more traffic. A liveness probe tells Kubernetes when a Pod should be restarted. A failing liveness probe triggers a restart.

Common mistake: configuring a liveness probe that fires during slow startup. If the app takes 60 seconds to start and the liveness probe starts checking at 10 seconds, the Pod restarts before it can start — crash loop. Fix: set initialDelaySeconds to longer than startup time, or use a startupProbe.

Three-day prep plan

Day one: run the practice assessment. Note the questions that involved Kubernetes networking — these are the hardest.

Day two: write a complete Dockerfile from scratch for a Node.js app: use multi-stage, pin the base image version, set NODE_ENV=production, run as a non-root user. Each of those choices has a rationale the assessment will test.

Day three: read the Kubernetes documentation for readiness and liveness probes. Write a Deployment YAML with both probes configured correctly for a slow-starting HTTP service.