Rollout strategies: multiple-choice review
Multiple-choice synthesis across the rollout unit — strategy tradeoffs, maxSurge/maxUnavailable, readiness probes, canary gating, and schema-safe rollback.
Six 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.
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.
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?
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?
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 ```
You are running blue-green and want rollback to stay safe. Green's release renames a database column. What do you do?
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?
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?
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. Now when you face the next release decision, run the three-axis check before reaching for a default — blast radius, resource cost, rollback speed — and make sure the prerequisites are in place before the deploy goes out.
Something unclear?
Ask a question about this lesson. Questions are anonymous and go straight to the author to make the lesson better.