1.3 - Automated remediation (EventBridge and SSM Automation)
AWS SysOps Administrator objective 1.3 covers remediating issues based on monitoring. The core pattern is event-driven: a CloudWatch alarm, a GuardDuty finding or a non-compliant AWS Config rule emits an event, an Amazon EventBridge rule matches it, and a target runs the fix - most often an AWS Systems Manager Automation runbook or a Lambda function that restarts a service, tags or isolates an instance, or resizes a resource. AWS Config remediation actions attach an SSM document to a rule for manual or automatic correction. EC2 auto recovery replaces impaired hardware, and dead-letter queues capture failed event deliveries. You should know EventBridge event patterns, scheduled rules, and cross-account event buses. Expect scenario questions that describe detecting a problem and fixing it without a human, and ask which trigger and remediation action to wire together.
Detect then auto-fix = alarm/finding -> EventBridge rule -> SSM Automation runbook. Config rule can auto-remediate via an SSM document. Failed event deliveries land in a dead-letter queue.
Practice questions
1. A newly created CloudWatch alarm has not yet received enough data to evaluate its threshold. Which state is it in?
- INSUFFICIENT_DATA (correct answer)
- ALARM
- OK
- PENDING_EVALUATION
With too few data points, an alarm sits in INSUFFICIENT_DATA until enough datapoints arrive. The three valid states are OK, ALARM, and INSUFFICIENT_DATA; PENDING_EVALUATION is not a CloudWatch alarm state.
2. An alarm is set with an evaluation period of 5 and 'datapoints to alarm' of 3. What does this configuration mean?
- The alarm triggers if 3 of the last 5 data points breach the threshold (correct answer)
- The alarm triggers only when 5 consecutive data points all breach the threshold value
- The alarm waits 3 minutes and then averages 5 samples before deciding
- The alarm needs 5 breaches within any rolling three-hour window
This is an M-out-of-N alarm: 3 of the last 5 evaluated data points must breach the threshold for the alarm to fire. It does not require all 5 to be consecutive breaches.
3. An EC2 instance is stopped nightly, so its metric stops reporting. You do not want the alarm to flip to ALARM during that gap. Which 'treat missing data' setting fits?
- missing, so the alarm keeps its current state during the gap (correct answer)
- breaching, so each missing data point counts as crossing the threshold
- notBreaching combined with a mandatory 24-hour delay window
- ignore, which permanently disables the alarm's evaluation engine
Treating missing data as 'missing' makes the alarm keep its current state during expected gaps, avoiding false ALARMs. 'breaching' would force it into ALARM, and 'ignore' keeps the last state but does not disable evaluation.
4. A metric filter counts 500 errors. You need an email when errors spike AND an auto-remediation. What chain works?
- Alarm on the filter metric, notify SNS, and trigger a Systems Manager runbook (correct answer)
- Point the metric filter straight at SNS to send the email on each error
- Schedule a Logs Insights query and email its results using Lambda hourly
- Create an EventBridge rule that reads the raw log group text every minute
Filter to metric, alarm on the metric, then the alarm fans out to SNS for email and to an SSM Automation runbook for remediation. Metric filters cannot notify SNS directly, Insights is ad-hoc, and EventBridge cannot poll raw log text.
5. After installing the CloudWatch agent, no log events appear in the console. What should you check FIRST?
- Whether the log group retention was accidentally set to only one day
- Whether the metric filter pattern matches the incoming log format exactly
- Whether the CloudWatch dashboard widget points at the correct AWS Region
- Whether the agent is running and its role allows CreateLogStream/PutLogEvents (correct answer)
Logs not appearing almost always traces to the agent process being down or its IAM role lacking CreateLogStream/PutLogEvents, so verify those first. Retention, metric filter patterns, and dashboard widgets do not stop ingestion into the group.
6. An app writes logs successfully, but your alarm on a metric filter never fires. The filter's log group is app/prod while the app logs to app/production. What is wrong?
- The metric filter pattern is case sensitive and must be rewritten in lowercase
- The metric filter is attached to the wrong log group name (correct answer)
- The alarm period is too long, so it silently ignores every data point
- The log stream retention expired the events before the alarm could evaluate them
The filter watches app/prod but the app writes to app/production, so it never sees events and the metric stays empty. Case sensitivity, alarm period, and retention are not the cause when the group names simply do not match.