An Aurora PostgreSQL cluster is experiencing high read latency because 85% of traffic consists of read-only queries. The write workload must stay on the writer instance, and the team wants to offload reads without changing the application’s core query patterns. What is the best architectural option?

Increase the writer instance size so it can handle more reads and writes simultaneously.

Scaling the writer increases resources, but it does not isolate read workload from write workload. With a heavily read traffic pattern, the writer still becomes the bottleneck due to shared compute/storage resources for both reads and writes.

Enable Multi-AZ failover only and rely on the standby to serve reads in normal operation.

Multi-AZ standby primarily provides high availability and failover behavior. It is not the same as adding dedicated reader capacity for steady-state read scaling, and it is not intended as a normal operational read offload path.

Move the read workload to ElastiCache Redis while keeping DynamoDB as the SQL data source.

ElastiCache is a caching layer and Redis does not replace Aurora PostgreSQL SQL query execution for arbitrary read patterns without additional application/data redesign. The scenario asks for offloading reads from Aurora while keeping core query patterns, which aligns with Aurora readers rather than changing the data architecture.

What does this SAA-C03 question test?

Static NAT maps one inside address to one outside address.

What is the correct answer to this question?

The correct answer is: Add Aurora reader instances (read replicas) and route read queries to the reader endpoint while keeping writes on the writer endpoint. — The best option is to add Aurora reader instances (Aurora read replicas) and route read-only queries to the reader endpoint. Aurora readers are intended to offload read-heavy workloads by providing separate compute capacity for reads while keeping the write workload on the writer. Multi-AZ failover is primarily for availability rather than steady-state read throughput. Scaling only the writer increases capacity but does not isolate or eliminate contention between reads and writes. Changing to ElastiCache would require a larger architectural shift than necessary for the stated goal. Why others are wrong: Increasing the writer size may reduce latency, but it still shares resources for both reads and writes, so contention remains. Multi-AZ standby is not a dedicated read offload mechanism under normal operation. ElastiCache introduces a cache consistency/data modeling challenge and does not directly satisfy “offload reads from Aurora without changing core query patterns.”

What should I do if I get this SAA-C03 question wrong?

Then try more questions from the same exam bank and focus on understanding why the wrong options are tempting.