The permits portal weekend release should swap citizen traffic from the live environment to a fully prepared standby in one cutover. Which strategy is that?
Select an answer to reveal the explanation.
Short Explanation
Blue-green is two fully dressed stages—flip the permits spotlight from blue to green when weekend go-live hits. Half-patched live nodes or a fake "100% canary" are not that swap.
Full Explanation
Blue-green delivery maintains two complete environments and switches traffic from the live (blue) environment to a fully prepared standby (green) at cutover. A permits-portal weekend release that should swap citizen traffic onto a prepared standby in one cutover is a classic blue-green strategy: green is built and validated first, then the router or load balancer flips. Municipal weekend windows often prefer that binary environment swap because rollback is another flip back to blue.
Patching half the live nodes in place with no standby environment fails by concept because that is partial in-place or rolling mutation of the live fleet, not a full environment switch. Shipping unfinished builds straight to the only production cluster midweek fails because there is no prepared complete standby and no controlled blue-green cutover discipline. Labeling an immediate 100% shift with no second environment as "canary" fails both naming and architecture: without two complete environments, it is not blue-green, and 100% with no progressive slice is not canary either.
Exam caveat: blue-green requires two complete environments (or equivalent full stacks) and a traffic switch; it is not identical to rolling batches or percentage canaries. Also ensure data/schema compatibility across the flip—the traffic switch alone does not fix incompatible databases.
Operational check: before the weekend cutover, verify green is healthy on the standby URL, flip traffic to green, confirm citizens hit green, and rehearse flipping back to blue. Confirm blue remains intact as the rollback target during the validation window.