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.

• ✗

  Delete unused indexes to reduce write overhead.

  Why it's wrong here

  Removing unused indexes primarily reduces write amplification and storage footprint, but it does not directly accelerate the SELECT queries that are likely causing the slowness. If the indexes are truly unused, their absence won't affect read performance, and if any of the slow queries actually rely on them, dropping them could force full table scans and make performance worse. The bottleneck is more likely resource saturation or a suboptimal query plan, not index overhead.

• ✗

  Enable Multi-AZ deployment for better read performance.

  Why it's wrong here

  Enabling Multi-AZ deploys a standby replica in a different Availability Zone and provides automatic failover for high availability, but that standby does not serve any read traffic. Because the primary instance continues to handle all queries, the additional replica does not increase read throughput or reduce server load. For horizontal read scaling, you would need to create one or more Read Replicas and route traffic to them, which is a different feature.

• ✓

  Increase the instance size to provide more CPU and memory.

  Why this is correct

  Scaling up to a larger instance class directly addresses the symptoms by giving the database engine more vCPUs and more memory. With additional memory, the InnoDB buffer pool can cache more data and index pages, reducing disk I/O, while extra CPU accelerates query execution, sorting, and joins. This is an appropriate immediate mitigation when CloudWatch metrics show high CPU utilization or high swap usage, though it doesn't fix inefficient queries.

• ✓

  Enable the slow query log to identify poorly performing queries.

  Why this is correct

  Enabling the slow query log causes RDS to record queries that exceed a configurable execution-time threshold, making it possible to pinpoint exactly which statements are consuming the most time. This is a critical diagnostic step because it turns a vague 'slow database' complaint into a concrete list of queries to analyze with EXPLAIN for missing indexes or poorly written joins. It is the right first step before making structural changes to the schema or instance.

• ✗

  Delete the binary log files to free up storage.

  Why it's wrong here

  Binary log files support replication, point-in-time recovery, and some monitoring features; deleting them frees storage space, but the reported problem is slow query performance, not a full or nearly full disk. Unless the database is erroring due to insufficient free space, removing binlogs will have no effect on query latency and may actually disable the ability to perform point-in-time recovery if deletion is not done through the managed retention settings. Storage pressure should be addressed by scaling the allocated storage or modifying backup retention, not by manually deleting logs.