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.

• ✗

  Enable Multi-AZ for the RDS instance and scale up the instance size

  Why it's wrong here

  Enabling Multi-AZ adds a standby replica in a different Availability Zone for high availability and automatic failover, but the standby is passive and cannot serve read traffic. Scaling up the instance size increases vCPU and memory, which may help if the bottleneck is CPU capacity, but it does not address the architectural issue that read-heavy queries are consuming primary instance resources. This approach incurs significant cost for a larger instance plus the standby, and it does not provide a dedicated endpoint for read scaling, so it fails to solve the root cause: read load on the primary.

• ✓

  Implement a read replica for the RDS instance and modify the application to route read queries to the read replica

  Why this is correct

  Implementing a read replica creates a separate RDS instance that uses asynchronous replication to maintain a copy of the primary database, and it has its own endpoint that can handle read traffic. By modifying the application to route SELECT queries to the read replica (and keeping write operations on the primary), you offload CPU-intensive read workloads from the primary instance, directly alleviating high CPU utilization. This is a proven pattern for read-heavy applications because it scales read capacity independently and is more cost-effective than scaling up the primary, as you only size the primary for write throughput.

• ✗

  Enable Amazon RDS Performance Insights and increase the storage allocation

  Why it's wrong here

  Performance Insights helps identify performance bottlenecks but does not directly reduce CPU load. Increasing storage may improve I/O performance if bottlenecks are I/O-related, but it does not address high CPU from read queries and increases cost.

• ✗

  Implement Amazon ElastiCache for Memcached in front of the database and migrate read-heavy queries to cache

  Why it's wrong here

  Implementing ElastiCache for Memcached would offload some read queries by caching frequently accessed data, reducing direct database hits. However, it does not scale the underlying database's read capacity by providing additional read endpoints, which is crucial when the database CPU itself is consistently high due to read-only queries. This option is tempting as it addresses read-heavy workloads and improves performance by reducing database load. It would be correct for caching specific query results or application objects, such as session data, to minimise repetitive database access.

Go deeper

Related to this question