DVA-C02 Troubleshooting and Optimization Practice Question
A developer is troubleshooting a slow-running Amazon RDS for PostgreSQL instance. Which TWO metrics should the developer examine in Amazon CloudWatch to identify a possible resource bottleneck?
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
✓
CPUUtilization
High CPU utilization indicates a CPU bottleneck, which can slow down query processing. Option B is correct because high ReadIOPS and WriteIOPS accompanied by a high Average Queue Depth signal an I/O bottleneck, where the storage subsystem cannot keep up with requests. Option C is incorrect because FreeableMemory alone does not directly indicate a performance bottleneck; while low memory can cause issues, it is not a primary metric for resource bottlenecks. Option D is incorrect because NetworkThroughput is rarely a limiting factor for RDS performance; the database typically processes requests faster than network bandwidth constraints. Option E is incorrect because DatabaseConnections only indicates the number of connections, not a direct resource bottleneck; performance problems are better captured by CPU or I/O metrics.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
CPUUtilization
Why this is correct
When CPUUtilization is high, the database engine is busy executing queries, parsing SQL, and managing internal tasks, leaving little processing headroom for new operations. On an undersized RDS instance, consistent CPU saturation translates directly into slower query response times and even connection timeouts during peak load. This metric is the most direct signal that the instance's compute capacity is a limiting factor.
- ✓
ReadIOPS and WriteIOPS with high Average Queue Depth
Why this is correct
ReadIOPS and WriteIOPS measure the rate of storage I/O requests, but the key indicator of a storage bottleneck is a high Average Queue Depth, meaning I/O requests are spending time waiting in the EBS volume's queue. When the queue depth exceeds the volume's optimal I/O depth (often near 1 per 1,000 IOPS provisioned), latency rises significantly even if the raw IOPS number looks moderate. This condition indicates the storage layer cannot keep up with the workload, which is a distinct failure mode from CPU exhaustion.
- ✗
FreeableMemory
Why it's wrong here
FreeableMemory on RDS reports the OS-level free RAM, but database engines like InnoDB intentionally consume large cache and buffer pools, so a low value is often healthy and not a problem. Real performance degradation occurs only when memory scarcity forces the OS to swap or when the database cannot keep its working set in memory, causing extra physical reads. Instead of watching this metric alone, look at SwapUsage and the Buffer Cache Hit Ratio to determine whether memory is actually causing slowness.
- ✗
NetworkThroughput
Why it's wrong here
NetworkThroughput aggregates traffic between the RDS instance and its clients, and it is rarely the root cause of slow database performance because standard RDS instance types provide ample network bandwidth for typical OLTP workloads. Even when throughput is high, it is usually a consequence of large results being returned, not a constraint; the bottleneck lies in query execution or I/O. Unless the deployment spans regions or uses a small instance type with very modest networking, this metric should be low on the list of suspects.
- ✗
DatabaseConnections
Why it's wrong here
The DatabaseConnections metric becomes a bottleneck only when the current connection count approaches the instance's configured max_connections limit, at which point new connection attempts are rejected, causing application errors. Below that threshold, a large number of connections might indicate a badly tuned connection pool or leaked connections, but it does not by itself make queries slow. The right diagnostic is to compare active vs idle connections and track the error rate for 'too many connections'.
Go deeper
Related to this question
About these practice questions
One of 724 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 →
Same concept, more angles
1 more way 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.
Variation 1. A developer is troubleshooting a slow RDS MySQL instance. Which TWO metrics in Amazon CloudWatch should the developer examine first?
easy- A.NetworkReceiveThroughput
- B.SwapUsage
- ✓ C.CPUUtilization
- D.FreeStorageSpace
- ✓ E.ReadLatency
Why C: The correct metrics to examine first for a slow RDS MySQL instance are CPUUtilization and ReadLatency. High CPUUtilization indicates that the instance is under heavy load, possibly from inefficient queries or inadequate compute capacity. High ReadLatency suggests slow I/O, which could be due to disk contention or suboptimal queries. NetworkReceiveThroughput (A) is related to network traffic, not database performance. SwapUsage (B) is not typically a primary metric for RDS performance. FreeStorageSpace (D) indicates storage capacity but does not directly measure performance. Therefore, options C and E are the correct choices.
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
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.