Deployment & Infra
Rollout strategies: multiple-choice review
Crux Multiple-choice synthesis across the rollout unit — strategy tradeoffs, maxSurge/maxUnavailable, readiness probes, canary gating, and schema-safe rollback.
Your altitude — climbing toward senior
ZeroJuniorMiddleSenior
You are at senior altitude — in orbitSix questions that cut across the whole unit. Each mirrors a call you make during a real release — not a definition to recite, but a tradeoff to weigh with traffic on the line.
Goal
Confirm you can connect strategy choice, the rolling-update knobs, readiness gating, canary metric gates, and schema-safe rollback — the synthesis the overview lesson built toward.
Quiz
Completed
A payments API ships a risky refactor on Kubernetes. You have Prometheus dashboards, SLO alerts, and spare cluster capacity, and you want the smallest possible user impact if it goes wrong. Which strategy, and why?
Heads-up Recreate has maximum blast radius and guaranteed downtime: every user hits the new version at once with a service gap in between. It is for non-HA services or maintenance windows, not a high-availability payments API.
Heads-up Blue-green gives instant rollback but the flip exposes 100% of traffic the instant you cut over — a larger blast radius than canary, at double the resource cost. With good observability, canary's gated ramp catches the failure on 5%, not 100%.
Heads-up Observability is precisely what unlocks canary: the metric gate is worthless if you cannot read the canary slice. Good dashboards make canary the lower-risk choice here, not an irrelevant detail.
Quiz
Completed
A rolling update reports the Deployment as 'available' and every replica is up, yet ~30% of requests return 502s for the first few seconds after each pod rotates in. What is the root cause?
Heads-up maxSurge only controls extra capacity during the rollout; more pods do not cause 502s. The symptom — traffic hitting not-ready pods — points to a missing readiness gate, not surge sizing.
Heads-up Recreate would cause full downtime, not a partial 502 rate. The issue is traffic reaching half-booted pods, which a readiness probe prevents during a rolling update.
Heads-up maxUnavailable: 0 is the safe setting and causes no 502s — it only means no old pod is removed before its replacement is ready. The errors come from traffic hitting unready new pods.
Quiz
Completed
A team wants strict zero-downtime on a 4-replica Deployment that must never drop below full capacity. Which rolling-update config is correct, and what does it cost? ```yaml strategy: type: RollingUpdate rollingUpdate: maxSurge: 1 maxUnavailable: 0 ```
Heads-up It does not deadlock — maxSurge: 1 creates a new pod first, and only once it is ready does an old one terminate. The pair is the canonical zero-downtime config; it just rolls one pod at a time.
Heads-up The knobs guarantee capacity never drops, but without a real readiness probe Kubernetes still routes traffic to pods the moment they start. Zero-downtime needs maxUnavailable: 0 AND a readiness probe, not the knobs alone.
Heads-up The 25% defaults let a quarter of capacity be unavailable mid-rollout, which is not zero-downtime. Faster is not safer here — the team's requirement is never dropping below full capacity.
Quiz
Completed
You are running blue-green and want rollback to stay safe. Green's release renames a database column. What do you do?
Heads-up The app flips atomically but the database is shared and does not flip. Renaming breaks blue against the live schema, so flipping back crashes — the instant rollback is gone exactly when you need it.
Heads-up A restore is slow and loses every write made after the flip. Backward-compatible expand-contract changes keep both versions working without a destructive restore.
Heads-up Recreate trades the migration problem for guaranteed downtime, and a forward-incompatible schema still blocks rollback. Expand-contract solves the actual constraint: a schema both versions can read.
Quiz
Completed
A canary deploy ramps 5% then 25% then 50% with no metric gate — an engineer eyeballs the dashboard and promotes manually at each step. At 3am a release with a 4% error rate ramps all the way to 100%. What is the real failure?
Heads-up A smaller first step shrinks the initial blast radius but still ramps to 100% if nothing reads the metrics. The missing piece is the automated gate, not the step sizes.
Heads-up Blue-green exposes 100% of traffic on the flip — a larger blast radius. Canary is correct here; what failed is that it had no metric gate, the very thing that makes canary lower-risk.
Heads-up A 4% error rate on a production service is typically far over SLO and is exactly what a gate should catch. The point of canary is that a gate, not a tired human, decides whether to promote.
Quiz
Completed
You must choose a rollout for a service where two versions genuinely cannot coexist — an in-place change to a stateful singleton with no compatible intermediate schema. Capacity is tight and a brief maintenance window is acceptable. Which strategy, and what is the tradeoff you are accepting?
Heads-up Rolling update keeps both versions live simultaneously, which is exactly what this workload cannot tolerate. The default is not universal; the no-coexistence constraint rules it out.
Heads-up Canary also runs both versions at once to serve the split traffic, violating the no-coexistence constraint. Its blast-radius benefit is irrelevant when mixed versions corrupt state.
Heads-up During cutover both environments exist and blue-green doubles resource cost, which tight capacity rules out; expand-contract can't help when there is no compatible intermediate schema. Recreate's clean version swap fits the constraint.
Recap
The through-line is one decision: weigh blast radius (canary smallest, recreate total) against resource cost (blue-green doubles) against rollback speed (blue-green and canary near-instant, rolling backward, recreate a second downtime). Then the prerequisites that make any choice real — maxSurge/maxUnavailable plus a readiness probe for zero-downtime rolling, an automated metric gate for canary, and expand-contract migrations so rollback survives a schema change. Observability decides which strategy you can actually trust.