DOP-C02 Monitoring and Logging Practice Question
A company runs an Auto Scaling group of EC2 instances that publish custom application metrics to CloudWatch using the PutMetricData API. During a traffic spike, the operations team reports that alarms based on these metrics did not trigger even though application error rates rose sharply. The metrics are published with a one-minute resolution. Which action should a DevOps engineer take to make the alarms respond reliably during spikes?
⚠ Common exam trap
The trap here is responding to a missed alarm by widening the evaluation period, when that averaging actually makes the spike harder to detect.
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
✓
Publish the custom metrics as high-resolution metrics and configure the alarm with a shorter evaluation period and M-out-of-N datapoints to alarm.
Custom metrics published at standard one-minute resolution can lag behind a fast spike, and a long evaluation window dilutes the signal. Publishing high-resolution metrics and configuring the alarm with a short evaluation period plus M-out-of-N datapoints to alarm lets the alarm react quickly to a genuine error-rate increase.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Change the alarm statistic to SampleCount and set the period to 60 seconds.
Why it's wrong here
SampleCount reports the number of data points, not the error rate, so an alarm on SampleCount would fire on traffic volume rather than on errors. It does not address the underlying issue of sparse or delayed custom metric publication during a spike.
- ✗
Configure the alarm to treat missing data as breaching and shorten the evaluation period.
Why it's wrong here
Treating missing data as breaching can cause false positives when instances are simply replaced or temporarily not reporting. It masks the real problem, which is that the custom metrics are not being aggregated at the granularity and timing the alarm expects.
- ✓
Publish the custom metrics as high-resolution metrics and configure the alarm with a shorter evaluation period and M-out-of-N datapoints to alarm.
Why this is correct
High-resolution metrics allow one-second granularity, and combining a short evaluation period with M-out-of-N datapoints to alarm makes the alarm evaluate recent error data quickly. This directly addresses the delay and sparsity of custom metrics during rapid spikes, improving alarm responsiveness.
- ✗
Increase the alarm's evaluation period to five minutes so more data points are averaged together.
Why it's wrong here
A longer evaluation period averages more data and further smooths the spike, making the alarm even less likely to trigger promptly. The team needs faster detection, not a wider averaging window that dilutes the error signal.
Go deeper
Related to this question
About these practice questions
This DOP-C02 question is part of Courseiva's 1,298-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 and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Amazon Web Services exam blueprint
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.