SOA-C02 Deployment, Provisioning, and Automation Practice Question

A SysOps administrator deploys a web application using AWS Elastic Beanstalk. The administrator wants to deploy a new application version with zero downtime and minimize the risk of failure by launching a completely new set of instances before swapping traffic. Which deployment policy should the administrator choose?

⚠ Common exam trap

A common mix-up: candidates confuse 'Rolling with additional batch' (Option C) with immutable deployments because both add new instances, but they fail to recognize that only Immutable launches a completely separate fleet and swaps traffic atomically, while Rolling with additional batch still modifies the existing environment and does not provide a full isolation or instant rollback capability.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Immutable

The Immutable deployment policy (Option D) is correct because it launches a completely new set of instances in a separate Auto Scaling group, deploys the new application version to them, and then swaps the Elastic Load Balancer (ELB) traffic from the old instances to the new ones in a single, atomic swap. This ensures zero downtime and minimizes risk by keeping the original environment fully intact until the new instances pass health checks, allowing an immediate rollback by simply swapping traffic back.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
All at once
Why it's wrong here
All at once terminates and replaces every existing instance concurrently, leaving the Auto Scaling group with zero in-service instances during the deployment window. This causes complete downtime for the web application, and if the new version fails health checks, you cannot roll back without launching a fresh batch of old-version instances. It is only acceptable for dev/test environments that can tolerate an outage.
✗
Rolling
Why it's wrong here
Rolling updates instances in batches, such as one at a time or a fixed percentage, while leaving old instances serving traffic until each batch is replaced. During each batch, the fleet temporarily runs below desired capacity until the new instances pass health checks, causing a transient reduction in available capacity. Rollback is also difficult because the old configuration is not preserved separately; you must run a reverse rolling deployment to restore the previous version.
✗
Rolling with additional batch
Why it's wrong here
Rolling with additional batch first launches an extra batch of new instances before removing any old instances, so capacity is temporarily increased rather than reduced during the deployment. However, updates are still performed in-place on existing instances in waves, meaning the old and new versions coexist on the same Auto Scaling group with no clean traffic-level separation. If the new version is defective, you still need a multi-step in-place rollback, and the extra capacity can trigger scaling or cost concerns.
✓
Immutable
Why this is correct
Immutable deployment creates a completely separate Auto Scaling group with a new launch template or configuration running the new application version. It lets the new fleet fully initialize, pass health checks, and register with the load balancer before traffic is shifted away from the old fleet. Because the old fleet remains untouched until traffic has moved and can be instantly restored by redirecting traffic back, it provides zero downtime and a trivial rollback mechanism.

Go deeper

SOA-C02 Deployment, Provisioning, and Automation Practice Question

Why each option matters

Option-by-option breakdown

Related to this question