SAA-C03 Design High-Performing Architectures Practice Question

An application uses Amazon Aurora MySQL. CloudWatch shows the writer instance near 85% CPU while the only reader instance averages 15% CPU. Trace logs show that all SELECT statements still target the writer endpoint. The workload is read-heavy, and the application already tolerates eventual consistency for reads. Which two changes will best increase total read throughput without a schema redesign? Select two.

⚠ Common exam trap

It's easy for candidates to think adding more reader instances alone solves the problem, but they must first redirect read traffic away from the writer endpoint—otherwise, the new replicas remain idle and the writer remains overloaded.

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

✓

Point read-only queries to the Aurora reader endpoint instead of the writer endpoint.

The Aurora reader endpoint is designed to distribute read-only connections across all available Aurora Replicas, offloading SELECT queries from the writer instance. Currently, all SELECT statements target the writer endpoint, causing the writer's CPU to be at 85% while the reader instance is underutilized at 15%. By redirecting read traffic to the reader endpoint, the writer's CPU load decreases, and the existing reader instance can handle more read throughput without any schema changes.

Answer analysis

Option-by-option breakdown

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

✓
Point read-only queries to the Aurora reader endpoint instead of the writer endpoint.
Why this is correct
The reader endpoint is intended for read-only traffic and automatically distributes connections across Aurora Replicas. Redirecting SELECT statements away from the writer immediately reduces CPU pressure on the writer and uses the unused read capacity already available in the cluster. This is the fastest, lowest-risk way to improve read throughput without changing the schema or the application data model.
✓
Add one or more additional Aurora Replicas and distribute read traffic across them.
Why this is correct
Each additional Aurora Replica adds independent read capacity to the cluster. For a read-heavy workload, more replicas increase total throughput and provide more room for the application to spread load. Because the application already accepts eventual consistency, replicas are a good fit and can be used through the reader endpoint or application-side routing.
✗
Convert the cluster to a single-AZ RDS MySQL instance to reduce replication overhead.
Why it's wrong here
This would remove Aurora’s read-scaling architecture and reduce availability. A single-AZ instance also concentrates all traffic on one node, which is the opposite of what this workload needs. It may reduce replication complexity, but it does not increase read throughput.
✗
Replace the writer endpoint with the instance endpoint of the primary node to speed up SELECT queries.
Why it's wrong here
The primary writer is already the bottleneck in the scenario. Sending more SELECT traffic to the writer endpoint or its instance endpoint increases contention on the busiest node and does not add any new read capacity. That choice worsens the current CPU imbalance.
✗
Add Amazon ElastiCache and move all database writes into the cache layer.
Why it's wrong here
A cache can offload some read traffic, but it is not a substitute for the database for transactional writes. Moving writes into a cache layer would break durability and consistency guarantees. The question asks for a direct Aurora read-scaling fix without schema redesign, so replica-based scaling is the right approach.

Go deeper

SAA-C03 Design High-Performing Architectures Practice Question

Why each option matters

Option-by-option breakdown

Related to this question