Only 5% of citizens should see the new UI first while metrics are watched before a wider rollout. Which deployment strategy matches this plan?
Select an answer to reveal the explanation.
Short Explanation
Canary is the "try it on a few birds before the whole flock" approach. Five percent of citizens get the new UI while you watch error rates and latency — if it sings, you widen the slice. That small-subset exposure is canary, not an all-at-once blue-green flip.
Full Explanation
A canary release routes a small, controlled subset of users or traffic to the new version while the majority remains on the stable build, allowing operators to watch real metrics before widening exposure. Limiting the new UI to 5% of citizens first is the defining canary pattern for a risk-managed municipal rollout. Blue-green cutover that instantly moves 100% of users fails because that strategy switches the full population between complete environments rather than constraining initial blast radius. In-place upgrade that replaces binaries on every production host overnight fails because it applies the change fleet-wide without a progressive traffic subset. Big-bang migration that retires the old portal before any citizen traffic is tested fails because it removes progressive validation and maximizes citizen impact on day one. Exam caveat: Cloud+ frequently contrasts canary (percentage or cohort) with blue-green (environment switch) and rolling (instance batches); pick canary when the stem emphasizes limited initial user exposure and metric watching. Operational check: define success and abort thresholds for error rate, latency, and key civic transactions; automate ramp-up only after those gates pass; and ensure the canary cohort is representative enough of citizen traffic without concentrating risk on a single department. Keep a fast disable path via traffic weight or feature flag for city hall communications if metrics degrade.