DOP-C02 Incident and Event Response Practice Question
A company uses an Auto Scaling group with a dynamic scaling policy based on a custom CloudWatch metric. After a recent deployment, the metric spikes unexpectedly, causing the Auto Scaling group to launch several EC2 instances. The operations team wants to quickly determine whether the spike was caused by a real load increase or a deployment issue. What is the MOST efficient way to investigate this?
⚠ Common exam trap
Candidates often confuse monitoring scaling actions (SNS/CloudTrail) with diagnosing the metric's root cause, overlooking that application logs provide the direct evidence needed to distinguish real load from deployment issues.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Use CloudWatch Logs Insights to query application logs for error patterns or deployment markers that coincide with the metric spike.
CloudWatch Logs Insights allows you to query application logs for error patterns or deployment markers (e.g., new version tags, exception stack traces) that coincide with the metric spike. This directly correlates the scaling event with application-level evidence, enabling rapid root-cause analysis without altering infrastructure or relying on indirect notifications.
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 SNS topic that the scaling policy publishes to for notifications.
Why it's wrong here
Checking the SNS topic that the scaling policy publishes to will only deliver scaling lifecycle notifications or activity notifications indicating that a scaling action occurred. These notifications contain the policy name and the new/old desired capacity, but they never include the underlying application metric data or the reason the metric spiked. Without application-level telemetry, such as error rates, request latencies, or deployment markers, you cannot determine the root cause from SNS alone.
- ✓
Use CloudWatch Logs Insights to query application logs for error patterns or deployment markers that coincide with the metric spike.
Why this is correct
CloudWatch Logs Insights lets you run SQL-like queries against application logs stored in CloudWatch Logs, allowing you to filter for specific error codes, exception stack traces, or deployment markers that align with the exact timestamp of the metric spike. By correlating log timestamps with the scaling activity, you can identify events like a failed code release, a dependency outage, or a traffic surge that pushed the metric above the alarm threshold. This is the only option that gives access to application-level evidence needed to diagnose the upstream cause of the spike.
- ✗
Use AWS CloudTrail to review API calls that modified the scaling policy.
Why it's wrong here
AWS CloudTrail records API calls made by users, roles, or services, including calls that modify the scaling policy such as PutScalingPolicy or UpdateAutoScalingGroup. However, it does not capture application-level performance metrics or errors that would explain a sudden spike in load, and it is irrelevant if the policy definition has not been changed. Unless someone deliberately altered the policy thresholds or targets, CloudTrail will show no relevant events to investigate.
- ✗
Temporarily disable the scaling policy and manually increase the desired capacity to handle the load.
Why it's wrong here
Temporarily disabling the scaling policy and manually increasing desired capacity is a reactive mitigation that addresses the symptom, not the root cause. This action does not generate any diagnostic data, and it may even mask the issue by absorbing the load without revealing what caused the spike. It also risks leaving manual capacity in place after the spike subsides, leading to overprovisioning or conflicting with the dynamic scaling policy's target values.
Go deeper
Related to this question
About these practice questions
This DOP-C02 question is part of Courseiva's 1,013-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This DOP-C02 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the DOP-C02 exam.