Deployment capstone: multiple-choice review
Cross-track synthesis MCQs over the whole deployment chain — image digests, probes, rollout-vs-migration, L7 draining, secrets, and IaC drift — each framed as a release decision under load.
Six questions, each spanning two or more stages of the deployment chain. None tests a single definition — every one is a seam where two correct stages compose into an outage, and your job is to name the contract that broke.
Confirm you can reason across the whole track at once: how the image, registry, k8s objects, rollout strategy, load balancer, secrets, and IaC compose into one release — and where the emergent failures live.
A team pushes every build as registry.example.com/api:latest and the Deployment pins image: api:latest. Rollouts mostly work, but twice now a node that recreated a pod served a months-old build. What single change fixes the class of bug, and why?
A rolling update is configured as below and a new release is rolled out. The manifest applies cleanly and the rollout reports success in 40s, but clients see a burst of 502s for ~2 minutes. Where is the seam?\n\n```yaml\nstrategy:\n rollingUpdate:\n maxUnavailable: 0\n maxSurge: 1\ntemplate:\n spec:\n containers:\n - name: api\n image: api@sha256:abc\n # no readinessProbe\n```
You ship a column rename as one migration bundled into the same blue-green release that flips the LB to green. Green serves fine, then throws an unrelated error and you flip back to blue — and blue now 500s on every request. Why did two reversible-looking stages produce a non-recoverable state?
During every deploy, a small fraction of in-flight requests are severed mid-response right as old pods terminate, even though readiness and rollout are correct. The service sits behind an L4 load balancer. What is the highest-leverage fix?
A reviewer flags that the production database password is set in the Dockerfile so the image is self-contained. The team argues the registry is private, so it is fine. What is the correct objection?
An incident postmortem finds the failing service had a hand-edited replica count and an env var that no IaC config declares — someone kubectl-edited it during a previous fire. The next terraform apply will revert both. What does this reveal, and what is the durable fix?
The through-line across the track is one composed object: an immutable digest fixes which artifact runs, the readiness probe makes “ready” mean “serving,” expand-contract keeps the rollout strategy and the migration N-1 compatible, an L7 drain plus SIGTERM handling protect in-flight requests across the cutover, runtime secret injection keeps credentials rotatable and out of image history, and IaC as the single source of truth kills drift. Every wrong answer here was a real outage shipped by a team whose individual stages were each fine — the failure lived in the seam. Now when you review a release plan, scan the column of seams first: which contract between stages is written down, tested, or enforced — and which is assumed.
Something unclear?
Ask a question about this lesson. Questions are anonymous and go straight to the author to make the lesson better.