Examkin

Question

Difficulty: MediumCloudWatch Metrics and Alarms

A SysOps Administrator is setting up automated remediation for an Amazon EC2 instance. The administrator configures an Amazon CloudWatch alarm to monitor the `CPUUtilization` metric. The alarm has a period of 1 minute1\text{ minute} (60 seconds60\text{ seconds}) and is set to transition to the `ALARM` state if the CPU utilization exceeds 90%90\% for 33 consecutive evaluation periods. An Amazon EventBridge rule is configured to detect this alarm state transition and trigger an AWS Systems Manager (SSM) Automation runbook to restart the instance. During testing, the CPU utilization remains at 95%95\% for over 10 minutes10\text{ minutes}, but the alarm stays in the `INSUFFICIENT_DATA` state and the remediation runbook is never executed. What is the most likely cause of this issue, and how should it be resolved?

  1. The EC2 instance has standard monitoring enabled, which sends metrics to CloudWatch every 5 minutes5\text{ minutes}. The administrator must enable detailed monitoring on the instance to send metrics at 1 minute1\text{ minute} intervals.Answer
  2. B
    The EC2 instance is utilizing standard monitoring. The administrator must change the CloudWatch alarm period to 10 seconds10\text{ seconds} to force CloudWatch to pull CPU metrics from the instance at a higher rate.
  3. C
    The EventBridge rule is unable to receive triggers from CloudWatch. The administrator must configure the CloudWatch alarm to directly execute the Systems Manager Automation runbook as an alarm action without using EventBridge.
  4. D
    The Auto Scaling group cooldown period is preventing the instance state change from being evaluated. The administrator must decrease the cooldown period to allow the alarm to transition states within the 3 minute3\text{ minute} evaluation window.

Answer

The EC2 instance is using standard monitoring, which sends metrics to CloudWatch every 5 minutes. Enabling detailed monitoring on the instance will publish metrics at 1-minute intervals, providing the necessary data for the 1-minute alarm to evaluate properly.
The correct option correctly identifies that standard monitoring publishes CPU metrics at 5 minute5\text{ minute} intervals, which is insufficient for a 1 minute1\text{ minute} period alarm. Enabling detailed monitoring changes the reporting interval to 1 minute1\text{ minute}, allowing the alarm to evaluate properly and transition states.

Step-by-Step Solution

1
Analyze the reporting frequency of default EC2 metrics under standard monitoring.
Standard monitoring reports metrics every 5 minutes5\text{ minutes}.
This explains why a CloudWatch alarm with a 1 minute1\text{ minute} period lacks the data points needed to evaluate the metric, resulting in the `INSUFFICIENT_DATA` state.
2
Identify the configuration change required to increase metric granularity for EC2.
Detailed monitoring must be enabled on the target EC2 instance.
Enabling detailed monitoring changes the metric reporting frequency from 5 minutes5\text{ minutes} to 1 minute1\text{ minute} intervals, which matches the alarm period.
3
Verify the automated remediation trigger flow.
Confirm that the alarm transitions to `ALARM` state and successfully fires the EventBridge rule targeting the Systems Manager Automation runbook.
With data points arriving every minute, the alarm will now evaluate successfully and execute the configured remediation.

Key Concept

CloudWatch Standard vs. Detailed Monitoring Granularity
Rate this question

Topics

CloudWatch Metrics and Alarms

More questions from this topic