SAA-C03 Design Resilient Architectures Practice Question

A financial analytics platform runs a stateless containerized service on Amazon ECS with AWS Fargate tasks spread across three Availability Zones. The service reads from an Amazon Aurora MySQL cluster and must continue serving read traffic if one Availability Zone fails. The team wants the read capacity to remain available with the least operational overhead and no changes to application connection strings during a zone failure. Which approach meets these requirements?

⚠ Common exam trap

The trap here is adding external load balancing or per-zone clusters when Aurora's reader endpoint already provides managed read distribution and failover.

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 Aurora Replicas in multiple Availability Zones and connect the service to the cluster reader endpoint so reads are load-balanced and fail over automatically.

The Aurora cluster reader endpoint is purpose-built to distribute read connections across replicas and to remove unhealthy replicas, including those in a failed Availability Zone. Deploying replicas in multiple zones and using that endpoint delivers automatic read failover with no application changes and minimal operational effort.

Answer analysis

Option-by-option breakdown

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

✗
Place a Network Load Balancer in front of each Aurora Replica and configure the service to connect through the load balancer DNS name.
Why it's wrong here
Aurora already exposes a managed reader endpoint that performs this distribution, so inserting a Network Load Balancer adds cost and complexity without benefit. The load balancer also does not understand Aurora cluster topology, so it cannot properly handle replica promotion or endpoint membership changes during a zone failure.
✓
Add Aurora Replicas in multiple Availability Zones and connect the service to the cluster reader endpoint so reads are load-balanced and fail over automatically.
Why this is correct
Aurora Replicas in different Availability Zones provide redundant read capacity, and the cluster reader endpoint automatically distributes connections across healthy replicas. If a zone fails, Aurora removes the affected replica from the endpoint, so the application keeps reading without changing connection strings, satisfying the low-overhead and no-reconfiguration requirements.
✗
Increase the size of the Aurora writer instance so it can absorb read traffic if a replica becomes unavailable.
Why it's wrong here
Scaling the writer does not add read endpoints or zone redundancy for reads, and routing read queries to the writer undermines the purpose of replicas. If an Availability Zone fails, the writer may be affected too, and this approach still requires application changes to redirect reads to the writer instance.
✗
Create a separate Aurora cluster in each Availability Zone and have the service choose a cluster endpoint based on a health check.
Why it's wrong here
Aurora storage is already replicated across three Availability Zones within a cluster, so running separate clusters per zone duplicates data and cost unnecessarily. It also pushes failover logic into the application, adding operational overhead and requiring connection-string changes, which the scenario explicitly wants to avoid.

Go deeper

SAA-C03 Design Resilient Architectures Practice Question

Why each option matters

Option-by-option breakdown

Related to this question