SOA-C02 Cost and Performance Optimization Practice Question

A SysOps administrator is troubleshooting high CPU utilization on an RDS for MySQL instance. The application is read-heavy. Which optimization technique would improve performance and potentially reduce costs?

⚠ Common exam trap

The trap is confusing Multi-AZ with Read Replicas. Multi-AZ is for high availability, not performance. Also, candidates might think increasing storage improves CPU, but it doesn't. The key is to offload reads.

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

✓

Implement RDS Read Replicas to offload read traffic.

Implementing RDS Read Replicas offloads read traffic from the primary instance to one or more replicas, reducing CPU utilization on the primary. This improves performance for read-heavy applications and can also reduce costs because you can potentially use a smaller primary instance or fewer replicas than scaling up the primary. Read Replicas are asynchronous and can be in different AZs or regions.

Answer analysis

Option-by-option breakdown

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

✗
Delete unused indexes from the database.
Why it's wrong here
Deleting unused indexes frees storage space and reduces write amplification, but it does not directly address CPU consumption on an RDS instance. CPU utilization is driven by query execution, such as table scanning, sorting, and joins, not by the number of indexes present. Removing an index that is genuinely unused can even harm read performance if the optimizer would have chosen it for a different query. Therefore, while index hygiene is good practice, it is not a targeted fix for high CPU utilization caused by an active workload.
✓
Implement RDS Read Replicas to offload read traffic.
Why this is correct
Implementing RDS Read Replicas is an effective solution for high CPU utilization when the workload is read-heavy. Replicas are asynchronous read-only copies of the primary instance, and routing SELECT traffic to them offloads query processing and reduces CPU spent on reads on the primary. The primary still handles writes and synchronized reads, but by scaling out read capacity you can prevent CPU saturation without upgrading the primary instance. This approach also delivers cost efficiency because you can choose smaller replicas or a smaller primary rather than purchasing a larger single instance.
✗
Increase the allocated storage size.
Why it's wrong here
Increasing the allocated storage size on an RDS instance primarily affects I/O capacity, specifically the baseline IOPS and throughput that the instance receives. CPU utilization is a compute metric driven by query processing, session management, and transaction handling; disk capacity does not influence how many CPU cycles a query consumes. Even if the instance is I/O-bound, the bottleneck would manifest as high wait time or latency, not high CPU. Thus, expanding storage is an incorrect remedy for a CPU saturation issue.
✗
Enable Multi-AZ deployment for failover support.
Why it's wrong here
Enabling Multi-AZ deployment creates a synchronously replicated standby instance in a different Availability Zone for high availability, but that standby cannot service read or write traffic. The application still connects to the primary instance for all queries, and the standby consumes resources for replication and failover only. Therefore, Multi-AZ has no effect on the primary's CPU load; if anything, synchronous replication between the primary and standby introduces additional overhead. This option is intended for failover resilience, not for alleviating CPU saturation.

Go deeper

SOA-C02 Cost and Performance Optimization Practice Question

Why each option matters

Option-by-option breakdown

Related to this question