SAA-C03 Design Resilient Architectures Practice Question

A healthcare provider hosts a patient-records API on Amazon EC2 instances in a single Availability Zone behind an Application Load Balancer. An audit finds the architecture cannot tolerate the loss of that Availability Zone. Budget is limited, and the API reads from an Amazon Aurora MySQL cluster that currently has one writer instance and no replicas. Which change most effectively addresses the audit finding?

⚠ Common exam trap

Candidates often confuse multi-Region disaster recovery with multi-Availability Zone high availability, which leads to an over-engineered and over-budget answer.

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

✓

Add an Aurora Replica in a second Availability Zone and register EC2 instances in that same second Availability Zone with the load balancer's target group.

The audit finding is about surviving the loss of one Availability Zone, so the fix must add capacity in a second zone for both tiers. An Aurora Replica in another zone gives the database an automatic failover target, and EC2 instances in that same zone let the load balancer continue serving requests. Cross-Region designs exceed the requirement and the budget.

Answer analysis

Option-by-option breakdown

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

✓
Add an Aurora Replica in a second Availability Zone and register EC2 instances in that same second Availability Zone with the load balancer's target group.
Why this is correct
Placing an Aurora Replica in a second Availability Zone gives the database a failover target, and Aurora promotes a replica automatically if the writer fails. Adding EC2 instances in that same zone removes the single-zone compute risk and lets the Application Load Balancer route to healthy targets in either zone. This directly resolves the audit finding at modest cost.
✗
Enable Aurora backtrack on the cluster and increase the EC2 Auto Scaling group maximum size within the existing Availability Zone.
Why it's wrong here
Aurora backtrack rewinds a cluster to a prior point in time to undo logical mistakes; it does not create a second Availability Zone or provide failover during a zone outage. Scaling EC2 capacity within the same zone keeps every instance exposed to the same failure domain. Neither action removes the single Availability Zone dependency the audit flagged.
✗
Convert the cluster to Aurora Global Database and add a secondary AWS Region for the EC2 fleet.
Why it's wrong here
Aurora Global Database targets cross-Region disaster recovery, which exceeds the stated requirement and adds substantial cost, conflicting with the limited budget. The audit finding concerns loss of one Availability Zone, not loss of an entire Region. A second Region also introduces replication lag and operational complexity that the scenario does not call for.
✗
Replace Aurora with a single-instance Amazon RDS for MySQL deployment and place all EC2 instances in an Auto Scaling group with a desired capacity of one.
Why it's wrong here
A single-instance RDS deployment has no standby and therefore no automatic failover, which is weaker than the current Aurora cluster rather than stronger. A desired capacity of one keeps a single point of failure for compute. This option reduces resilience while appearing to add an Auto Scaling group, so it fails the audit requirement outright.

Go deeper

SAA-C03 Design Resilient Architectures Practice Question

Why each option matters

Option-by-option breakdown

Related to this question