SOA-C02 Cost and Performance Optimization 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.

• ✗

  Use Amazon ElastiCache for caching.

  Why it's wrong here

  ElastiCache can reduce load by caching frequent query results, but it introduces a separate caching tier that requires application changes, cache invalidation logic, and additional infrastructure management. For a read-heavy RDS MySQL workload, a read replica is simpler and more cost-effective because it offloads the actual SQL read traffic without requiring code changes. Caching only helps when the same exact data is requested repeatedly; a read replica provides comprehensive read scaling that works for any query pattern.

• ✗

  Enable Multi-AZ deployment.

  Why it's wrong here

  Multi-AZ deployment creates a synchronous standby replica in a different Availability Zone for high availability, but the standby is never used to serve read or write traffic. All queries are still handled by the primary instance, so enabling Multi-AZ does not reduce the read load at all. It improves fault tolerance and failover, but does not address the need to scale read performance, making it irrelevant to the stated problem.

• ✗

  Scale up the DB instance to a larger size.

  Why it's wrong here

  Scaling up the DB instance to a larger size increases the compute and memory capacity of the primary instance, but it is a vertical scaling approach that is typically more expensive than adding read replicas. It forces the primary to handle all read and write traffic, so it does not decouple heavy read workloads from writes, and it may require a lot of downtime depending on the RDS modification method. Additionally, vertical scaling has hardware limits, whereas horizontal scaling with read replicas can be extended far more easily and elastically.

• ✓

  Create a read replica in the same region.

  Why this is correct

  A read replica in the same region is the most direct and cost-effective way to offload read traffic from the primary RDS MySQL instance. It uses asynchronous replication to keep a copy of the database and can handle a large number of SELECT queries, reducing the load on the source instance. Because it is in the same region, replication latency is low, and it also offers the benefit of being promotable to a standalone instance if needed for disaster recovery or migration scenarios.

Go deeper

Related to this question