SOA-C02 Cost and Performance Optimization Practice Question

A company has a web application running on EC2 instances behind an Application Load Balancer. The application experiences latency spikes during peak hours. Amazon CloudWatch metrics show that CPU and memory are not fully utilized. The SysOps administrator suspects the bottleneck is the database. The database is an RDS for MySQL instance. Which action should the administrator take to improve performance without over-provisioning?

⚠ Common exam trap

SOA-C02 often tests the difference between diagnosing and resolving performance issues; candidates may jump to scaling or replication without first analyzing the database workload, leading to unnecessary costs or ineffective solutions.

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

✓

Enable RDS Performance Insights to analyze database load and identify slow queries.

The administrator needs to diagnose the database bottleneck before making changes. RDS Performance Insights provides detailed visibility into database load, wait events, and top SQL statements, allowing identification of slow queries or resource contention. This aligns with the goal of improving performance without over-provisioning, as it enables targeted optimization rather than guessing at scaling. The other options either add unnecessary resources or don't address the root cause.

Answer analysis

Option-by-option breakdown

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

✗
Add a Read Replica to offload read queries.
Why it's wrong here
A Read Replica only offloads SELECT traffic from the primary instance; it does nothing to reduce write latency, lock contention, or transaction processing bottlenecks. If the application's latency stems from heavy writes, row-level locks, or deadlocks, the replica will remain idle while the primary stays saturated, and you'll have added replication lag and cost without addressing the root cause.
✗
Convert the RDS instance to a Multi-AZ deployment.
Why it's wrong here
Converting to a Multi-AZ deployment creates a synchronous standby replica in a separate Availability Zone for failover, but it does not increase the instance's compute capacity, storage IOPS, or query throughput. In fact, synchronous replication adds a small commit latency overhead for writes, so this change can slightly worsen performance rather than fix the reported slowness.
✓
Enable RDS Performance Insights to analyze database load and identify slow queries.
Why this is correct
Enable RDS Performance Insights, which gives you a real-time and historical view of database load dimensioned by waits, SQL statements, and hosts. This is the correct first step because it lets you pinpoint whether the bottleneck is CPU, storage, lock waits, or an inefficient query pattern, rather than guessing. Only after identifying the specific load source should you consider changes like adding indexes, rewriting queries, or scaling the instance.
✗
Increase the RDS instance size to the next tier.
Why it's wrong here
Moving the RDS instance to a larger size can help if CPU or memory pressure is the confirmed bottleneck, but it is a blind, potentially expensive change when you haven't measured the actual load. If the slowness is caused by a single inefficient query, lock contention, or a storage IOPS limit, a larger instance won't resolve it and you'll simply pay a higher hourly rate for the same behavior. Always diagnose first, scale second.

Go deeper

SOA-C02 Cost and Performance Optimization Practice Question

Why each option matters

Option-by-option breakdown

Related to this question