Docker & Kubernetes: Ship with Confidence

Final assessment

Twelve questions across the whole course. Score 70% or more to pass and unlock your certificate. You can retake it as often as you like.

Finish every lesson to earn the certificate — you can take the assessment any time.

A Skylane engineer wants faster CI builds for notes-api. Builds run on fresh runners with an empty Docker cache, and the Dockerfile is already ordered correctly. What helps most?

Switching npm ci to npm install.
Exporting and importing the build cache with --cache-to and --cache-from (for example to a registry).
Building with --no-cache for consistency.
Adding more RUN steps so there are more cache points.

Which Dockerfile line puts a credential at risk even though it’s deleted later in the same build?

RUN --mount=type=secret,id=npmrc,target=/root/.npmrc npm ci
COPY package.json package-lock.json ./
USER node
COPY .npmrc . followed later by RUN rm .npmrc

notes-api’s image runs as USER node, and the Deployment’s securityContext sets runAsNonRoot: true. Pods fail with CreateContainerConfigError. What’s the cleanest fix?

Set a numeric user, either USER 1000 in the Dockerfile or runAsUser: 1000 in the securityContext, so the kubelet can verify it isn’t root.
Remove runAsNonRoot from the securityContext.
Switch the image back to running as root.
Add allowPrivilegeEscalation: true.

A Compose stack starts reliably on your laptop, but in CI the integration tests sometimes run before the API is ready. Which change fixes it without guesswork?

Add sleep 30 before the tests.
Use restart: always on the API.
Give the API and database healthchecks and start the stack with docker compose up -d --wait.
Publish the database port so tests can poll it.

You inherit a Deployment with no readiness probe and default rolling-update settings. A release with a broken database URL goes out. What happens?

The rollout stalls and the old Pods keep serving.
Kubernetes detects the bad URL and rejects the release.
Only one Pod is replaced, because of maxSurge.
New Pods are marked ready as soon as their containers start, so the rollout replaces every working Pod with a failing one.

notes-api has CPU request 500m and no CPU limit, memory request and limit 512Mi. Under a traffic spike its CPU usage reaches 1.5 cores on a node with idle capacity. What happens?

It’s OOM-killed for exceeding its request.
It uses the idle CPU, since there’s no CPU limit to throttle it; its request still guarantees 500m under contention.
It’s throttled to 500m.
The scheduler moves it to a bigger node.

Which manifest is valid for current Kubernetes?

apiVersion: extensions/v1beta1 with kind: Deployment
apiVersion: autoscaling/v1 with an HPA that uses metrics and behavior
apiVersion: networking.k8s.io/v1beta1 with kind: Ingress
apiVersion: apps/v1 with kind: Deployment

notes-api 1.5.0 added a column, and its code writes to both the old and new columns. 1.5.0 has a bug, so you run kubectl rollout undo. Why is this rollback safe?

Because rollout undo restores a database snapshot.
Because the schema change was additive, 1.4.0 still finds everything it expects.
Because Postgres ignores unknown columns in UPDATE statements.
Because rollbacks are always safe in Kubernetes.

notes-api’s HPA targets 60% CPU utilization with a CPU request of 200m. Four Pods average 240m each. Roughly how many replicas will the HPA want?

4, because the HPA only scales when usage exceeds the request.
5
8
2, because it averages the request and the usage.

The ingress-nginx controller your cluster used is retired and receives no security fixes. What’s the recommended direction for new HTTP routing setups?

Expose every service with its own NodePort.
Keep the retired controller; it will be maintained by Kubernetes core.
Replace Ingress with a LoadBalancer Service per app.
Gateway API: a Gateway owned by the platform team and HTTPRoutes owned by each app team.

A notes-api Pod shows CrashLoopBackOff and Last State: Terminated, Exit Code: 137. kubectl logs --previous shows normal request logs, then nothing. What’s the likely cause and fix?

The container exceeded its memory limit and was OOM-killed; check describe for OOMKilled, then raise the limit or fix the leak and cap the V8 heap.
A JavaScript exception crashed the process.
The image can’t be pulled.
The readiness probe failed.

Which combination gives notes-api zero-downtime deploys?

Recreate strategy plus a liveness probe on /readyz.
No probes, maxUnavailable: 25%, and a high terminationGracePeriodSeconds.
A readiness probe, maxUnavailable: 0, a short preStop sleep, and a SIGTERM handler that drains in-flight requests.
replicas: 1 with kubectl rollout restart after every change.

12 questions unanswered