DVA-C02 Troubleshooting and 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.

• ✗

  NetworkReceiveThroughput

  Why it's wrong here

  NetworkReceiveThroughput measures the incoming network traffic to the RDS instance, typically in bytes per second. While a sustained spike could coincide with heavy read/write activity, it is a throughput metric, not a latency or utilization metric that directly indicates slow query performance. High network throughput alone does not cause slow instance response; it is usually a symptom of large result sets or data transfer patterns, not the root cause of high CPU or query delays.

• ✗

  SwapUsage

  Why it's wrong here

  SwapUsage is not a standard Amazon RDS metric exposed by CloudWatch for MySQL instances. RDS manages the underlying EC2 host and does not provide direct swap usage; instead, the relevant metric is the FreeableMemory or database-specific memory pressure. Even if swap were occurring, it would be a consequence of memory pressure, not the primary metric for diagnosing a slow MySQL instance, and the question's symptoms point more toward CPU or query efficiency.

• ✓

  CPUUtilization

  Why this is correct

  CPUUtilization shows the percentage of allocated compute capacity being consumed on the RDS instance. For a slow MySQL instance, high and sustained CPU utilization is a classic indicator that the database is working too hard, often due to inefficient queries, missing indexes, or a burst of concurrent traffic. When CPU is saturated, query execution queues build up, directly increasing response times, so this is the most direct metric to investigate first for a slow instance.

• ✗

  FreeStorageSpace

  Why it's wrong here

  FreeStorageSpace tracks the available disk capacity, but running low on space triggers write operations to block or auto-scaling, not general read latency. Slow query performance is typically caused by resource contention like CPU, memory, or locks, not by free disk space unless the disk is completely full. In the context of a slow MySQL instance, checking FreeStorageSpace would not reveal the most likely cause; it is more relevant for failure prevention than for diagnosing latency.

• ✓

  ReadLatency

  Why this is correct

  ReadLatency measures the time taken for a read I/O operation to complete, and high read latency is often a direct sign of slow queries or disk contention. While this is a valid diagnostic metric, it is a consequence of underlying problems such as high CPU utilization, inefficient query plans, or insufficient memory for cache. Unlike CPUUtilization, which shows the active bottleneck, ReadLatency only exposes the effect on I/O and does not pinpoint whether the cause is compute, storage, or query design.

Go deeper

Related to this question