SAA-C03 Design High-Performing Architectures Practice Question

A web application uses an Amazon Aurora DB cluster. The workload is becoming read-heavy, and the application team wants to increase read throughput without changing the database schema. They can adjust the application to route reads differently. What should they do?

⚠ Common exam trap

Many exam-takers confuse Multi-AZ with read replicas: candidates often think Multi-AZ improves read performance, but in standard RDS Multi-AZ the standby is passive and cannot serve reads, whereas Aurora's architecture allows all replicas to actively handle read traffic.

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 read replicas and route read queries to the cluster reader endpoint

Adding Aurora read replicas and routing read queries to the cluster reader endpoint is the correct approach because Aurora replicas share the same underlying storage volume as the primary instance, so they can serve read traffic with minimal replication lag. The reader endpoint automatically load-balances connections across all available replicas, increasing aggregate read throughput without requiring 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.

✓
Add Aurora read replicas and route read queries to the cluster reader endpoint
Why this is correct
Aurora read replicas scale read throughput by creating up to 15 independent instances that share the same distributed storage volume. The cluster reader endpoint automatically routes new connections to any available replica, allowing SELECT queries to run in parallel across multiple instances while the writer instance focuses on update operations. Because replicas require no data copy and remain fully in sync with minimal replica lag, this approach directly addresses a read-heavy workload without schema or application refactoring.
✗
Switch the cluster to Multi-AZ with a longer failover target clock
Why it's wrong here
Switching the cluster to Multi-AZ only changes the physical placement and failover behavior, not the number of instances serving reads. In Aurora, high availability is already inherent through its replicated storage and replicas; modifying the failover target or timing simply alters which replica becomes primary during a failure. Read-heavy workloads are limited by the primary instance's CPU and IO capacity, so this configuration offers no additional read bandwidth and fails to solve the performance bottleneck.
✗
Move all reads to the writer endpoint to reduce connection overhead
Why it's wrong here
Consolidating all reads onto the writer endpoint forces the primary instance to absorb both write and read workloads, increasing CPU utilization, lock contention, and buffer pool churn. The connection overhead saved by not opening additional connections is negligible compared to the performance cost of oversubscribing one node. In a read-heavy scenario, the writer's limited processing capacity becomes the single point of failure, so spreading reads to replicas is necessary to increase aggregate throughput.
✗
Disable automated backups to reduce storage overhead and speed reads
Why it's wrong here
Automated backups for Aurora are implemented as continuous, incremental backups stored in S3, which do not reside on the local read path or consume database engine resources during normalization. Disabling automated backups does not free up read capacity because read queries are served from the cluster's storage layer, not backup snapshots. Removing backups only eliminates point-in-time recovery (PITR) capabilities and increases the risk of data loss, without improving query latency or throughput.

Go deeper

SAA-C03 Design High-Performing Architectures Practice Question

Why each option matters

Option-by-option breakdown

Related to this question