Feature flags plus a tiny traffic slice will validate a payments change before citywide enablement. Which deployment strategy does this describe?
Select an answer to reveal the explanation.
Short Explanation
Flags let you hide a feature; a tiny traffic slice lets a few real payments prove it — together that is canary thinking. Validate small, then flip the flag wider. That is not "everyone on day one" or "patch every box with the flag welded off."
Full Explanation
Canary validation using limited real traffic, often combined with feature flags, describes releasing a payments change to a tiny slice of users before citywide enablement. Feature flags control who sees the behavior without requiring a full redeploy for every cohort adjustment, while the small traffic slice supplies production signal. Blue-green that requires retiring feature flags before any citizen can be tested fails because blue-green is an environment switch model and does not intrinsically forbid flags; more importantly, the stem’s defining trait is limited real-traffic validation, not a full dual-stack cutover. In-place patching of every payment node with flags permanently disabled fails because it forces fleet-wide exposure without progressive enablement. Big-bang enablement for all citizens on day one fails the limited-slice requirement entirely. Exam caveat: Cloud+ may present canary and feature flags together; recognize canary as the traffic/user exposure strategy and flags as a complementary control plane for progressive delivery. Operational check: define flag cohorts, watch authorization and settlement metrics, automate kill-switch disablement, and only then raise the percentage for municipal payments. Keep audit logs of flag changes for financial control reviews.