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.

• ✗

  Stop and start the instance from the EC2 console.

  Why it's wrong here

  Stopping and starting the instance from the EC2 console initiates a normal shutdown; if the instance is completely unresponsive, the shutdown may hang and require a forced stop, but even then the same root volume and instance configuration are preserved, so any underlying corruption or resource exhaustion remains. Moreover, this manual operation does not update the Auto Scaling group's health status, and the group may ignore the manual state change or replace the instance anyway, making this action unreliable.

• ✗

  Create a new AMI from the instance and launch a replacement manually.

  Why it's wrong here

  Creating a new AMI from an unresponsive instance risks capturing a corrupted or inconsistent filesystem, especially without a clean shutdown, and the manual process of launching a replacement from that AMI is slow and error-prone. The Auto Scaling group already has a defined launch template and desired capacity, so a manually created instance would not automatically integrate with scaling policies or health checks, duplicating effort and potentially leaving the group in a confused state.

• ✓

  Terminate the instance and let the Auto Scaling group launch a new one.

  Why this is correct

  Terminating the instance is the correct action because it triggers the Auto Scaling group to detect the lost capacity through its health checks and immediately launch a fresh instance from the launch template, restoring the desired instance count automatically. This approach ensures the replacement is clean, conforms to the group's configuration, and avoids the downtime and statefulness of manual repair, making it the most efficient and reliable recovery mechanism.

• ✗

  Restore the instance from the most recent EBS snapshot.

  Why it's wrong here

  Restoring from the most recent EBS snapshot requires stopping or detaching the current root volume, creating a new volume from the snapshot, and reattaching it before attempting to boot, which is a lengthy manual procedure. Additionally, if the snapshot predates the unresponsiveness or contains the same misconfiguration or corrupted state, the instance will likely fail again, and this method completely bypasses the Auto Scaling group's automated replacement and health-check capabilities.

Go deeper

Related to this question