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 instance's system logs in CloudWatch Logs to identify the root cause

  Why it's wrong here

  While system logs can reveal underlying causes such as kernel panics or out-of-memory events, retrieving and analyzing them from CloudWatch Logs is a post-incident diagnostic step that extends downtime. The immediate priority is to restore service availability; root-cause analysis should follow after the instance is operational again, not before initiating recovery.

• ✗

  Create an AMI of the instance and launch a new instance from that AMI

  Why it's wrong here

  Creating an AMI captures the current instance's configuration and data, but the process involves snapshotting EBS volumes and registering the image, which can take minutes and does nothing to fix the underlying issue on the existing instance. Launching a replacement from that AMI also incurs boot and initialization delays, so this approach is better suited for disaster recovery or scaling rather than rapid response to an unresponsive web application.

• ✓

  Reboot the EC2 instance from the AWS Management Console or CLI

  Why this is correct

  A graceful reboot via the AWS Management Console or CLI sends an ACPI reboot signal to the guest OS, which restarts the operating system and all application processes while preserving the instance ID, private IP, EBS volumes, and attached Elastic IP. This is the fastest and least disruptive recovery action for transient conditions like memory leaks or a stuck process, and it typically resolves the issue within minutes without requiring reconfiguration.

• ✗

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

  Why it's wrong here

  Terminating the instance issues a shutdown and then deletes the underlying compute resources; any instance-store data vanishes immediately, and EBS volumes are usually deleted because the DeleteOnTermination attribute defaults to true for root volumes. Launching a fresh instance from an AMI also changes the instance ID and private IP, which can break DNS records, application configs, and security group references, while the rebuild and warm-up time extends the outage. This is an irreversible, last-resort action after confirming the instance is irrecoverable, not the first step for a transient web server issue.

Go deeper

Related to this question