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.

• ✓

  Review AWS CloudTrail logs for TerminateInstances API calls.

  Why this is correct

  AWS CloudTrail is the authoritative source for who, when, and how an EC2 instance was terminated: every StopInstances/TerminateInstances API call is recorded as an event with the IAM user or role, source IP, user agent, and request parameters. Console clicks, CLI commands, SDK calls, and automated actions by services such as Auto Scaling or AWS Lambda all generate a TerminateInstances event. Reviewing CloudTrail event history or querying the CloudTrail S3 bucket with Athena reveals the entity that issued the termination and any accompanying error or access-denied information.

• ✗

  Look at the EC2 console's 'Termination Protection' setting.

  Why it's wrong here

  Termination protection is a per-instance attribute that blocks accidental deletion by preventing a TerminateInstances call from succeeding, but it does not record or persist any reason for a terminated instance. Checking its current state only reveals whether the attribute was enabled at the moment of inspection, which can change after the fact. If the instance was terminated despite protection being enabled, the relevant evidence is the CloudTrail event showing the caller first performed ModifyInstanceAttribute to disable protection, not the console toggle itself.

• ✗

  Check the application logs on the instance's attached EBS volume (detached and attached to another instance).

  Why it's wrong here

  The root EBS volume of a terminated instance may be detached and attached to a fresh instance, but application logs capture only what the software wrote while the operating system was running, such as application errors, kernel panics, or shutdown messages. These logs cannot capture AWS control-plane API calls, and a hard API termination may not give the guest OS an opportunity to write a meaningful shutdown reason before the instance is torn down. Retrieving the volume tells you nothing about who invoked the termination because that information lives exclusively in CloudTrail, not in the guest filesystem.

• ✗

  Verify the Auto Scaling group's scaling policies and scheduled actions.

  Why it's wrong here

  Auto Scaling scaling policies can terminate instances, but they only apply to instances that are part of an Auto Scaling group, and the policies themselves are triggers, not the source of a TerminateInstances event. If the instance is not a managed member of an ASG, these policies are irrelevant; even when it is, the ASG makes the termination call through an IAM role, and that call appears in CloudTrail. A scaling-in or health-check replacement would be correlated with CloudWatch alarms or lifecycle hooks, but an unexpected termination could be caused by any other principal, so this check alone cannot determine the root cause.

Go deeper

Related to this question