SAA-C03 Design High-Performing Architectures Practice Question
An Aurora PostgreSQL application has an OLTP writer and a reporting dashboard that issues many read-only queries. The writer is healthy, but read latency rises noticeably during reporting windows. Which two changes should you make? Select two.
⚠ Common exam trap
Test-takers frequently think scaling up the writer instance (Option C) is sufficient, but they overlook that read-heavy workloads require horizontal read scaling via replicas, not just vertical scaling of the writer.
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 to scale out the read workload.
Adding Aurora Replicas (Option A) is correct because Aurora Replicas are dedicated read-only instances that share the same underlying storage volume as the writer, allowing you to scale read capacity linearly without impacting write performance. Sending read-only traffic to the reader endpoint (Option B) is correct because the reader endpoint automatically load-balances connections across all available Aurora Replicas, ensuring that dashboard queries are distributed and do not overload a single instance.
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 Replicas to scale out the read workload.
Why this is correct
Aurora Replicas are independent compute instances in the same Aurora cluster that share the underlying storage volume. By adding one or more replicas, you create additional read endpoints that can absorb dashboard queries and other read-only traffic, directly offloading the writer instance. Because Aurora's storage is distributed and replicated separately, adding replicas does not cause significant write overhead, making horizontal read scaling the most efficient and cost-effective solution for an OLTP workload with heavy reads.
- ✓
Send read-only application traffic to the reader endpoint.
Why this is correct
The reader endpoint is a connection endpoint that load-balances across all available Aurora Replicas in the cluster. Directing read-only traffic such as the dashboard to this endpoint ensures that queries are spread across the replicas instead of hitting the writer instance. This reduces CPU and connection pressure on the writer, improving overall throughput and allowing write performance to remain stable, while the writer endpoint exclusively handles OLTP writes.
- ✗
Scale up only the writer instance and keep all queries on it.
Why it's wrong here
Scaling up the writer instance by increasing its size (e.g., from r6g.large to r6g.2xlarge) provides only temporary and limited relief because all reads and writes still contend for the same CPU, memory, and I/O on a single node. Aurora storage is already separate from compute, but the writer instance alone must process every write and every read that is not routed elsewhere, so it remains the single point of contention. Aurora instance sizes have upper limits, so this approach cannot sustain growth and does not address the architectural pattern of separating read-heavy traffic from write-heavy traffic.
When this WOULD be correct
In a scenario where the database is CPU-bound on the writer due to write-heavy workload and read latency is acceptable, scaling up the writer instance (vertical scaling) would be correct to increase write throughput.
- ✗
Replace the cluster with a single-AZ RDS instance to reduce replication overhead.
Why it's wrong here
Replacing the Aurora cluster with a single-AZ RDS instance removes all read scaling capability because there are no read replicas, forcing every dashboard query and write onto one database instance. Single-AZ also sacrifices high availability, as a failure causes downtime with no failover target. The original bottleneck is read-heavy load, not replication overhead; Aurora Replicas use the same storage volume with minimal extra write cost, so eliminating them does not solve the problem and makes availability and performance worse.
- ✗
Move the dashboard to DynamoDB without changing the query model.
Why it's wrong here
DynamoDB is a NoSQL key-value and document database with a different data model, query semantics, and indexing mechanisms than Aurora PostgreSQL. Moving the dashboard to DynamoDB without rewriting the SQL queries, redesigning the schema, and adapting to eventual consistency or using PartiQL carefully would not work. Even if the dashboard were moved, this does not reduce the read load on the Aurora writer if the dashboard still needs the same transactional or relational queries; it also introduces a major application redesign with no direct benefit to the identified read bottleneck.
When this WOULD be correct
This option would be correct in a scenario where the reporting dashboard requires extremely low-latency access to a simple, high-traffic dataset (e.g., user session data or IoT events) and the application can be refactored to use DynamoDB's query patterns, with the original Aurora cluster handling only transactional writes.
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.
✓Add Aurora Replicas to scale out the read workload.Correct answer▾
Why this is correct
Aurora Replicas are independent compute instances in the same Aurora cluster that share the underlying storage volume. By adding one or more replicas, you create additional read endpoints that can absorb dashboard queries and other read-only traffic, directly offloading the writer instance. Because Aurora's storage is distributed and replicated separately, adding replicas does not cause significant write overhead, making horizontal read scaling the most efficient and cost-effective solution for an OLTP workload with heavy reads.
✗Scale up only the writer instance and keep all queries on it.Wrong answer — click to see why▾
Why this is wrong here
Scaling up the writer instance does not offload read queries; the writer still handles all traffic, so read latency remains high during reporting windows. Aurora Replicas are needed to distribute read-only queries.
★ When this WOULD be the correct answer
In a scenario where the database is CPU-bound on the writer due to write-heavy workload and read latency is acceptable, scaling up the writer instance (vertical scaling) would be correct to increase write throughput.
Why candidates choose this
Candidates may think that a more powerful writer can handle both reads and writes faster, overlooking that Aurora's architecture separates read scaling via replicas.
✗Move the dashboard to DynamoDB without changing the query model.Wrong answer — click to see why▾
Why this is wrong here
Moving the dashboard to DynamoDB without changing the query model is wrong because DynamoDB is a NoSQL database with a different query model (key-value and document), so existing SQL queries from the reporting dashboard would not work without significant application changes.
★ When this WOULD be the correct answer
This option would be correct in a scenario where the reporting dashboard requires extremely low-latency access to a simple, high-traffic dataset (e.g., user session data or IoT events) and the application can be refactored to use DynamoDB's query patterns, with the original Aurora cluster handling only transactional writes.
Why candidates choose this
Candidates may think DynamoDB is always a good choice for read-heavy workloads due to its scalability and low latency, overlooking the fact that the existing query model (SQL) is incompatible with DynamoDB's NoSQL interface.
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
This SAA-C03 question is part of Courseiva's 935-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. 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.