City permit API instances are upgraded a few at a time so the service never goes fully dark. Which deployment strategy is being used?
Select an answer to reveal the explanation.
Short Explanation
Rolling is like repainting a bridge one section at a time while cars still cross the other lanes. A few instances upgrade; the rest keep answering permits. The service stays up — that gradual subset swap is rolling, not parking a whole second bridge (blue-green) or shutting the road.
Full Explanation
Rolling deployment upgrades or replaces subsets of instances in waves so remaining instances continue serving traffic and the service never goes fully dark. City permit API instances upgraded a few at a time with continuous availability is textbook rolling change management inside a single pool. Blue-green deployment that requires an idle duplicate of the entire production stack fails the concept here because the stem describes gradual instance updates, not a parallel full environment waiting for a traffic switch. Canary deployment that only ever serves five users regardless of fleet size fails because canary is about limited user exposure for validation, not the batch-by-batch replacement mechanics implied by upgrading instances a few at a time across the API fleet. In-place maintenance that takes the whole API offline for a weekend fails because continuous service is an explicit requirement. Exam caveat: rolling focuses on instance-batch progression and capacity remaining online; do not equate it with blue-green just because both reduce downtime risk. Operational check: set max unavailable or batch size, require health checks to pass before the next municipal wave, pause on failure, and verify permit-submission success rates during the rollout window. Ensure autoscaling and session affinity settings still make sense as instance versions temporarily mix in the civic API pool.