DOP-C02 Practice Question 8: EventBridge SSM Automation Remediation

Systems Manager Automation is purpose-built for multi-step operational runbooks: each step is recorded with its inputs, outputs, and status, and the execution history is retained and queryable, which is what the audit requirement is asking for. EventBridge supports an SSM Automation runbook directly as a rule target, so a CloudWatch alarm state-change event triggers it with no intermediate compute. Two IAM roles are involved and both matter: the rule's target role needs ssm:StartAutomationExecution plus iam:PassRole on the AutomationAssumeRole, and the AutomationAssumeRole is what Automation itself assumes to act on the instance.

Option A introduces an unnecessary and fragile hop through SNS to an HTTPS endpoint the team must now operate and secure. A single SendCommand shell script also collapses six auditable steps into one opaque script whose per-step outcomes are not individually recorded.

Option B replaces event-driven response with polling, adding up to five minutes of latency to every incident and running needlessly the rest of the time. Run Command executes commands on instances but has no notion of a multi-step workflow with branching or per-step output the way Automation does.

Option C uses the wrong service for the trigger. AWS Config evaluates *resource configuration* compliance; disk utilization inside a guest OS is a runtime metric, not a configuration item, so there is nothing for a Config rule to evaluate. Config remediation is also driven by configuration-change or periodic evaluations, not by an alarm firing.

Reference: Run automations based on EventBridge events