SAA-C03 Design Resilient Architectures Practice Question

A healthcare company runs a stateless patient-intake API on a fleet of Amazon EC2 instances in a single VPC. The compliance team requires the workload to survive the complete loss of one Availability Zone with no manual intervention, and the instances must be replaced automatically if they fail health checks. The application stores no local state and writes all data to Amazon RDS. Which approach meets these requirements with the LEAST operational effort?

⚠ Common exam trap

The trap here is assuming that a load balancer alone provides high availability, when it only distributes traffic and does not replace failed compute capacity.

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

✓

Create an Auto Scaling group spanning two Availability Zones with a launch template, and attach it to an Application Load Balancer target group with health checks enabled.

Resilience to a full Availability Zone loss requires capacity spread across at least two zones, and automatic instance replacement requires an Auto Scaling group whose health checks are tied to the load balancer. Combining a multi-AZ Auto Scaling group with an Application Load Balancer target group delivers both properties without manual intervention, which is exactly what the compliance requirement demands.

Answer analysis

Option-by-option breakdown

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

✗
Launch the instances directly with a launch template into two subnets in different Availability Zones, and attach each instance to a Network Load Balancer with cross-zone load balancing enabled.
Why it's wrong here
Manually launched instances in two subnets have no health-check-driven replacement mechanism, so a failed instance stays failed until an operator intervenes. The Network Load Balancer distributes traffic but does not recreate unhealthy capacity, and cross-zone load balancing only affects traffic distribution, not instance lifecycle. This leaves the fleet unable to self-heal on instance failure.
✗
Place the instances behind an Application Load Balancer in one Availability Zone and configure an Amazon Route 53 health check with a failover record pointing to a static Elastic IP address.
Why it's wrong here
A single-zone load balancer has no second zone to fail over to, and a static Elastic IP address is not a scalable target for a fleet. Route 53 failover records redirect DNS, but they cannot recreate instances or restore capacity in a healthy zone. This architecture remains a single point of failure despite the health check.
✗
Deploy the instances as an Auto Scaling group in a single Availability Zone and enable detailed CloudWatch monitoring with a scaling policy based on CPU utilization.
Why it's wrong here
A single-Availability-Zone Auto Scaling group cannot survive the loss of that zone because all capacity resides in one failure domain. Detailed monitoring and CPU-based scaling policies respond to load, not to zone failure, and cannot provision capacity in a zone that is unavailable. The design therefore fails the stated resiliency requirement.
✓
Create an Auto Scaling group spanning two Availability Zones with a launch template, and attach it to an Application Load Balancer target group with health checks enabled.
Why this is correct
An Auto Scaling group across multiple Availability Zones redistributes capacity when a zone is lost, and its health checks replace instances that fail. Attaching the group to an Application Load Balancer target group means ELB health checks drive replacement of unhealthy instances. This satisfies both zone-failure survival and automatic instance replacement with minimal operational overhead.

Go deeper

SAA-C03 Design Resilient Architectures Practice Question

Why each option matters

Option-by-option breakdown

Related to this question