SAA-C03 Design High-Performing Architectures Practice Question
A retail analytics app uses Amazon RDS for PostgreSQL. Read traffic is growing, and the database CPU spikes mainly due to SELECT-heavy workloads. Writes are less frequent, and the app can tolerate eventually consistent reads for the reports. What is the most appropriate AWS-native way to improve read performance with minimal application changes?
⚠ Common exam trap
The trap here is that candidates might assume read replicas require application changes to handle eventual consistency, but the question explicitly states the app can tolerate eventually consistent reads, making the replica endpoint swap a minimal-change solution.
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 an RDS read replica and point the reporting queries to the replica endpoint.
Creating an RDS read replica is the most appropriate AWS-native solution because it offloads SELECT-heavy workloads from the primary database instance to a read-only copy, reducing CPU spikes on the primary. The application can tolerate eventually consistent reads for reports, which is exactly the consistency model of RDS read replicas (typically sub-second replication lag). This requires minimal application changes—only updating the reporting queries to point to the replica endpoint—and fully leverages PostgreSQL's built-in replication capabilities.
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 an RDS read replica and point the reporting queries to the replica endpoint.
Why this is correct
Amazon RDS read replicas use asynchronous replication from the primary DB instance to one or more read-only copies, typically within the same region or cross-region. By pointing reporting and analytics queries to a replica's DNS endpoint, you offload SELECT-heavy traffic from the primary, reducing CPU and I/O contention on the source instance. This lets the primary focus on OLTP writes while analysts query near-real-time data from the replica, requiring no application schema changes. For a retail analytics app with read pressure, this is the minimal-risk, AWS-native fix.
- ✗
Switch the cluster to DynamoDB without redesigning the data model.
Why it's wrong here
DynamoDB is a schemaless key-value/document store, not a drop-in replacement for a PostgreSQL relational database. Moving the same schema and SQL-style joins, transactions, and aggregations would require extensive application redesign, including new partition keys, secondary indexes, and query patterns. Even after migration, DynamoDB would not remove the existing read load from the RDS instance; you would need to decommission or re-architect the RDS layer entirely. This is a high-effort, high-risk option that does not directly address the immediate need to scale RDS read capacity.
When this WOULD be correct
A question where the application requires a fully managed NoSQL database with single-digit millisecond latency at any scale, and the team is willing to redesign the data model and application code to fit DynamoDB's key-value and document structures.
- ✗
Enable S3 event notifications to trigger a Lambda function after each write to the database.
Why it's wrong here
S3 event notifications fire only when objects are created, deleted, or restored in an S3 bucket, not when rows change in a relational database. Your RDS for PostgreSQL instance does not automatically emit writes to S3, so wiring an S3 event to a Lambda function would not capture any database changes. Even if you configured the RDS instance to export data to S3, the event would trigger post-write processing, not reduce the SELECT workload hitting the reporting queries. This option adds moving parts (Lambda, S3, permissions) without addressing read path performance.
When this WOULD be correct
This option would be correct in a scenario where the requirement is to offload heavy write processing or to trigger downstream actions (e.g., data export, analytics pipeline) after each database write, and the application can tolerate eventual consistency for those downstream tasks.
- ✗
Replace the RDS instance class with a smaller size to reduce cost and improve performance.
Why it's wrong here
Downsizing the RDS instance class—for example, from a memory-optimized to a burstable or smaller general-purpose class—reduces vCPU and memory resources available for query execution and connection handling. Under a heavy reporting read load, this usually increases CPU utilization, lengthens query runtimes, and raises latency on both reads and writes. Cost might drop, but performance would not improve; the correct performance lever is scaling out replicas, not shrinking the single instance. This option confuses cost reduction with capacity planning and would likely make the read pressure worse.
When this WOULD be correct
This option would be correct in a scenario where the database is over-provisioned for the actual workload (e.g., consistently low CPU usage) and the goal is to reduce costs without negatively impacting performance. For example, a question stating 'The database CPU utilization is below 10% and costs must be minimized.'
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 an RDS read replica and point the reporting queries to the replica endpoint.Correct answer▾
Why this is correct
Amazon RDS read replicas use asynchronous replication from the primary DB instance to one or more read-only copies, typically within the same region or cross-region. By pointing reporting and analytics queries to a replica's DNS endpoint, you offload SELECT-heavy traffic from the primary, reducing CPU and I/O contention on the source instance. This lets the primary focus on OLTP writes while analysts query near-real-time data from the replica, requiring no application schema changes. For a retail analytics app with read pressure, this is the minimal-risk, AWS-native fix.
✗Switch the cluster to DynamoDB without redesigning the data model.Wrong answer — click to see why▾
Why this is wrong here
Switching to DynamoDB without redesigning the data model is not feasible because RDS PostgreSQL and DynamoDB have fundamentally different data models (relational vs. NoSQL), requiring significant application changes to adapt queries, schema, and consistency models.
★ When this WOULD be the correct answer
A question where the application requires a fully managed NoSQL database with single-digit millisecond latency at any scale, and the team is willing to redesign the data model and application code to fit DynamoDB's key-value and document structures.
Why candidates choose this
Candidates may think DynamoDB is a universal performance solution for all read-heavy workloads, overlooking the critical need for data model compatibility and the effort required to migrate from a relational database.
✗Enable S3 event notifications to trigger a Lambda function after each write to the database.Wrong answer — click to see why▾
Why this is wrong here
This option does not directly improve read performance for SELECT-heavy workloads on RDS PostgreSQL. It introduces asynchronous S3 event notifications and Lambda processing, which adds latency and complexity without offloading read queries from the primary database.
★ When this WOULD be the correct answer
This option would be correct in a scenario where the requirement is to offload heavy write processing or to trigger downstream actions (e.g., data export, analytics pipeline) after each database write, and the application can tolerate eventual consistency for those downstream tasks.
Why candidates choose this
Candidates may think that using serverless components like S3 and Lambda can scale reads, but they overlook that the bottleneck is database CPU from SELECT queries, which this option does not address.
✗Replace the RDS instance class with a smaller size to reduce cost and improve performance.Wrong answer — click to see why▾
Why this is wrong here
Replacing the RDS instance with a smaller size would reduce CPU capacity, worsening performance under SELECT-heavy workloads, not improving it. The question asks for improved read performance, not cost reduction.
★ When this WOULD be the correct answer
This option would be correct in a scenario where the database is over-provisioned for the actual workload (e.g., consistently low CPU usage) and the goal is to reduce costs without negatively impacting performance. For example, a question stating 'The database CPU utilization is below 10% and costs must be minimized.'
Why candidates choose this
Candidates may think that a smaller instance class reduces cost and assume performance is tied to cost, or they misinterpret 'improve performance' as 'reduce unnecessary resource waste'.
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.