DOP-C02 Incident and Event Response 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 Enhanced Monitoring to check OS-level metrics

  Why it's wrong here

  Enhanced Monitoring provides OS-level visibility into the underlying EC2 instance's CPU, memory, disk I/O, and file system usage, but it does not expose the database's connection count or the max_connections limit. While OS metrics can help detect resource contention, the problem here is connection saturation, which is a database-layer concurrency limit rather than an OS-level resource shortage. Monitoring OS-level metrics would add overhead and delay diagnosis, when a direct CloudWatch metric already exists for this exact purpose.

• ✗

  Examine the slow query log to identify long-running queries

  Why it's wrong here

  Examining the slow query log targets query execution performance, such as missing indexes or inefficient joins, but the symptom is connection timeouts that occur before queries are accepted. With normal CPU and memory utilization, long-running queries are unlikely to be the root cause, as they would manifest as resource exhaustion. Furthermore, the slow query log does not reveal the current connection count or how close it is to the max_connections ceiling, so it cannot diagnose connection saturation.

• ✗

  Verify that the DB instance's storage is not full

  Why it's wrong here

  A full storage volume on an RDS instance leads to write failures, 'Insufficient storage' errors, or the instance transitioning to read-only state, but it does not prevent the database from accepting new connections. In fact, even with zero free storage, the database can still receive and process incoming connection attempts until storage is completely exhausted. The symptom described is intermittent connection timeouts, not write errors or disk-full messages, so checking storage is tangential and misses the actual connection limit issue.

• ✓

  Check the 'DatabaseConnections' CloudWatch metric to see if the connection count is near the max_connections limit

  Why this is correct

  The DatabaseConnections CloudWatch metric directly tracks the number of client connections currently established to the RDS instance, and when this value approaches the max_connections parameter, the server begins rejecting or timing out new connection attempts. This pattern perfectly matches the symptom of intermittent connection timeouts while CPU and memory remain normal, because the connection ceiling is a hard limit unaffected by resource utilization. Comparing this metric against the configured max_connections (from the parameter group) confirms whether connection exhaustion is the cause.

Go deeper

Related to this question