Rollback must be near-instant after a bad release without rebuilding every server from scratch. Which strategy best supports that requirement?
Select an answer to reveal the explanation.
Short Explanation
When you need an undo button that works in seconds, keep the old stage warm and just flip the lights back — that is blue-green. Rebuilding every server from scratch is the long way home. Near-instant rollback without a full rebuild points straight at traffic-switch blue-green.
Full Explanation
Blue-green deployment best supports near-instant rollback because the prior healthy environment remains intact and traffic can be redirected back without rebuilding servers from scratch. For citizen-facing municipal releases, that traffic-switch rollback is the operational advantage when a bad build must be withdrawn quickly. In-place upgrade fails this requirement because reverting typically means reinstalling or reconfiguring packages on live hosts, which is slow and error-prone under pressure. Manual rebuild of all production VMs from golden images after each failed change fails because rebuild time contradicts near-instant recovery. Deleting the load balancer and hoping DNS TTL alone restores the previous build fails as a controlled strategy: removing the balancer damages availability, and DNS caching delays make rollback unpredictable for citizens. Exam caveat: when stems emphasize fast rollback without rebuild, map the answer to blue-green (or another pattern that preserves the last known-good environment), not to in-place package reverse. Operational check: keep the idle environment patched and data-compatible, rehearse the switch in non-production, monitor error budgets after cutover, and define how long blue remains reserved before cost reclamation. Align the municipal change advisory board on abort criteria so rollback authority is clear during after-hours portal incidents.