Deployment & Infra
Deployment capstone: multiple-choice review
Crux 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.
Your altitude — climbing toward senior
ZeroJuniorMiddleSenior
You are at senior altitude — in orbitSix 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.
Goal
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.
Quiz
Completed
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?
Heads-up Always makes the staleness worse, not better — it guarantees a rescheduled pod fetches whatever :latest points to right now, which may be a newer or older build than the rest of the ReplicaSet. The fix is an immutable reference, not a more aggressive pull.
Heads-up A probe checks whether a pod is serving, not whether it is running the right code — a months-old build can pass /healthz/ready perfectly. The seam here is the registry tag's mutability, not the readiness contract.
Heads-up Layer caching speeds up pulls; it has nothing to do with which build a tag resolves to. The bug is identity (which artifact), not performance (how fast it arrives).
Quiz
Completed
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```
Heads-up maxUnavailable: 0 keeps capacity at or above desired during the roll — it is the safe setting. It does not route traffic to unready pods; the absence of a probe does.
Heads-up A slow pull delays a pod from starting at all; it does not produce a reported success followed by transient 502s from pods k8s already added to the Service. The missing readiness gate does that.
Heads-up maxSurge: 1 adds a new pod before retiring an old one, so capacity never dips. Throughput was not the problem — traffic reached pods that were alive but not yet serving.
Quiz
Completed
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?
Heads-up Sharing one database across blue and green is normal and expected. The failure is the shared schema being incompatible with the version you rolled back to — not a connection-routing mistake.
Heads-up Reversibility is exactly what blue-green promises — flip the LB back instantly. The promise held; what broke it was composing the reversible flip with an irreversible DROP COLUMN.
Heads-up A canary watches metrics on the new version, but the destructive migration still breaks the old code on rollback regardless of rollout style. The real fix is expand-contract, not a different traffic-shift strategy.
Quiz
Completed
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?
Heads-up Surge controls how fast new capacity appears; it does nothing for requests already in flight on a pod that is shutting down. Draining and SIGTERM handling are what protect in-flight work.
Heads-up That delays when new pods receive traffic on startup; the problem here is the shutdown side — requests killed when old pods go away — which draining, not startup delay, addresses.
Heads-up Recreate kills all old pods before starting new ones, causing full downtime — it makes availability worse and still severs whatever was in flight when the old pods died.
Quiz
Completed
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?
Heads-up Registry access control is one layer, but the secret is now permanently embedded in image history and in every node and cache that ever pulled it — un-rotatable and over-exposed. Build-time and runtime are different trust boundaries.
Heads-up They can (ENV/ARG), and that is precisely the trap — a build-time ARG or ENV secret is baked into the image. The objection is about the trust boundary, not a capability gap.
Heads-up base64 is encoding, not encryption — it is trivially reversible and adds zero protection. It is also still baked into the image, so it inherits every problem above.
Quiz
Completed
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?
Heads-up That abandons reproducibility entirely — the whole point of IaC is that the declared state is authoritative and recreatable. Letting manual edits win turns the cluster into an unrepeatable snowflake.
Heads-up Drift means your tested config and your live config differ silently — the next apply, node replacement, or scale event snaps reality back to the declared state and undoes the undocumented fix, often mid-incident.
Heads-up Importing the values into version-controlled IaC is right; continuing to make manual edits is the original sin. The fix is closing the out-of-band path, not legitimizing it.
Recap
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.