Automated remediation with Systems Manager: SOA-C03 study notes and practice questions
What to know about Automated remediation with Systems Manager for the SOA-C03 exam, from the Monitoring, Logging, Analysis, Remediation, and Performance Optimization domain (22% of the exam guide), then 2 free questions to test it. Part of the SOA-C03 study guide.
Remediation questions ask how to fix a recurring problem without a person, with the least custom code.
Systems Manager Automation
Runbooks (Automation documents) are multi-step workflows: stop an instance, create a snapshot, run a script, call an API, wait for approval.
AWS provides many: AWS-RestartEC2Instance, AWS-StopEC2Instance, AWS-CreateSnapshot, AWSSupport-ExecuteEC2Rescue (repair an unreachable instance’s OS), AWS-DisablePublicAccessForSecurityGroup, AWSConfigRemediation-* runbooks and more.
Runbooks run with an Automation assume role that needs permission for every action.
Rate control and targets (by tag or resource group) run a runbook across many resources safely.
Approval steps pause for a human when needed.
Wiring it together
Trigger
Path to the fix
A CloudWatch alarm
Alarm state change → EventBridge rule → Automation runbook (or Lambda). Alarms can also take EC2 actions directly
A non-compliant resource
AWS Config rule with automatic remediation → Automation runbook
A security finding
Security Hub or GuardDuty finding → EventBridge → runbook or Lambda
An AWS Health event
Health event → EventBridge → runbook
Other tools
EC2 auto recovery: instances recover onto healthy hardware after a system status check failure (simplified automatic recovery is on by default for supported types), keeping instance ID and IP addresses.
Systems Manager OpsCenter collects operational issues (OpsItems) with links to runbooks.
AWS Systems Manager Incident Manager has closed to new customers, so don’t plan new designs around it.
Common traps
Writing a Lambda function for a job an AWS runbook already does. It fails “least operational overhead”.
Forgetting the Automation role’s permissions. The runbook fails at the step it can’t perform.
Config detects but doesn’t fix by itself. Add a remediation action.
A dental chain's appointment API runs on EC2 instances.
About once a week the API process hangs, and a custom CloudWatch alarm on its health-check metric goes into ALARM. The fix is always to restart the service with a custom Systems Manager Automation runbook the team already wrote.
Rebooting the instance is not acceptable, because the cache takes 10 minutes to warm. The team wants the fix to run automatically within a minute of the alarm.
What should a CloudOps engineer do?
Choose one answer.
AA. Add an EC2 reboot action to the alarm so that the instance restarts automatically whenever the health-check alarm enters ALARM.
BB. Create a State Manager association that runs the runbook on all instances every 30 minutes, whether or not the alarm has fired.
CC. Create an EventBridge rule that matches the alarm's state change to ALARM and starts the Automation runbook through an IAM role allowed to start it.
DD. Write a Lambda function that runs every minute, checks the alarm state with the CloudWatch API, and calls Run Command to restart the service.
C. Right: Correct. CloudWatch sends alarm state changes to EventBridge, and a rule can start an Automation runbook directly as its target. The restart runs within seconds and touches only the service, not the instance. Learn more: Alarm events and EventBridge (opens in a new tab)
Automatic remediation in AWS usually chains an alarm to an action through EventBridge. The alarm's state change event matches a rule, and the rule starts a Systems Manager Automation runbook that performs the precise fix. EC2 alarm actions are coarser, scheduled associations are slower, and polling code adds overhead.
The alarm's state change is the trigger, and the runbook does only the precise fix, so the cache stays warm.
A regional bank's engineer edited the SSH daemon configuration on an EBS-backed Amazon Linux reporting server with an unencrypted root volume and restarted it. The server now refuses all SSH connections, and the SSM Agent on it had been stopped weeks ago to save memory.
The team wants an AWS-provided, repeatable way to diagnose and repair common operating system connectivity problems on the instance, without building a recovery process themselves.
Which approach should the team use?
Choose one answer.
AA. Run the AWSSupport-ExecuteEC2Rescue Automation runbook to repair the instance offline.
BB. Connect with Session Manager and revert the SSH configuration file from the shell session.
CC. Use Run Command with the AWS-RunShellScript document to restore the previous SSH configuration file.
DD. Create an AMI from the instance and launch a new instance from it, then delete the original instance.
Show the answer and explanation
Answer: A
A. Right: Correct. This AWS-provided runbook stops the instance, attaches its root volume to a helper instance and runs EC2Rescue offline to fix common connectivity problems. Because the work happens on the helper instance, it does not need SSH or a session on the broken instance. Learn more: AWSSupport-ExecuteEC2Rescue runbook (opens in a new tab)
Systems Manager provides predefined runbooks for common repair jobs. AWSSupport-ExecuteEC2Rescue works on the instance's volume offline from a helper instance, so it does not depend on SSH or on a session with the broken instance. Session Manager and Run Command need that agent, and an AMI reproduces the broken configuration.
Want more on Automated remediation with Systems Manager? The 5 full-length practice sets have 8 more Automated remediation with Systems Manager questions, 325 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets →