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.

• ✓

  Check CloudWatch metrics for DatabaseConnections and CPUUtilization.

  Why this is correct

  This is the correct first step because CloudWatch provides two directly relevant metrics for an RDS for MySQL instance: DatabaseConnections shows the number of client sessions currently established, and CPUUtilization reflects aggregate CPU consumption. If DatabaseConnections spikes while CPUUtilization remains normal, the problem is connection exhaustion or a connection leak; if CPUUtilization also rises, it likely indicates heavy query load. These metrics give you a high-level, time-aligned picture of whether the symptom is connection-bound or compute-bound, which drives the next diagnostic step (e.g., enabling Performance Insights).

• ✗

  Immediately scale up the RDS instance to handle the load.

  Why it's wrong here

  Scaling up the instance size is a reactive mitigation that does not diagnose the root cause, and it can be expensive and time-consuming because a modification may require a reboot. The real issue could be a single poorly optimized query, a connection leak, or a parameter misconfiguration, none of which a larger instance would fix—though it might temporarily mask the symptom. Furthermore, scaling to a higher instance class increases compute but may not address constraints like max_connections, storage I/O, or a problematic query that still runs for the same duration.

• ✗

  Analyze VPC Flow Logs to identify the source IPs of connections.

  Why it's wrong here

  VPC Flow Logs capture metadata about network traffic, such as source/destination IPs, ports, and packet counts, but they do not expose database layer details like MySQL usernames, session IDs, or per-connection authentication outcomes. While they could reveal which IP addresses are reaching port 3306 on the RDS endpoint, they cannot show whether a connection is idle, active, or consuming CPU, nor can they identify the SQL statement being executed. For diagnosing database performance, you need RDS-specific telemetry (CloudWatch, Performance Insights, or the MySQL SHOW PROCESSLIST), not raw network flows.

• ✗

  Use the RDS console to view the number of active connections per user.

  Why it's wrong here

  The RDS Management Console provides instance-level metrics like current connections and, in some cases, the number of active sessions, but it does not give a per-user breakdown of connections. To see connections per MySQL user, you would need to query PERFORMANCE_SCHEMA tables such as threads or sessions, or run SHOW PROCESSLIST from an admin connection—neither of which is available through a console pane. Therefore, this option is not a valid diagnostic path because the console simply lacks the granularity to identify which user is consuming connections.

• ✓

  Enable Performance Insights and review the top SQL statements.

  Why this is correct

  Performance Insights is the correct second diagnostic step because it goes beyond aggregate metrics and shows database load broken down by SQL statement, waiting event, and client host. By reviewing the top SQL statements, you can identify a specific query that is consuming high CPU or locking resources, which may be causing connections to pile up. This target visibility lets you pinpoint a problematic query (e.g., a missing index or Cartesian join) and then tune it, rather than guessing at the cause from external metrics alone.

Go deeper

Related to this question