Incident & Event Response

Incident & Event Response is the smallest of the AWS Certified DevOps Engineer – Professional (DOP-C02) exam's six domains, but its size has nothing to do with how much tooling it covers. This is the domain where a metric breach or an API event turns into an automatic reaction: EventBridge and CloudWatch Alarms do the noticing, Systems Manager Automation runbooks do the fixing when a fix can be scripted, and Systems Manager Incident Manager, SNS, and AWS Chatbot take over the moment a human has to get involved. By the end of this page you should be able to pick the right AWS service for a given detection-to-resolution scenario and explain how each one hands off to the next.

What this domain covers

☺ Like you're 10: Six slices make up the whole exam, and this is the thinnest slice — but it's specifically the slice about reacting to trouble automatically, on AWS, without a person doing it by hand.

AWS's own exam guide splits this domain into automating a response to an event and troubleshooting or remediating the failures that response uncovers. The practical scope sits between two other domains: Monitoring & Logging (domain 4, 15%) is what actually generates the signal — the metrics, the logs, the alarms — and Security & Compliance (domain 6, 17%) is where the guardrails on what an automated response is allowed to do get defined. This domain is what happens in between: turning a signal into an automatic reaction, escalating to a human when automation can't finish the job, and leaving behind a record good enough to learn from. It leans heavily on the same severity, on-call, and communication practices covered generally in incident management — the difference here is that this page is about the specific AWS services that implement those practices, not the practices themselves.

AWS revises task statements and domain weights between exam guide versions without much notice — the breakdown above reflects the current published DOP-C02 exam guide, but verify it against AWS's own guide before you build a study plan around exact percentages.

Detecting trouble: CloudWatch Alarms vs. EventBridge rules

☺ Like you're 10: One watches a number and yells when it crosses a line; the other watches for a specific thing happening at all, no number required.

A CloudWatch metric alarm watches one metric (or a math expression over several) against a threshold for a configurable number of datapoints within a period, and moves between three states: OK, ALARM, and INSUFFICIENT_DATA. When too many related alarms fire for what's really one underlying failure — high latency and a rising 5xx rate on the same service — a composite alarm combines several alarms with a boolean rule expression so the team pages once on the real problem instead of three times on its symptoms:

aws cloudwatch put-composite-alarm \
  --alarm-name "prod-checkout-degraded" \
  --alarm-rule "ALARM(prod-checkout-high-latency) AND ALARM(prod-checkout-5xx-rate)" \
  --actions-enabled \
  --alarm-actions "arn:aws:sns:us-east-1:111122223333:oncall-escalation"

An EventBridge rule reacts to a different kind of trigger entirely: a discrete event matched by an event pattern, not a numeric threshold. Events land on an event bus — the default bus receives events automatically from most AWS services (including AWS Health, for service issues and scheduled changes), a custom bus carries your own application events, and a partner bus carries events from supported SaaS vendors. A rule matches on the event's source, detail-type, and fields inside detail, and can fan out to up to five targets per rule by default. This is the pattern that matches a CloudWatch Alarm's own state change — because an alarm transitioning to ALARM is itself just another event you can route through EventBridge:

{
  "source": ["aws.cloudwatch"],
  "detail-type": ["CloudWatch Alarm State Change"],
  "detail": {
    "state": { "value": ["ALARM"] },
    "alarmName": [{ "prefix": "prod-" }]
  }
}

Automated remediation: Systems Manager Automation runbooks

☺ Like you're 10: A runbook is a recipe with numbered steps that a robot follows exactly, in order, every time — not a single command, a whole sequence.

A Systems Manager Automation document ("runbook") is a multi-step, orchestrated workflow expressed as YAML or JSON, made of mainSteps that each call an action — aws:executeAwsApi to call any AWS API directly, aws:runCommand to run a command on managed instances, aws:invokeLambdaFunction, aws:approve to pause for a human sign-off, aws:branch for conditional logic, and aws:sleep to wait between steps. AWS ships a library of pre-built runbooks prefixed AWS- (AWS-RestartEC2Instance, AWS-CreateImage, AWS-PatchInstanceWithRollback, and dozens more) alongside whatever custom ones your team authors. A minimal self-heal runbook that reboots an unhealthy instance and pauses before the alarm re-evaluates looks like this:

schemaVersion: "0.3"
description: "Reboot an unhealthy EC2 instance, then give the alarm time to clear."
assumeRole: "{{ AutomationAssumeRole }}"
parameters:
  InstanceId:
    type: String
  AutomationAssumeRole:
    type: String
mainSteps:
  - name: rebootInstance
    action: "aws:executeAwsApi"
    inputs:
      Service: ec2
      Api: RebootInstances
      InstanceIds: ["{{ InstanceId }}"]
  - name: pauseForBoot
    action: "aws:sleep"
    inputs:
      Duration: PT3M
  - name: verifyStatusOk
    action: "aws:executeAwsApi"
    inputs:
      Service: ec2
      Api: DescribeInstanceStatus
      InstanceIds: ["{{ InstanceId }}"]

This is a Systems Manager Run Command document's opposite number, and the exam likes to test the difference directly: Run Command executes one ad hoc command or script on a fleet of managed instances right now — no orchestration, no built-in rollback, no branching. Automation is the state-machine version — multiple ordered steps across any AWS API (not just instance commands), with approval gates for higher-risk actions and rate control (MaxConcurrency, MaxErrors) when you're remediating across a whole fleet instead of one resource. If a question describes a multi-step, auditable, potentially-rolled-back remediation, the answer is Automation; if it describes running one script on some instances right now, the answer is Run Command. An Automation execution needs its own IAM execution role (the AutomationAssumeRole parameter above), separate from whoever or whatever triggered it — scoped to exactly the APIs that specific runbook calls, nothing wider.

Escalating to a human: Incident Manager, SNS, and AWS Chatbot

☺ Like you're 10: When the robot's recipe doesn't fix it, someone has to actually wake a person up, tell them what's wrong, and give them a room to work in together.

Systems Manager Incident Manager is AWS's purpose-built incident response service. A response plan ties three things together: which runbook to run automatically when an incident starts, an engagement plan defining the chain of contacts to page (with escalation timing, similar in spirit to the on-call escalation policies covered generically in incident management), and a chat channel that gets created or joined automatically for the responders to coordinate in. The most direct trigger is a CloudWatch Alarm's native "start an Incident Manager incident" action, described above — no EventBridge required for that specific path; for anything more custom, route the alarm's or event's state through EventBridge to a target that calls the StartIncident API instead. One setup step trips people up the first time: before you can create response plans or contacts at all, Incident Manager requires you to configure a replication set — at least one AWS Region, ideally two, where its data is stored and replicated, specifically so incident response tooling itself survives a regional outage.

SNS is the fan-out layer underneath most of this. A topic published to by an alarm action or an Automation step can reach many subscribers at once — email, SMS, an HTTPS endpoint, Lambda, SQS, or AWS Chatbot. A subscription filter policy keeps that fan-out from becoming noise: instead of every subscriber getting every message, each subscription only receives messages whose attributes match its filter, so a message tagged low-severity never wakes anyone up:

aws sns set-subscription-attributes \
  --subscription-arn "arn:aws:sns:us-east-1:111122223333:oncall-escalation:abcd1234-..." \
  --attribute-name FilterPolicy \
  --attribute-value '{"severity": ["SEV1", "SEV2"]}'

AWS Chatbot is the ChatOps layer: it subscribes to SNS topics (and can consume EventBridge events and Security Hub or GuardDuty findings directly) and posts formatted notifications into a Slack or Microsoft Teams channel, and — the part that actually matters for incident response — lets authorized users run AWS CLI commands and approved actions from inside that same chat channel, so a responder can check status or trigger a follow-up runbook without ever leaving the incident thread. The IAM role attached to a Chatbot channel configuration is what gates exactly which commands are permitted; scoping it tightly is the whole point, not an afterthought.

If your organization already runs on-call through PagerDuty or Opsgenie, Incident Manager's engagement plans cover overlapping ground natively on AWS — contacts, rotations, and escalation chains — which is worth knowing for the exam's "which AWS-native service handles this" framing even if your real-world stack keeps the third-party tool. Either way, the sustainability principles behind who's on that rotation and how it's staffed are the same ones covered in on-call culture & sustainable operations — this domain automates the mechanics, not the humane design of the rotation itself.

Post-incident analysis workflows

☺ Like you're 10: The system already wrote most of the report while the fire was happening — chat log, when the alarm rang, what the robot tried — so writing it up afterward is editing, not reconstructing from memory.

Incident Manager's post-incident analysis is built directly on top of an incident's already-captured timeline: the chat transcript from the automatically-created channel, the CloudWatch alarms and metrics tied to the incident, and the history of any Automation runbook executions it triggered are all present before anyone starts writing. What the team adds afterward is judgment — impact, root cause, and concrete follow-up items — not the raw sequence of what happened, which is usually the most tedious and error-prone part of writing a postmortem by hand. For the definitive "who or what called which API, and exactly when" record — especially useful when the question is whether a change someone made caused the incident — CloudTrail remains the authoritative source, and it's routinely pulled alongside Incident Manager's timeline to reconstruct the full picture.

None of this replaces the cultural practice; it automates the mechanics of it on AWS specifically. The blameless framing, the discipline of turning findings into tracked follow-up actions instead of blame, and the habit of sharing what was learned across teams are exactly the practices covered generally in incident management — this domain is what makes gathering the raw material for that review fast and reliable on an AWS-native stack, not a substitute for doing the review well.

Common exam traps in this domain

☺ Like you're 10: The exam likes to describe a situation and see if you pick the AWS service that actually does that specific job instead of a similar-sounding one.

• Automation vs. Run Command. A scenario describing multiple ordered steps, approval gates, or a rollback path wants Systems Manager Automation. A scenario describing "run this one script on these instances right now" wants Run Command — there's no orchestration or state machine involved.
• Alarm native actions vs. EventBridge. An alarm's own action list is short by design (EC2 action, Auto Scaling action, SNS, OpsItem, Incident Manager incident). If the scenario needs a custom Lambda, a specific Automation runbook, or anything not on that short list, the alarm's state change has to be routed through an EventBridge rule first — you cannot point an alarm directly at an arbitrary target.
• Too many related pages. If a scenario describes several alarms firing together for what's really one failure and the fix is "reduce noise," the answer is a composite alarm with a boolean rule expression, not restructuring SNS topics or adding more subscription filters.
• The replication set gotcha. A question about why Incident Manager response plans or contacts can't be created yet is almost always pointing at the missing first-time-setup step: a replication set has to exist first.
• OpsItems vs. incidents. Systems Manager OpsCenter tracks and correlates operational issues as lightweight OpsItems — good for "aggregate related issues in one place." A full Incident Manager incident is heavier: a response plan, an engagement plan that pages people, and an auto-created chat channel. A scenario asking only for tracking and correlation wants OpsItems, not a full incident.
• Over-broad IAM on the automated path. Whether it's an Automation execution role or the IAM role behind an AWS Chatbot channel, "just attach AdministratorAccess so it always works" is reliably the wrong answer — scope the role to exactly the APIs the runbook or the permitted chat commands actually need.

Rehearsing this whole path end to end — trigger, self-heal attempt, escalation, chat coordination, post-incident review — on a non-production system before it matters for real is exactly what chaos engineering & game days covers, and it's the fastest way to find a gap in a response plan before an actual incident does.

Domain 4, Monitoring & Logging, is what produces the signal this whole page reacts to. Domain 6, Security & Compliance, is where the guardrails on what Automation and Chatbot are allowed to touch get formally defined. For the exam's full task-statement breakdown and current weighting, check the DOP-C02 exam guide; for a quick service-by-service refresher on everything named here, see the AWS service & command reference.