Event-driven auto-remediation with EventBridge and SSM Automation runbooks
When something breaks or drifts, the event is the trigger and the runbook is the fix. No human clicks required.
Detect, route, remediate
Event-driven auto-remediation has three moving parts. First a detection signal fires: a CloudWatch alarm changes to ALARM state, GuardDuty raises a finding, an EC2 instance changes state, or AWS Config marks a resource NON_COMPLIANT. Second, the signal is routed: an Amazon EventBridge rule matches the event pattern and picks a target. Third, the remediation runs: the target is an AWS Systems Manager Automation runbook (an Automation document) whose steps perform the corrective action, such as restarting an instance, isolating a security group, or releasing an unattached Elastic IP.
The operator is not in the loop. The fix happens in seconds because the event, not a human, is the trigger. That is the whole point of the pattern: turn an alarm or a compliance failure straight into an action.
Event-driven auto-remediation: detect, route, run the runbook
Trace
Detection signals (a CloudWatch alarm state change, a GuardDuty finding, an EC2 state-change) are emitted as events. An EventBridge rule matches the event pattern and starts an SSM Automation runbook as its target, using an EventBridge service role to invoke it. The runbook executes its steps under a separate AutomationAssumeRole with least-privilege permissions, performs the corrective action on the resource, and notifies operators through SNS. AWS Config takes a parallel path: a Config rule marks a resource noncompliant and its remediation action runs an SSM Automation document directly, without going through EventBridge.
Wiring an EventBridge rule to an SSM Automation runbook
An EventBridge rule has two halves: an event pattern that decides which events match (for example source aws.ec2 and detail-type 'EC2 Instance State-change Notification'), and a target that decides what runs. When the target is Systems Manager Automation, you choose the runbook and pass its parameters, including the instance ID or resource ID the runbook should act on.
Two distinct IAM roles are involved and the exam likes to test the difference. The EventBridge rule needs a service role that grants EventBridge permission to invoke (start) the automation. Separately, the runbook itself runs under an AutomationAssumeRole passed as a parameter; this is the identity whose permissions the runbook's steps actually use to touch resources. Keep the AutomationAssumeRole least privilege: it should allow only the specific actions the corrective steps need, not broad admin.
Wiring an EventBridge rule to an SSM Automation runbook (the two-role split)
Trace
An EventBridge rule has two halves: an event pattern that decides which events match, and a target that decides what runs. When the target is Systems Manager Automation you choose the runbook and pass parameters (the instance/resource ID, plus the AutomationAssumeRole). Two distinct IAM roles are involved: an EventBridge service role grants EventBridge permission to start the automation, while a separate AutomationAssumeRole (passed as a parameter, kept least privilege) is the identity whose permissions the runbook's steps actually use to touch resources.
Managed runbooks versus writing your own
AWS ships a library of managed Automation runbooks for common fixes, with names like AWS-StartEC2Instance, AWS-StopEC2Instance, and AWS-RestartEC2Instance, plus a family of AWSConfigRemediation-* documents for compliance fixes. Reach for a managed runbook before writing code: it is already documented, versioned, and maintained by AWS, and it slots straight into an EventBridge target or a Config remediation action with no Lambda function to build or patch.
Write a custom runbook only when no managed document matches. A runbook is itself a document of ordered steps (aws:executeAwsApi, aws:runCommand, aws:branch, and so on), so most fixes are declarative steps rather than general-purpose code. This is why 'wire an alarm to a documented remediation' points to EventBridge plus Automation rather than 'write a Lambda function' on the exam.
Managed runbooks vs writing your own
Trace
AWS ships a library of managed Automation runbooks for common fixes (AWS-StartEC2Instance, AWS-StopEC2Instance, AWS-RestartEC2Instance, and the AWSConfigRemediation-* family). Reach for a managed runbook first: it is documented, versioned, and maintained by AWS, and it slots straight into an EventBridge target or a Config remediation action with no Lambda to build or patch. Write a custom runbook only when no managed document matches; a runbook is a document of ordered steps (aws:executeAwsApi, aws:runCommand, aws:branch), so most fixes are declarative steps rather than general-purpose code.
The AWS Config remediation path
AWS Config gives you a second, parallel way to reach the same runbooks that does not use EventBridge at all. When a Config rule evaluates a resource as NON_COMPLIANT, you attach a remediation action that runs an SSM Automation document directly. That remediation can be manual (an operator clicks remediate) or automatic (Config runs it as soon as the resource is found noncompliant).
You can also set a retry count and a limit so Config re-attempts a failing remediation up to a maximum number of times within a period instead of looping forever. Use the Config path when the trigger is 'a resource drifted out of a desired configuration'; use the EventBridge path when the trigger is an operational event or alarm.
The AWS Config remediation path (no EventBridge)
Trace
AWS Config gives a parallel way to reach the same runbooks that does not use EventBridge at all. The Config recorder tracks configuration changes; a Config rule evaluates a resource and marks it NON_COMPLIANT; an attached remediation action then runs an SSM Automation document directly. That remediation can be manual (an operator clicks remediate) or automatic (Config runs it as soon as the resource is found noncompliant). A retry count and limit cap re-attempts within a period so a failing fix does not loop forever. Use this path when the trigger is configuration drift.
What this teaches for the exam
When a scenario says 'automatically fix X when Y happens with no human action,' map Y to a signal and X to a runbook, then pick the router. Operational events and CloudWatch alarms route through EventBridge; configuration drift routes through a Config rule's remediation action.
Prefer a managed runbook, scope the AutomationAssumeRole to least privilege, and remember the two-role split: an invoke role for EventBridge and an assume role for the runbook. If a distractor offers a hand-written Lambda for a fix that a managed runbook already performs, or gives the runbook broad admin permissions, it is usually wrong.
Choosing the router: map the trigger to EventBridge or Config
Trace
The exam-level decision: map the trigger to the right router. Operational events and CloudWatch alarms route through an EventBridge rule; configuration drift routes through a Config rule's remediation action. Both paths land on the same SSM Automation runbook, so prefer a managed runbook, scope the AutomationAssumeRole to least privilege (not admin), and remember the two-role split (an invoke role for EventBridge, an assume role for the runbook). A hand-written Lambda for a fix a managed runbook already performs is usually a wrong distractor.
