DOP-C02 CloudWatch Alarm Evaluation Periods Practice Question
A DevOps engineer is responsible for monitoring an AWS environment that includes multiple EC2 instances running a web application. The engineer needs to set up a solution that sends an email alert when the average CPU utilization across all instances exceeds 80% for 10 consecutive minutes. The engineer has created a CloudWatch alarm with the metric `CPUUtilization` aggregated across all instances using the statistic `Average` and a period of 5 minutes. The alarm is set to trigger when the metric exceeds 80% for 2 consecutive periods (10 minutes). The alarm's action is configured to send a notification to an Amazon SNS topic that has an email subscription. However, the engineer is not receiving the email alerts. The engineer verified that the SNS topic exists and the email subscription is confirmed. The CloudWatch alarm shows that the metric value exceeded the threshold for 2 periods, but the alarm state is still 'OK'. What is the MOST likely reason for this?
⚠ Common exam trap
A common trap is assuming that if the metric graph shows the threshold exceeded, the alarm should trigger. However, the alarm evaluates based on the number of data points as configured, not on the visual representation. Missing data points can prevent the alarm from transitioning to ALARM.
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
✓
The CloudWatch alarm requires 2 consecutive evaluation periods with the metric exceeding the threshold, but the alarm is still evaluating because of insufficient data points.
CloudWatch alarms evaluate based on the number of data points in the evaluation period. For a 'M out of N' alarm, if the metric is published every 5 minutes, after two periods there are exactly two data points. However, if there are any missing data points (e.g., due to instances not reporting), the alarm may not have sufficient data to evaluate and will remain in 'INSUFFICIENT_DATA' or 'OK'. The fact that the metric displayed exceeded the threshold does not guarantee the alarm used the correct statistic; the alarm's statistic is 'Average' across instances, which can be affected by missing or delayed data. The most likely reason is insufficient data points for evaluation, causing the alarm to stay in 'OK'.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The email subscription is not confirmed.
Why it's wrong here
Incorrect. An unconfirmed email subscription would only prevent SNS email delivery, not affect how CloudWatch evaluates metrics. The alarm's state machine is driven by metric data points and evaluation periods, not by the subscription status of an endpoint. Because the subscription is already confirmed, this explanation is invalid for the observed alarm behavior.
- ✗
The metric `CPUUtilization` is not being published to CloudWatch.
Why it's wrong here
Incorrect. If no CPU utilization data were being published to CloudWatch, the alarm would show a state of INSUFFICIENT_DATA, not OK. The fact that the alarm has seen values exceed the threshold shows that at least some data points arrived, so the metric is indeed being published. The problem is not a total absence of data but rather gaps in the data stream during the consecutive evaluation windows.
- ✓
The CloudWatch alarm requires 2 consecutive evaluation periods with the metric exceeding the threshold, but the alarm is still evaluating because of insufficient data points.
Why this is correct
Correct. A CloudWatch alarm configured for 2 consecutive evaluation periods only triggers ALARM when the metric breaches the threshold in every period of that window. With missing data points, especially if a stopped instance stops reporting CPUUtilization, the alarm cannot complete two full consecutive breach periods. Depending on the 'treat missing data as' setting (default: missing, not breaching), the alarm remains in OK rather than transitioning, because insufficient data points prevent the evaluation from concluding a continuous breach.
- ✗
The SNS topic is not configured to allow CloudWatch to publish to it.
Why it's wrong here
Incorrect. The SNS topic's resource policy is independent of the alarm's metric evaluation logic. Even if CloudWatch lacked permission to publish to the topic, the alarm would still evaluate CloudWatch metric data and transition to ALARM; only the notification delivery would fail. Since the alarm remains in OK, this cannot be the cause, and SNS configuration has no bearing on consecutive period evaluation or data point sufficiency.
Go deeper
Related to this question
About these practice questions
Courseiva writes every DOP-C02 question from scratch — 1,013 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or 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.