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.

• ✗

  Analyze slow query logs and optimize queries.

  Why it's wrong here

  Analyzing slow query logs and optimizing queries is a long-term performance-tuning measure that requires time to identify, test, and deploy query changes. It does not provide immediate relief for a CloudWatch alarm on high CPU utilization, especially if the workload is a steady high volume of traffic rather than a few inefficient queries. Even if query inefficiencies exist, the immediate operational priority is to restore headroom, and query optimization alone may be insufficient to address a sustained CPU saturation alarm.

• ✗

  Enable Multi-AZ deployment for failover.

  Why it's wrong here

  Enabling Multi-AZ deployment creates a standby replica in a different Availability Zone for high availability and automatic failover, but it does not share the active workload or increase compute capacity during normal operation. The standby does not process reads or writes until a failover occurs, so it cannot reduce the CPU load on the primary instance. A high CPU utilization alarm indicates resource exhaustion, not unavailability, and failing over to an identical standby would likely hit the same CPU bottleneck, making this option ineffective for the immediate scenario.

• ✓

  Modify the RDS instance to a larger instance class.

  Why this is correct

  Modifying the RDS instance to a larger instance class is the correct immediate response because it directly adds vCPU, memory, and often dedicated EBS bandwidth to handle the current workload. Amazon RDS supports scaling instance classes with minimal downtime, especially for Multi-AZ deployments where a failover masks the restart. This scale-up action provides the compute headroom needed to bring CPU utilization back to acceptable levels and is the standard first step when a CPU alarm indicates that the instance is simply undersized for the traffic.

• ✗

  Add a read replica to offload read traffic.

  Why it's wrong here

  Adding a read replica to offload read traffic only helps if the high CPU is driven by a high volume of SELECT queries that can be routed to the replica. It does not reduce the CPU cost of write operations, DDL, or complex transactions, which still execute on the primary instance. Furthermore, a read replica is not automatically used by the application; the application must be configured to direct read traffic to it, so simply creating one would not provide immediate relief unless the architecture already supports read routing.

Go deeper

Related to this question