SOA-C02 Monitoring, Logging, and Remediation Practice Question

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 in the 'OK' state and not 'INSUFFICIENT_DATA'.

  Why it's wrong here

  If the alarm were in the INSUFFICIENT_DATA state, it would indicate that CloudWatch lacked enough metric samples to evaluate the threshold—often due to missing data or down instances. However, an OK state means CloudWatch is receiving valid CPUUtilization data and evaluating it successfully. The real reason the alarm isn't firing is that the metric must remain above 80% for two consecutive 5-minute evaluation periods, and short spikes don't satisfy that sustained-breach condition.

• ✗

  The CPUUtilization metric is not enabled by default for EC2 instances.

  Why it's wrong here

  EC2 CPUUtilization is always available and published to CloudWatch at no additional charge for all instances, regardless of the operating system or instance type. With basic monitoring, the metric is reported every 5 minutes; with detailed monitoring, it is reported every 1 minute. Therefore, the metric is certainly enabled and present, so the absence of this alarm cannot be attributed to a missing metric. The failure to trigger must be caused by the alarm's evaluation logic requiring sustained high utilization over multiple periods.

• ✓

  The CPU utilization spikes above 80% for less than 10 minutes at a time.

  Why this is correct

  This is correct because CloudWatch alarms evaluate a metric against the threshold over a specified number of consecutive periods. If the alarm is configured with a period of 5 minutes and evaluation periods of 2, the CPU utilization must exceed 80% for the entire 10-minute span covered by two consecutive data points. When the CPU spikes above 80% for less than 10 minutes, it never passes two full evaluation periods, so the alarm state remains OK. Thus, short-lived spikes, even if severe, will not trigger the alarm.

• ✗

  The alarm period is set to 5 minutes, but the metric is reported every 1 minute.

  Why it's wrong here

  The alarm period defines the time window over which each data point is aggregated, and a period of 5 minutes is perfectly compatible with metric data arriving every 1 minute—CloudWatch simply aggregates the 1-minute samples into a 5-minute average. The mismatch between period and metric reporting frequency is not the cause of the failure. Rather, the problem is that the alarm requires two consecutive periods of breach, so even though fresh data is arriving every minute, the sustained 10-minute threshold is not met.

Go deeper

Related to this question