A weekday release for a multi-instance Elastic Beanstalk permitting site must replace instances gradually while keeping enough capacity online. Which strategy fits that platform constraint?
Select an answer to reveal the explanation.
Short Explanation
Rolling is swapping tires while the bus keeps rolling—batches out, batches in, seats still available for permit applicants. Flattening the whole Auto Scaling group at lunch is how you invent an outage.
Full Explanation
Multi-instance Elastic Beanstalk sites for weekday permitting releases typically use rolling updates: replace instances in batches so enough capacity remains online for citizens submitting applications. Beanstalk rolling (and rolling with additional batch) strategies match classic multi-instance web apps where you cannot take the whole Auto Scaling group offline during business hours. The platform drains or replaces a controlled batch, waits for health, then continues—keeping the municipal permitting UI reachable throughout the release window.
Terminating the entire Auto Scaling group before launching replacements creates an unnecessary outage and abandons Beanstalk's capacity-preserving update modes. Deploying only by rewriting DNS to a single untested instance abandons fleet health management and concentrates risk on one host. Applying Lambda alias canary percentages is the wrong platform control when the application runs solely on Beanstalk EC2 instances rather than versioned Lambda aliases.
Exam caveat: rolling, immutable, and blue/green (enhanced health / CNAME swap patterns) are Beanstalk options; pick rolling when the stem emphasizes gradual instance replacement with capacity retained on a multi-instance environment.
Operational check: set a rolling batch size that leaves sufficient healthy instances for permit traffic, monitor Beanstalk environment health during the weekday window, confirm form availability throughout the batch replacements, and be ready to abort the environment update if health checks fail mid-roll.