SAA-C03 Design High-Performing Architectures Practice Question
A production application writes to an Amazon Aurora PostgreSQL cluster. Users report that during business-hour reporting runs, write latency increases. The application team wants to keep the writer focused on OLTP writes while still providing low-latency reads for reporting queries. What architectural approach should the solutions architect recommend?
⚠ Common exam trap
Watch out — candidates often think resizing the writer instance (Option B) is sufficient, but the exam tests the architectural principle of separating read and write workloads to avoid resource contention, not just scaling vertically.
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
✓
Create Aurora read replicas and direct reporting read-only connections to the cluster reader endpoint.
A is correct because creating Aurora read replicas and directing reporting read-only connections to the cluster reader endpoint offloads read traffic from the writer instance. This allows the writer to focus on OLTP writes, while the reader endpoint load-balances read-only queries across replicas, providing low-latency reads for reporting without impacting write performance.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Create Aurora read replicas and direct reporting read-only connections to the cluster reader endpoint.
Why this is correct
Aurora read replicas are separate DB instances that share the same underlying storage volume, so they serve read-only traffic without adding load to the writer. The cluster reader endpoint automatically load-balances connections across all replicas, allowing reporting queries to run in parallel with production writes. This decouples read and write workloads, reducing contention on the writer and improving overall responsiveness. It also lets you scale read capacity independently by adding or resizing replicas.
- ✗
Resize the writer instance to a larger class so it can handle both writes and reads with fewer slowdowns.
Why it's wrong here
Vertically scaling the writer instance to a larger class gives it more CPU and memory, which can temporarily reduce slowdowns caused by mixed workloads. However, this approach still funnels both writes and read-heavy reporting through the same instance, so resource contention remains. Larger instances are more expensive per hour, and you may reach an instance-size ceiling before read demand is satisfied. It does not provide the architectural separation that dedicated read replicas offer.
When this WOULD be correct
A solutions architect needs to improve overall database performance for a single-instance Aurora PostgreSQL that experiences high CPU and memory pressure from both reads and writes, with no requirement to separate read traffic. Scaling up the instance class provides more resources to handle the combined load.
- ✗
Enable cross-region replication for the entire cluster so reporting always runs in the secondary Region.
Why it's wrong here
Cross-region replication creates a second Aurora cluster in a different Region, which is valuable for disaster recovery and low-latency reads in geographically distant locations. For a local production application, however, directing reporting traffic to the secondary Region would add significant network latency and may violate data residency/compliance requirements. Cross-region replication is asynchronous, so the disaster-recovery cluster can lag behind the primary, causing reporting queries to return stale data. It also adds operational complexity and cost far beyond what is needed to solve simple read-write contention in the primary Region.
When this WOULD be correct
When the requirement is disaster recovery across regions and reporting can tolerate higher latency, or when the primary region is heavily loaded and reporting queries can be offloaded to a different geographic location with acceptable latency.
- ✗
Disable read replicas and use caching only in the application layer, keeping all queries connected to the writer endpoint.
Why it's wrong here
Application-layer caching only eliminates repeated identical queries, but reporting workloads often include unique aggregates, ad-hoc filters, or time-window scans that miss the cache and hit the database. With no read replicas, every such query—plus all production writes—must compete for the same writer instance's CPU, memory, and I/O. Disabling replicas removes the ability to scale reads horizontally, and cache invalidation becomes complex when writes constantly mutate the underlying data. This approach fails to offload steady read pressure from the writer.
When this WOULD be correct
In a scenario where the application requires strong read-after-write consistency and cannot tolerate even eventual consistency, and the reporting workload is small enough that caching handles most reads, directing all queries to the writer endpoint ensures immediate consistency.
Option-by-option analysis
Why each answer is right or wrong
Understanding why wrong answers are wrong — and when they would be correct — is what separates a 750 score from a 900. The SAA-C03 exam frequently reuses these exact scenarios with slightly different constraints.
✓Create Aurora read replicas and direct reporting read-only connections to the cluster reader endpoint.Correct answer▾
Why this is correct
Aurora read replicas are separate DB instances that share the same underlying storage volume, so they serve read-only traffic without adding load to the writer. The cluster reader endpoint automatically load-balances connections across all replicas, allowing reporting queries to run in parallel with production writes. This decouples read and write workloads, reducing contention on the writer and improving overall responsiveness. It also lets you scale read capacity independently by adding or resizing replicas.
✗Resize the writer instance to a larger class so it can handle both writes and reads with fewer slowdowns.Wrong answer — click to see why▾
Why this is wrong here
Resizing the writer instance to a larger class does not offload read traffic from the writer; reporting queries still compete with OLTP writes on the same instance, failing to isolate workloads and reduce write latency.
★ When this WOULD be the correct answer
A solutions architect needs to improve overall database performance for a single-instance Aurora PostgreSQL that experiences high CPU and memory pressure from both reads and writes, with no requirement to separate read traffic. Scaling up the instance class provides more resources to handle the combined load.
Why candidates choose this
Candidates may think that a larger instance can simply 'power through' the workload, overlooking the architectural best practice of separating read and write traffic to avoid contention.
✗Enable cross-region replication for the entire cluster so reporting always runs in the secondary Region.Wrong answer — click to see why▾
Why this is wrong here
Cross-region replication does not reduce latency for reporting queries in the primary region; it creates a separate cluster in another region, which would not help with low-latency reads for local reporting and introduces additional cost and complexity.
★ When this WOULD be the correct answer
When the requirement is disaster recovery across regions and reporting can tolerate higher latency, or when the primary region is heavily loaded and reporting queries can be offloaded to a different geographic location with acceptable latency.
Why candidates choose this
Candidates may think that replicating to another region automatically distributes read load, but they overlook that cross-region replication is for disaster recovery, not for reducing read latency in the same region.
✗Disable read replicas and use caching only in the application layer, keeping all queries connected to the writer endpoint.Wrong answer — click to see why▾
Why this is wrong here
Disabling read replicas and using only application-layer caching forces all reporting queries through the writer endpoint, increasing write latency during reporting runs. This contradicts the goal of offloading reads to keep the writer focused on OLTP writes.
★ When this WOULD be the correct answer
In a scenario where the application requires strong read-after-write consistency and cannot tolerate even eventual consistency, and the reporting workload is small enough that caching handles most reads, directing all queries to the writer endpoint ensures immediate consistency.
Why candidates choose this
Candidates may think caching alone can solve read performance without understanding that reporting queries often involve complex aggregations that caching cannot fully address, and they may underestimate the impact of mixing read and write workloads on the same instance.
Analysis generated from the official SAA-C03blueprint and verified against question context. The “when correct” sections are what AI assistants cite when candidates ask “what’s the difference between these options?”
Go deeper
Related to this question
About these practice questions
One of 935 original SAA-C03 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This SAA-C03 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SAA-C03 exam.