SAA-C03 Design Resilient Architectures Practice Question

A company hosts a web application on Amazon EC2 instances in an Auto Scaling group behind an Application Load Balancer (ALB). The ALB and the Auto Scaling group are currently deployed in only one Availability Zone (AZ). The business wants the application to keep running if that AZ has an outage. What is the best change?

⚠ Common exam trap

Candidates often think increasing capacity or adjusting health check intervals can compensate for a single-AZ deployment, but AWS high availability fundamentally requires distributing resources across multiple isolated failure domains (AZs).

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

✓

Deploy the ALB and the Auto Scaling group across at least two Availability Zones so healthy targets remain.

Deploying the ALB and Auto Scaling group across at least two Availability Zones (AZs) ensures that if one AZ fails, the ALB can route traffic to healthy EC2 instances in the remaining AZ(s). This is the fundamental AWS best practice for high availability: an ALB is a regional service that requires targets in multiple AZs to survive an AZ outage, and the Auto Scaling group must also span those AZs to maintain capacity. Without multi-AZ deployment, a single AZ failure makes the entire application unavailable regardless of instance health checks.

Answer analysis

Option-by-option breakdown

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

✗
Increase the desired capacity in the existing Availability Zone to handle all traffic during an outage.
Why it's wrong here
Raising the desired capacity within the current single Availability Zone merely adds more instances that share the same failure domain. When that whole AZ becomes unavailable—due to power loss, network disruption, or other zone-level events—every one of those instances, regardless of count, goes down together. There is no independent infrastructure remaining to accept traffic, so this approach cannot preserve availability during an AZ outage.
✓
Deploy the ALB and the Auto Scaling group across at least two Availability Zones so healthy targets remain.
Why this is correct
To tolerate an AZ outage, both the load-balancing entry point (the ALB) and the compute capacity (the Auto Scaling instances) must be available in more than one AZ. With the ALB in multiple AZs and the Auto Scaling group using multiple subnets/AZs, requests can be routed to healthy targets in a remaining AZ while Auto Scaling replaces unhealthy instances.
✗
Enable longer ALB health check intervals so failing instances are detected more slowly.
Why it's wrong here
Lengthening health check intervals makes the ALB less responsive at detecting an already-failing instance, but it does not create any redundant compute capacity elsewhere. In fact, slower health checks delay the Auto Scaling group's ability to replace unhealthy instances, extending the period of reduced availability. This change only alters detection timing; it does not address the fundamental dependency on a single AZ for both the load balancer and the instances.
✗
Switch from the ALB to an Internet Gateway so instances can fail over to the public internet.
Why it's wrong here
An Internet Gateway (IGW) is a horizontally scaled, redundant network component that simply provides bidirectional routing between a VPC and the public internet. It does not perform load balancing, does not evaluate target health, and has no concept of application-level failover between compute instances. Replacing the ALB with an IGW would actually remove the only mechanism that can route requests to healthy instances across multiple AZs, thereby guaranteeing that an AZ outage takes down the application.

Go deeper

SAA-C03 Design Resilient Architectures Practice Question

Why each option matters

Option-by-option breakdown

Related to this question