SAP-C02 Continuous Improvement for Existing Solutions Practice Question

A company runs a three-tier web application on AWS. The database tier uses Amazon RDS for PostgreSQL with a single primary instance and no read replicas. The application experiences heavy read traffic during business hours, causing CPU utilization on the primary to exceed 90%. The team wants to offload read traffic without changing the application's write path. Which solution should a solutions architect recommend?

⚠ Common exam trap

The trap here is believing that a Multi-AZ standby instance can serve read traffic, when it is a passive failover target that is inaccessible for queries.

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 configure the application to send read queries to the replica endpoint.

Adding an RDS read replica offloads read-only queries to a separate instance, reducing CPU pressure on the primary while leaving the write path unchanged. The application can be configured to use the replica endpoint for reads and the primary endpoint for writes. This is a minimal-change, cost-effective solution that directly addresses the read-heavy bottleneck.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
Increase the size of the RDS instance to a larger instance class with more vCPUs and memory.
Why it's wrong here
Vertical scaling increases capacity but does not separate read and write workloads, and it is a temporary fix that will eventually hit the same ceiling as traffic grows. It also requires a reboot or failover, causing downtime. The scenario asks to offload read traffic, which vertical scaling does not accomplish.
✗
Migrate the database to Amazon DynamoDB with on-demand capacity and update the application to use the DynamoDB SDK.
Why it's wrong here
Migrating from RDS PostgreSQL to DynamoDB requires rewriting the data model, queries, and application code, which is a major change to the write path and the application. The scenario explicitly asks to avoid changing the write path. DynamoDB also lacks relational features like joins and foreign keys that the application likely relies on.
✗
Enable Multi-AZ on the RDS instance and direct read queries to the standby instance.
Why it's wrong here
A Multi-AZ standby is a synchronous, passive copy used only for failover; it does not serve read traffic. The standby endpoint is not accessible for application queries. Enabling Multi-AZ improves availability and durability but does nothing to reduce primary CPU utilization from read-heavy workloads. This misconception is a common source of unnecessary cost without performance benefit.
✓
Create an RDS read replica and configure the application to send read queries to the replica endpoint.
Why this is correct
RDS read replicas use asynchronous replication from the primary and serve read-only traffic, which directly offloads read queries and reduces CPU on the primary. The application's write path remains pointed at the primary endpoint, so no write logic changes. This is the standard, lowest-effort way to scale read-heavy PostgreSQL workloads on RDS without altering the write tier.

Go deeper

SAP-C02 Continuous Improvement for Existing Solutions Practice Question

Why each option matters

Option-by-option breakdown

Related to this question