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.

• ✓

  Enable the slow query log in RDS and review the logs.

  Why this is correct

  The slow query log records every SQL statement that takes longer than the `long_query_time` threshold to execute, capturing the exact query text, execution time, lock time, and rows examined. Enabling it via the RDS parameter group (`slow_query_log=1`) is the most direct way to pinpoint which specific statements are causing the observed slowdown, allowing targeted optimization such as adding indexes or rewriting the query. This makes it the definitive first step for diagnosing slow queries at the statement level rather than relying on inferred metrics.

• ✗

  Increase the DB instance size to improve performance.

  Why it's wrong here

  Increasing the DB instance size (scaling up) adds more CPU, memory, and I/O capacity, but it does not reveal which queries are slow or why they are slow; it merely gives the database more headroom to run inefficient statements. This can temporarily mask the performance issue while incurring higher costs, and if the root cause is a poorly designed query or missing index, the problem will persist or reappear once the workload grows. Scaling should be a remediation after identifying the bottleneck, not a diagnostic action.

• ✓

  Enable Performance Insights to analyze database performance.

  Why this is correct

  Performance Insights gives a real-time and historical visualization of database load, breaking down wait events and listing the top SQL statements by load so you can correlate high latency with specific queries. It is a correct and valuable diagnostic aid, especially for capturing the impact of queries that repeatedly consume resources, but it relies on the Performance Schema and aggregates load rather than logging every individual slow statement. Unlike the slow query log, it does not automatically report the exact execution time and lock time of each statement beyond a threshold, so it serves as a complement rather than a replacement.

• ✓

  Use the RDS console to review metrics for high CPU or IOPS usage.

  Why this is correct

  Reviewing the RDS CloudWatch metrics for high CPU, IOPS, or DatabaseConnections in the console reveals whether the instance is resource-constrained, which helps narrow down the type of problem (e.g., compute-bound vs. storage-bound). However, these aggregate metrics cannot tell you which specific SQL statement is responsible; a single heavy query can spike CPU usage, but the metric alone will not identify its text or pattern. This approach is useful for correlation and triage, but it is not sufficient for finding the exact query to fix.

• ✗

  Create a read replica to offload read traffic.

  Why it's wrong here

  Creating a read replica establishes a separate read-only copy of the database that can serve SELECT traffic, which can reduce load on the primary instance only if the slowdown is caused by a high volume of read queries. It does not diagnose the root cause of slow queries, and if the bottleneck is a slow write, an inefficient join, or lock contention on the primary, a read replica will have no effect or could even worsen matters by adding replication overhead. Replicas are a scaling strategy, not a diagnostic tool, and should be introduced only after logs confirm that read load is the actual issue.

Go deeper

Related to this question

Same concept, more angles

3 more ways this is tested on DVA-C02

These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.