SOA-C02 Monitoring, Logging, and Remediation Practice Question

Exhibit

Refer to the exhibit.

CloudWatch Alarm configuration:
{
  "AlarmName": "HighCPU",
  "AlarmDescription": "Alarm if CPU exceeds 90% for 5 minutes",
  "MetricName": "CPUUtilization",
  "Namespace": "AWS/EC2",
  "Statistic": "Average",
  "Period": 60,
  "EvaluationPeriods": 5,
  "Threshold": 90,
  "ComparisonOperator": "GreaterThanThreshold",
  "AlarmActions": ["arn:aws:sns:us-east-1:123456789012:MyTopic"]
}

Refer to the exhibit. A SysOps administrator creates the CloudWatch Alarm shown. However, the alarm never enters ALARM state even though the CPU utilization of the EC2 instance is consistently above 90%. What is the most likely reason?

⚠ Common exam trap

The trap here is that candidates focus on tuning threshold or evaluation periods, overlooking the fundamental requirement that CloudWatch alarms must include the correct dimensions to match the metric data stream.

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 is missing the InstanceId dimension.

The alarm never enters ALARM state because it is missing the required `InstanceId` dimension. CloudWatch metrics for EC2, such as `CPUUtilization`, are published with the `InstanceId` dimension to uniquely identify the data stream. Without specifying this dimension in the alarm configuration, CloudWatch cannot match the alarm to the metric data emitted by the EC2 instance, so the alarm remains in INSUFFICIENT_DATA or OK state regardless of actual CPU usage.

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 missing the InstanceId dimension.
Why this is correct
A CloudWatch EC2 metric such as CPUUtilization is published with an InstanceId dimension, and the metric name alone is ambiguous because multiple instances in the account can have similar CPU data. Without the InstanceId dimension, the alarm cannot select the specific instance's metric stream; in practice, the alarm will either fail validation or remain in INSUFFICIENT_DATA because no datapoints match the metric signature. Adding the InstanceId dimension scopes the alarm to the instance shown in the exhibit, which lets CloudWatch evaluate that instance's CPU utilization against the threshold.
✗
The threshold is set too high; it should be 80%.
Why it's wrong here
The alarm threshold is already set to 90% while the exhibited CPU utilization is above that level for consecutive periods, so the threshold is not what prevents the alarm from firing. Lowering the threshold to 80% would not help because the alarm is not actually evaluating the instance's metric at all—there is no InstanceId dimension to identify the data stream. A metric without a dimension is either an invalid reference or an aggregate that does not reflect the instance's high CPU. Therefore, changing the numeric threshold has no effect on the alarm state.
✗
The evaluation periods are too few.
Why it's wrong here
With a period of 1 minute and 5 evaluation periods, the alarm is correctly configured to require 5 consecutive datapoints above the threshold before it transitions to ALARM, which is a sensible way to filter out brief CPU spikes. Increasing the evaluation periods would actually make the alarm wait longer before triggering, not faster, so it would not solve the reported issue. Even with one evaluation period, the alarm would still remain in INSUFFICIENT_DATA or OK because it is not attached to the instance-specific CPUUtilization metric. The number of evaluation periods is irrelevant when the metric's InstanceId dimension is missing.
✗
The statistic should be Maximum instead of Average.
Why it's wrong here
Both Average and Maximum are valid CloudWatch statistics for CPUUtilization, and using Average over a 1-minute period is a perfectly reasonable choice for detecting sustained high load. The exhibit shows the average CPU above 90%, so if the alarm were correctly dimensioned, an Average statistic of 90% would trigger after enough consecutive periods. Switching to Maximum would make the alarm more sensitive to occasional spikes but would not fix the missing InstanceId dimension that prevents the alarm from evaluating the instance's data. The statistic selection is unrelated to the root cause of missing the instance dimension.

Go deeper

SOA-C02 Monitoring, Logging, and Remediation Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question