DVA-C02 Troubleshooting and Optimization Practice Question
A developer is troubleshooting a slow-performing Amazon RDS for MySQL database. Which TWO actions should the developer take to improve query performance?
⚠ Common exam trap
The trap here is conflating Multi-AZ with read scaling — candidates pick Multi-AZ thinking the standby serves reads, when only Read Replicas do that.
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
✓
Increase the instance size to provide more CPU and memory.
Option C is correct because a slow-performing RDS for MySQL instance is often constrained by CPU, memory, or IOPS, and vertically scaling to a larger instance class provides more vCPU, RAM, and baseline EBS throughput, which directly improves query execution and buffer pool caching. Option D is correct because enabling the MySQL slow query log (via the slow_query_log and long_query_time parameters in a custom parameter group) captures queries exceeding the threshold, letting the developer identify and then optimize the specific poorly performing SQL statements. Option A is not appropriate because deleting indexes generally hurts read performance and only marginally reduces write overhead, and unused indexes are not the typical cause of slow queries. Option B is wrong because Multi-AZ is a high-availability/failover feature that maintains a synchronous standby, not a read-scaling mechanism, so it does not improve read performance. Option E is wrong because purging binary logs only frees storage and does not address query performance, and it can break point-in-time recovery and replication.
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.
Go deeper
Related to this question
About these practice questions
One of 1,135 original DVA-C02 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Amazon Web Services exam blueprint
This DVA-C02 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the DVA-C02 exam.