Examkin

Question

Difficulty: Very hardCloudWatch Metrics and Alarms

A SysOps Administrator is designing an automated remediation workflow for a batch-processing application running on Amazon EC2 instances. The application publishes a custom metric named `QueueBacklogDepth` to Amazon CloudWatch at 1-minute intervals. The administrator wants to automatically execute the `AWS-RestartEC2Instance` Systems Manager (SSM) Automation runbook if the backlog depth exceeds 1,000 messages for a duration of 15 minutes.

The administrator configures a CloudWatch alarm for the `QueueBacklogDepth` metric with a threshold of 1,000, a period of 5 minutes (300 seconds), and evaluation periods of 3. During testing, the queue backlog depth exceeds 1,000 for 20 minutes, and the alarm state successfully transitions to ALARM, but the SSM Automation runbook fails to run.

How should the administrator resolve this issue to ensure the remediation workflow executes successfully?

  1. Create an Amazon EventBridge rule that triggers on a CloudWatch Alarm State Change event for this alarm to invoke the Systems Manager Automation runbook as the target.Answer
  2. B
    Enable detailed monitoring on the EC2 instances hosting the application to allow CloudWatch to receive and evaluate the custom metric at the 1-minute resolution required by the evaluation period configuration.
  3. C
    Configure the Systems Manager Automation runbook as a subscription endpoint on an Amazon SNS topic, and update the CloudWatch alarm actions to publish to that SNS topic.
  4. D
    Reduce the Auto Scaling group cooldown period to be less than the 15-minute evaluation window to prevent the alarm actions from being suppressed.

Answer

Create an Amazon EventBridge rule that triggers on a CloudWatch Alarm State Change event for this alarm to invoke the Systems Manager Automation runbook as the target.
The correct answer is to create an Amazon EventBridge rule that triggers on a CloudWatch Alarm State Change event to invoke the Systems Manager Automation runbook. CloudWatch metric alarms cannot natively invoke Systems Manager Automation runbooks as a direct action. Because CloudWatch publishes state changes to EventBridge, using an EventBridge rule to match the specific alarm transitioning to the ALARM state and targeting the runbook is the standard, event-driven pattern for this scenario.

Step-by-Step Solution

1
Analyze the native targets of Amazon CloudWatch alarm actions.
Identify that CloudWatch alarms can natively send notifications to SNS, execute Auto Scaling actions, or invoke EC2 actions (such as reboot, stop, terminate, or recover). They cannot directly target SSM Automation runbooks.
This establishes why the initial configuration failed to execute the runbook even though the alarm transitioned to the ALARM state.
2
Determine the proper integration path between CloudWatch alarms and SSM Automation.
Identify that CloudWatch Alarm State Change events are published to Amazon EventBridge. EventBridge can route these events directly to Systems Manager Automation as a target.
This creates the event-driven bridge required to execute the remediation workflow without modifying the application code.
3
Verify custom metric resolution requirements.
Confirm that custom metrics published via the PutMetricData API are separate from EC2 instance metrics, meaning EC2 detailed monitoring is not required for custom metrics evaluation.
This rules out standard vs. detailed monitoring configurations as the cause of the failure.

Key Concept

CloudWatch Alarm Actions and Event-Driven Remediation with EventBridge
Estimated Time:3m 0s
Rate this question

Topics

CloudWatch Metrics and Alarms

More questions from this topic