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.

• ✗

  Terminate the instance and launch a new one from the latest AMI.

  Why it's wrong here

  Terminating the instance is a destructive, irreversible action that strips away the ability to perform root-cause analysis: the OS logs, application traces, and any in-memory evidence on the instance's ephemeral storage are lost. Launching from the latest AMI also does not guarantee that the defect that caused the incident is not baked into that AMI or user-data script, potentially reproducing the failure. An AMI replacement is a recovery step that should only be taken after you have already collected system logs and CloudWatch Logs, not as the first diagnostic action.

• ✓

  Review the EC2 instance system log and CloudWatch Logs for error messages.

  Why this is correct

  The EC2 system log (console output) is a hypervisor-accessible snapshot of the instance's serial port, capturing kernel panics, OOM killer events, and boot-time failures that may be invisible from inside the OS. Pairing that with CloudWatch Logs—where the CloudWatch agent streams Apache, Nginx, or custom application errors—gives you a non-disruptive, evidence-based starting point to pinpoint whether the web service stopped due to memory exhaustion, a crashed process, or an external dependency. These sources are available via the EC2 console or the get-console-output CLI call and require no downtime, making them the correct first step for diagnosis.

• ✗

  Restart the EC2 instance immediately to restore service.

  Why it's wrong here

  Rebooting the EC2 instance without first capturing diagnostic evidence destroys volatile state, including /var/log messages stored in tmpfs, process core dumps, and the exact state of threads at the moment of failure. It also merely restarts the same software stack on the same root volume, so unless the root cause was a transient stale handle or a hung process, the outage will likely recur. Moreover, a blind restart can mask intermittent issues and make it impossible to correlate the failure with CloudWatch metrics time series, turning an incident into a recurring mystery.

• ✗

  Create a new CloudWatch alarm with a lower threshold to get alerted quicker next time.

  Why it's wrong here

  Adjusting or adding CloudWatch alarm thresholds is a monitoring optimization, not a diagnostic action, and it does nothing to reveal why the current web instance stopped responding. A lower threshold might have fired the alarm earlier, but it would have shown the same symptom without telling you whether the cause was CPU starvation, a memory leak, or a deadlocked application thread. Overly sensitive alarms can also lead to alert fatigue, and the correct next step for the current incident is to inspect system logs and CloudWatch Logs rather than configure future notifications.

Go deeper

Related to this question