DOP-C02 Auto Scaling activity history 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.

• ✗

  Ensure the scaling policy is configured to scale in

  Why it's wrong here

  A scale-in policy is designed to reduce capacity when demand drops (e.g., low CPU), and invoking it during a high-CPU condition would remove instances, directly worsening the shortage. The correct action is to investigate why the expected scale-out did not run—such as a misconfigured policy or a blocked launch—not to force the reverse operation. Thus, while you might eventually adjust the policy, 'ensuring it scales in' is factually counterproductive here.

• ✗

  Check the CloudWatch Logs for the instance

  Why it's wrong here

  CloudWatch Logs capture application output, system logs, and custom log streams from the EC2 instance; they do not record Auto Scaling lifecycle events, alarm transitions, or policy executions. To diagnose a failed scale-out, you need to inspect the Auto Scaling group’s activity history, which lists the status and reason for each scaling action. Checking logs would reveal application errors but cannot show whether the scaling policy was invoked or why it failed, so it is not the right diagnostic step.

• ✗

  Verify that the CloudWatch alarm is in INSUFFICIENT_DATA state

  Why it's wrong here

  The scenario states that the alarm received an alert, which in CloudWatch means the metric has breached the threshold and the alarm state is ALARM. INSUFFICIENT_DATA would indicate that there were not enough data points to evaluate the metric, contradicting the premise that CPU is high and the alert fired. Even if you verify the alarm state, you also need to see whether the ASG actually executed the scaling action, so this option is diagnostically incomplete and misleading.

• ✓

  Review the Auto Scaling group’s activity history in the EC2 console

  Why this is correct

  The Auto Scaling group’s activity history is the authoritative record of every scale-out and scale-in event, including the time, instance ID, reason code, and status (e.g., 'InProgress', 'Successful', or 'Failed'). By reviewing it, you can determine whether the CloudWatch alarm triggered the scaling policy, whether the capacity was blocked by the maximum instance limit, a service quota, or a launch template error. This directly shows why the instance did not receive the expected scale-out action, making it the correct first troubleshooting step.

Go deeper

Related to this question