SAA-C03 Design High-Performing Architectures Practice Question

A logistics company runs an Amazon RDS for MySQL database that supports a parcel-tracking API. During the morning peak, read queries for tracking history saturate the primary instance's CPU, slowing writes. The reads can tolerate a few seconds of staleness, and the team wants to offload them without changing the database engine. Which action should the team take?

⚠ Common exam trap

The trap here is assuming the Multi-AZ standby can serve reads, when it is a passive failover target and is not accessible for query traffic.

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 one or more read replicas and update the application to send tracking-history queries to the replica endpoint.

A read replica is a dedicated copy of the primary that serves read-only queries, so routing the tracking-history requests to it removes that CPU pressure from the primary instance while writes continue unimpeded. Replication is asynchronous, producing lag on the order of seconds, which matches the workload's tolerance for slightly stale reads. This keeps the MySQL engine and requires only an endpoint change in the application.

Answer analysis

Option-by-option breakdown

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

✗
Enable Multi-AZ on the DB instance and point the read queries at the standby instance.
Why it's wrong here
A Multi-AZ standby exists only for failover; it does not serve read traffic and cannot be addressed by the application. Pointing reads at it is not supported for RDS for MySQL. Enabling Multi-AZ improves availability, not read scalability, so the primary CPU would still be saturated by the tracking queries.
✓
Create one or more read replicas and update the application to send tracking-history queries to the replica endpoint.
Why this is correct
RDS read replicas are separate DB instances that receive asynchronous replication from the primary and can serve read traffic. Directing the tracking-history queries to the replica endpoint removes that load from the primary, freeing CPU for writes. The asynchronous replication lag is typically seconds, which the workload tolerates, and no engine change is required.
✗
Increase the size of the RDS DB instance and enable storage autoscaling on the primary.
Why it's wrong here
Scaling the primary vertically raises CPU and memory but does not separate read and write workloads, so the tracking queries still compete with writes on the same instance. Storage autoscaling only grows allocated disk space and has no effect on query CPU. The team would keep paying for a larger instance without resolving the read contention.
✗
Migrate the database to Amazon DynamoDB with a global secondary index on the tracking ID.
Why it's wrong here
DynamoDB is a NoSQL service, so moving from a relational MySQL schema would require substantial application and data-model changes, which the team wants to avoid. It also changes the engine, violating the stated constraint. While DynamoDB scales reads well, it is not the minimal-change fix for offloading read queries from an existing relational database.

Go deeper

SAA-C03 Design High-Performing Architectures Practice Question

Why each option matters

Option-by-option breakdown

Related to this question