SOA-C02 Reliability and Business Continuity Practice Question

Answer analysis

Option-by-option breakdown

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

• ✓

  Configure the Auto Scaling group with subnets in at least two Availability Zones and ensure the ALB has subnets in the same AZs.

  Why this is correct

  Correctly designed for failure domain isolation: an Auto Scaling group spanning subnets in at least two Availability Zones (AZs) lets EC2 instances be provisioned across independent infrastructure, and an ALB with subnets in those same AZs can route traffic to healthy instances in any AZ. If one AZ becomes unavailable, the ALB continues distributing requests to instances in the remaining AZs, while Auto Scaling replaces failed instances in the other AZs. This provides high availability because the application is stateless and can serve all traffic from a single AZ when needed.

• ✗

  Increase the Auto Scaling group minimum to 10 instances to absorb the failure.

  Why it's wrong here

  Raising the Auto Scaling group minimum to 10 does not change the failure domain: all 10 instances would still be launched within the same single Availability Zone (AZ) if the group is not configured for multiple AZs. When that one AZ experiences an outage, every instance is simultaneously unavailable, and the ALB has no healthy targets to route to. The minimum capacity only guarantees a desired number of instances exist, not that they reside in independent infrastructure. Redundancy across AZs is the only way to avoid a single point of failure, so this approach merely increases cost without improving resilience.

• ✗

  Use larger instance types to handle the load of a failed AZ.

  Why it's wrong here

  Selecting larger instance types only increases compute, memory, and network capacity on each individual instance but does not alter the underlying architecture's Availability Zone (AZ) dependency. If all instances are placed in a single AZ and that AZ fails, even a massive instance will be offline, so the workload is still completely unavailable. Larger instances can help absorb increased traffic during normal operations, but they cannot protect against an entire AZ becoming unreachable. To survive an AZ failure, instances must be distributed across multiple AZs, not made more powerful in one AZ.

• ✗

  Use multiple Application Load Balancers in different AZs.

  Why it's wrong here

  Deploying multiple Application Load Balancers in different AZs does not resolve the fundamental issue if the EC2 instances are all located in a single Availability Zone (AZ). The ALBs are only entry points; they still forward requests to backend targets, and if those targets are all down because their AZ is unavailable, every ALB will return 503 or have no healthy instances to serve. In fact, an ALB itself is designed to be a regional or multi-AZ resource, so creating separate ones in different AZs is unnecessary and adds complexity. The proper fix is to have the ALB and the Auto Scaling group span the same set of AZs so that at least one AZ remains operational.

Go deeper

Related to this question