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 the RDS error log for messages about connection timeouts or aborted connections.

  Why this is correct

  The RDS error log is the first place to look because it records 'Aborted connection' entries with explicit reasons such as 'Got timeout reading communication packets' or 'Client has exceeded the max_user_connections' when a reset occurs. These entries include the source host, user, and exact error code, which lets you determine whether the reset originates from the database server (e.g., idle timeout) or from the client side. This evidence directly confirms or rules out connection-level failures before you change any configuration or architecture.

• ✗

  Increase the max_connections parameter in the DB parameter group.

  Why it's wrong here

  Raising `max_connections` only helps if the reset is the result of the database rejecting new connections when the limit is reached—but the symptom here is *intermittent resets* of existing sessions, not a steady refusal of new ones. If the actual cause is CPU saturation, lock contention, or a network path that drops packets, adding more allowed connections can make things worse by increasing concurrency and memory pressure. Without checking `DBConnections` and `DatabaseConnections` CloudWatch metrics against the limit, this change is speculative and treats a symptom as a root cause.

• ✗

  Enable Multi-AZ deployment to provide a standby instance.

  Why it's wrong here

  Multi-AZ provides a separate standby instance solely for automatic failover during an Availability Zone outage or database maintenance, but during normal operation your application still connects to a single primary instance—so it has zero effect on connection resets caused by load, timeouts, or resource contention. In fact, failover events themselves force all existing connections to drop and require the application to reconnect with retry logic, which could *introduce* the exact kind of intermittent reset you are trying to fix. Implementing Multi-AZ is a durability/availability feature, not a connection-resilience feature.

• ✓

  Enable Performance Insights to analyze database load and find bottlenecks.

  Why this is correct

  Performance Insights gives you a time-series view of database load correlated across waits, SQL statements, and hosts, so you can see whether the connection resets coincide with a spike in a particular wait event like `innodb/log_write` or `CPU` or with a specific saturated query. This transforms an intermittent symptom into a measurable database load pattern, and you can drill down to the exact query or session causing the contention. Unlike static parameter changes, it provides direct evidence of the bottleneck that would force connections to be aborted.

• ✗

  Review the security group rules to ensure the application can connect.

  Why it's wrong here

  A security group is an allow-list attached to the RDS instance, and if it lacks a rule the connection would be *consistently* rejected from the start rather than failing intermittently after successful establishment. Because the application is working most of the time, the SG is demonstrably allowing traffic; the resets are more likely due to TCP-level keepalive timeouts, DB-side `wait_timeout`, or a proxy in between dropping idle sessions. Re-reviewing the rules would not provide any new data about when or why a connection is reset, so this step is a distraction from actionable diagnostics.

Go deeper

Related to this question