A new municipal portal version runs in parallel environment B while production traffic stays on environment A until cutover; rollback means flipping traffic back to A. Which deployment strategy is this?
Select an answer to reveal the explanation.
Short Explanation
Blue-green is like having two complete stages — one lit for the audience (blue) and one ready backstage (green). Flip the lights to cut over; flip them back if the show goes wrong. Parallel full environments plus a traffic switch is the giveaway, not a tiny canary slice or patching the same boxes.
Full Explanation
Blue-green deployment maintains two complete, production-capable environments and moves user traffic from the live environment (blue) to the candidate environment (green) at cutover, with rollback achieved by switching traffic back. A municipal portal running version B in parallel while production stays on A until cutover matches that strategy exactly. Canary deployment that exposes only a few percent of users fails here because the scenario describes full parallel environments and a traffic flip, not a small percentage cohort. In-place upgrade that patches live production VMs during business hours fails because production traffic remains on an untouched A while B runs separately rather than mutating A in situ. Rolling deployment that replaces one instance at a time inside a single pool fails because rolling works inside one fleet with gradual instance replacement, not two full environments with an explicit switch. Exam caveat: distinguish blue-green (two full stacks plus switch) from canary (limited exposure) and rolling (batched replacement in one pool). Operational check: confirm both environments receive equivalent configuration and data readiness, validate health on the idle stack, rehearse the load-balancer or DNS cutover, and keep the prior environment available long enough for civic rollback before reclaiming capacity. Record cutover criteria in the change ticket so council-facing services do not flip on incomplete smoke tests.