Courseiva

DOP-C02 Incident and Event Response Practice Question

Network Topology
$ aws cloudwatch describe-alarmsalarm-names "HighCPUAlarm"Refer to the exhibit.```"MetricAlarms": ["AlarmName": "HighCPUAlarm","AlarmArn": "arn:aws:cloudwatch:us-east-1:123456789012:alarm:HighCPUAlarm","AlarmConfigurationUpdatedTimestamp": "2023-03-15T10:00:00.000Z","StateValue": "ALARM","MetricName": "CPUUtilization","Namespace": "AWS/EC2","Statistic": "Average","Period": 300,"EvaluationPeriods": 1,"Threshold": 90.0,"ComparisonOperator": "GreaterThanOrEqualToThreshold","Dimensions": ["Name": "InstanceId","Value": "i-0abcd1234efgh5678"

A DevOps engineer observes the CloudWatch alarm output shown in the exhibit. The alarm is in ALARM state for instance i-0abcd1234efgh5678. The engineer checks the EC2 console and sees that the instance's CPU utilization is currently 10%. What is the MOST likely explanation?

⚠ Common exam trap

DOP-C02 often tests the misunderstanding that CloudWatch alarms change state immediately when the metric value changes, but they actually require multiple datapoints and evaluation periods to transition, leading candidates to incorrectly blame misconfiguration or missing metrics.

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 alarm has not yet evaluated enough low datapoints to change state

CloudWatch alarms evaluate metrics over a specified number of datapoints and periods. Even if the current CPU utilization is 10%, the alarm may still be in ALARM state because it has not yet evaluated enough consecutive low datapoints to transition to OK. The alarm state changes only after the configured number of evaluation periods and datapoints breach or recover from the threshold.

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 alarm is misconfigured with wrong metric

    Why it's wrong here

    The alarm is not misconfigured with the wrong metric. The alarm is explicitly wired to the CPUUtilization metric, and the metric data shown in the alarm output confirms the observed value is rising to 100%. The spike is actually visible in the alarm graph, so the metric being monitored is indeed producing the data that triggered the alarm. Recommending a different metric would not address the root cause, which is that the alarm is in ALARM state and waiting for consecutive OK datapoints.

  • ✗

    The threshold was set too low

    Why it's wrong here

    The threshold is not set too low; it is set to 90%, and the observed CPU utilization spiked to 100%. Even if the threshold were raised (the metric is correctly emitted and the value exceeded the threshold), the current state would still be ALARM because the threshold breach actually occurred. A low threshold would cause false positives, but here the alarm correctly reflects a real spike. The reason it remains in ALARM is not the threshold level but the lack of consecutive low datapoints to clear the alarm state.

  • ✓

    The alarm has not yet evaluated enough low datapoints to change state

    Why this is correct

    For a CloudWatch alarm to transition from ALARM to OK, it must evaluate a specified number of consecutive periods where the metric is below the threshold (e.g., 3 of 3 datapoints below 90%). After the CPU spike dropped back down, the alarm has only recently started seeing low datapoints; until enough consecutive okay datapoints are evaluated, the alarm state remains ALARM. This is CloudWatch's default state-transition behavior to avoid flapping, not a misconfiguration.

  • ✗

    The CPUUtilization metric is not being emitted

    Why it's wrong here

    The CPUUtilization metric is definitely being emitted; the alarm output clearly shows a datapoint of 100% and the graph displays the metric values. If the metric were not being emitted, CloudWatch would show a lack of data, and the alarm would transition to INSUFFICIENT_DATA, not ALARM. Since the alarm is in ALARM state with a 100% datapoint, the metric stream is healthy, and the missing-data handling is not a factor.

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 →

How Courseiva writes practice questions · Editorial policy

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.