SAA-C03 Design High-Performing Architectures Practice Question

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 RDS Performance Insights and set up a longer retention period for the performance history.

  Why it's wrong here

  Performance Insights is a diagnostic and monitoring tool that helps identify bottlenecks and wait events; it does not add read capacity or reduce load on the primary. Increasing retention only keeps more history for analysis. It is useful for tuning but does not by itself improve the read scalability of the application.

• ✓

  Add an Amazon ElastiCache for Redis cluster in front of the database and cache the results of repeated queries.

  Why this is correct

  Caching the results of frequently repeated identical queries in ElastiCache for Redis means the application can serve them from memory without touching RDS at all, which removes a large share of read traffic. This complements read replicas and is especially effective for hot keys that would otherwise hit the primary on every request.

• ✗

  Convert the instance to a larger db.r6g.16xlarge size to increase memory and CPU.

  Why it's wrong here

  Vertical scaling gives the primary more headroom, but it is a single point of contention and does not add read capacity beyond one instance. It also requires downtime for the instance class change and is a temporary fix rather than a scalable architecture. It does not exploit the repeated identical queries, so cache efficiency is left on the table.

• ✓

  Create one or more read replicas and direct read-only queries to the replica endpoints.

  Why this is correct

  Read replicas offload read traffic from the primary using MySQL's asynchronous replication, so the primary is freed to handle writes and the read capacity scales horizontally. For repeated identical queries, the application can send them to a replica endpoint, and the architect can add more replicas as read demand grows. This directly reduces primary CPU pressure.

• ✗

  Enable Multi-AZ with a standby instance and point read queries at the standby endpoint.

  Why it's wrong here

  A Multi-AZ standby exists only for failover and does not serve read traffic; pointing the application at it is not supported and would not return query results. Multi-AZ improves availability and durability, not read scalability, so it does nothing to relieve the CPU-bound primary under read load.

Go deeper

Related to this question