Incident Response Planning

The cloud incident response lifecycle

When a GuardDuty finding fires at 3 a.m., the difference between a 20-minute response and a 20-hour one is almost entirely decided by work you did months earlier. AWS organizes that work around the NIST SP 800-61 incident response lifecycle^[1], the same four-phase model used on-premises, adapted for the cloud: preparation, then detection and analysis, then containment, eradication, and recovery, then post-incident activity. This subtopic owns the preparation phase, which AWS describes as getting the people, the process, and the technology ready so that response is a rehearsed procedure rather than an improvisation.

The word for preparation in the cloud is pre-staging. Everything a responder will reach for, the elevated access, the runbook that quarantines an instance, the forensic account that receives a disk snapshot, the alarm that pages the on-call, exists and has been tested before any real incident. AWS SEC10-BP02 in the Well-Architected Security pillar^[2] frames the deliverable as an incident response plan plus per-scenario runbooks (a runbook is the codified step list for one situation, such as "credential exposed in a public repo" or "EC2 instance beaconing to a known-bad IP").

The phases are a loop, not a line. The post-incident phase feeds lessons back into preparation: a missing permission discovered mid-incident becomes a new pre-staged role, a manual step that cost ten minutes becomes an Automation runbook. The live work in the middle two phases, isolating a resource and tracing what the attacker did, is the response subtopic; here you build the machinery that makes those steps fast and repeatable.

The AWS cloud IR lifecycle follows NIST SP 800-61: four phases that loop, with post-incident lessons feeding back into preparation.

Pre-stage access and shrink the blast radius

Responding to an incident usually requires permissions you would never grant for daily operations: snapshot any volume, detach a role, quarantine an instance. The wrong move is to keep those permissions standing or to write an emergency policy live during the event. The right move is to pre-provision them as a dedicated incident-response IAM role that responders assume only when an incident is declared, gated by MFA and a tight trust policy, with every action captured in CloudTrail. This is the break-glass pattern: elevated access is one deliberate, fully logged sts:AssumeRole away, never lying around as standing privilege.

Where those roles live matters as much as that they exist. AWS recommends a separate security or forensic account, isolated from the workload accounts, so that an attacker who has compromised a production account cannot reach the responders' tooling or tamper with collected evidence. Disk snapshots and memory captures are shared into the forensic account; the workload account never holds the analysis environment. The same separation underpins chain of custody: evidence sits in an account the suspect identity cannot touch.

Preparation also means designing so the incident cannot spread far in the first place, which is the blast radius idea. Multi-account segmentation, scoped IAM, and network isolation boundaries mean a compromise in one account or subnet is naturally contained. Consistent resource tagging is part of this too: an isolation runbook can target exactly the tagged resources in scope instead of guessing. For one specific threat, DDoS, the pre-staging is a product: AWS Shield Advanced^[3] gives you the AWS Shield Response Team (SRT), and turning on proactive engagement lets the SRT contact your emergency contacts during an attack instead of waiting for you to open a case. Shield Advanced is $3,000 per month per payer account in an organization with a one-year commitment, so it is a deliberate preparation decision, not something you switch on under fire.

Break-glass: responders assume a pre-staged MFA-gated IR role (logged to CloudTrail) that reaches an isolated forensic account holding evidence.

Codify runbooks and orchestrate the response

A plan written only in a wiki is slow and error-prone when a responder is reading it under stress at 3 a.m. Preparation turns the repeatable parts into code. The building block is the Systems Manager Automation runbook (an Automation document, type Automation): a defined sequence of steps, such as snapshot a volume, replace an instance's security group, disable an access key, that runs the same way every time and can be invoked by hand, on a schedule, or by an event.

For security operations, Systems Manager OpsCenter^[4] is the place those runbooks meet the findings. OpsCenter aggregates operational issues as OpsItems in one console, deduplicates them, and attaches the relevant Automation runbooks so a responder can choose Run automation directly from the item. It is wired to detection: a CloudWatch alarm entering ALARM, or an EventBridge event (for example a Security Hub finding), can create an OpsItem automatically, so the path from "GuardDuty saw something" to "the quarantine runbook is one click away" is pre-built rather than assembled live.

When a response is more than a linear list, for example branch on whether the instance is in production, capture memory only if a flag is set, wait for human approval before terminating, use AWS Step Functions^[5] to orchestrate it as a state machine. Standard workflows give exactly-once execution and run for up to a year, which suits a long, auditable, possibly approval-gated IR flow; each transition is recorded, giving you a built-in timeline of what the automation did. A typical pattern is EventBridge catching a finding, invoking either an SSM runbook for simple cases or a Step Functions state machine (often calling Lambda functions and SSM steps) for complex ones. The aim is the same: convert the plan into automation a responder triggers, not a document they transcribe.

Pre-built path from finding to fix: an OpsItem links a runbook; linear cases run an SSM Automation runbook, branchy ones a Step Functions state machine.

Test the plan, and how the exam asks about it

A plan you have never executed is a hypothesis. AWS expects you to validate it, and the named tool for that is the game day: a scheduled, controlled exercise where you inject a realistic fault and watch whether detection fires, automation runs, and responders follow the runbook. AWS Fault Injection Service (AWS FIS)^[6] is the managed way to run these. FIS is built on chaos-engineering principles and performs real actions on real resources, so you define an experiment template with three parts: actions (what disruption to inject), targets (which resources, chosen by tag or state), and stop conditions (CloudWatch alarms that automatically halt and roll back the experiment if it goes too far). Because FIS acts on live resources, AWS recommends running new experiments in pre-production first. AWS Resilience Hub complements this by assessing an application against resiliency targets and recommending where to test, but FIS is the service that actually injects the fault.

What the exam stem looks like

The planning questions cluster around a few recognizable shapes:

"Responders need elevated access during an incident but the company forbids standing admin permissions." The answer is a pre-provisioned break-glass IAM role assumed under MFA with CloudTrail logging, not a permanent admin group and not an inline policy written during the event.
"How do you validate the incident response plan works before a real incident?" Run a game day using AWS Fault Injection Service to inject controlled faults; the distractors are real services that do not test response (AWS Config evaluates configuration; Inspector scans for vulnerabilities; Trusted Advisor checks best practices).
"Automate a multi-step, approval-gated response to a finding." EventBridge invokes a Step Functions state machine (or an SSM Automation runbook for the simple linear case). A single Lambda function is the weaker answer when the flow branches, waits, or must be auditable end to end.
"Prepare for a large DDoS attack with expert help available during the event." Shield Advanced with proactive engagement enabled so the SRT can reach you; Shield Standard (free, automatic) and WAF rate rules alone do not include the response team.

Why the common distractors are wrong

The trap on every one of these is choosing a detection or configuration service where the question asks about preparation for response. Config, Inspector, GuardDuty, and Security Hub all surface problems; they do not pre-stage access, codify runbooks, or rehearse the plan. Keep the lifecycle in mind: if the stem is about getting ready to respond, the answer is an IAM role, a runbook, an orchestration, or a game day, not another detector.

An AWS FIS experiment template is three parts: actions to inject, targets chosen by tag or state, and stop conditions (CloudWatch alarms) that auto-roll-back.

AWS services that prepare and test an incident response plan

Capability	Systems Manager (runbooks/OpsCenter)	Step Functions	Fault Injection Service	Shield Advanced + SRT
Primary IR role	Codify and run remediation runbooks	Orchestrate branching multi-step response	Test the plan with controlled faults	Pre-stage DDoS protection and expert access
Lifecycle phase served	Preparation and recovery	Preparation and recovery	Preparation (validation)	Preparation and containment
Triggered by	OpsItem from CloudWatch alarm or EventBridge, or manual	EventBridge event or Lambda/SSM invocation	Scheduled game day or manual experiment	DDoS detection; proactive SRT engagement
What it produces	Executed Automation runbook, central OpsItem	Auditable state-machine execution	Observed failure behavior to fix gaps	Mitigated attack, SRT-assisted response

Decision tree

Cheat sheet

Sharp facts the exam loves — give these one last read before exam day.

Cheat sheet

Sharp facts the exam loves — scan these before test day.

Cloud IR follows the four-phase NIST 800-61 lifecycle

AWS structures incident response on the NIST SP 800-61 lifecycle: preparation, then detection and analysis, then containment, eradication, and recovery, then post-incident activity. Preparation is where you stage access, runbooks, tooling, and rehearsals so response is a procedure, not an improvisation. The phases loop, so post-incident lessons feed straight back into preparation.

Pre-provision responder access as a break-glass role, never standing admin

Incident response needs broader permissions than daily work, so pre-create a dedicated IR IAM role that responders assume only during a declared incident, gated by MFA, a tight trust policy, and full CloudTrail logging. This gives auditable, time-boxed elevation without leaving powerful permissions lying around, and beats writing an emergency policy live under pressure.

Trap Granting responders standing administrator permissions so they are 'ready'; that is permanent excess privilege an attacker can ride, the opposite of least privilege.

Keep response and forensics in a separate account

Pre-stage a dedicated security or forensic account that is isolated from the workload accounts, and share evidence such as disk snapshots and memory captures into it. An attacker who controls a workload account then cannot reach the responders' tooling or tamper with collected evidence, which also preserves chain of custody because the evidence sits where the suspect identity has no access.

Trap Storing snapshots and analysis tools in the same compromised account; the attacker who owns that account can delete or alter the evidence.

Shrink the blast radius before the incident, not during it

Containment is easier when the architecture already limits how far an incident can spread, so preparation includes multi-account segmentation, scoped IAM, and network isolation boundaries. Consistent resource tagging is part of this because an isolation runbook can then target exactly the tagged in-scope resources instead of guessing.

Codify remediation as Systems Manager Automation runbooks

Turn repeatable response steps such as snapshot a volume, swap an instance's security group, or disable an access key into a Systems Manager Automation runbook (an Automation-type document) that runs identically every time. A runbook can be invoked manually, on a schedule, or by an event, replacing a wiki page a stressed responder would otherwise transcribe by hand.

2 questions test this

OpsCenter centralizes findings as OpsItems with runbooks attached

Systems Manager OpsCenter aggregates and deduplicates operational issues as OpsItems in one console and attaches the relevant Automation runbooks so a responder runs remediation from the item. It is wired to detection: a CloudWatch alarm entering ALARM, or an EventBridge event such as a Security Hub finding, can create an OpsItem automatically, pre-building the path from a finding to a one-click runbook.

Trap Treating OpsCenter as a detector; it organizes and remediates issues that other services detect, it does not generate the findings itself.

Use Step Functions to orchestrate branchy or approval-gated response

When response is more than a linear list, for example branch on whether the instance is production, capture memory only if flagged, or wait for human approval before terminating, orchestrate it as a Step Functions state machine rather than one Lambda. Standard workflows give exactly-once execution and run up to a year, and every state transition is recorded, giving a built-in audit timeline of what the automation did. Reach for a single SSM runbook instead when the flow is short and linear.

Trap Cramming a branching, approval-gated response into one large Lambda function; you lose the auditable per-step timeline and the long-running, exactly-once execution Standard workflows provide.

EventBridge is the glue from finding to automated response

A finding from GuardDuty or Security Hub publishes to EventBridge, and an EventBridge rule then invokes the response: an SSM Automation runbook for the simple linear case or a Step Functions state machine for the complex one. Pre-building this rule means the response triggers automatically instead of waiting for a human to notice and start it.

3 questions test this

Validate the plan with game days using AWS Fault Injection Service

A plan you have never executed is only a hypothesis, so rehearse it with a game day: a scheduled, controlled exercise that injects a realistic fault and confirms detection fires, automation runs, and responders follow the runbook. AWS Fault Injection Service (FIS) is the managed way to run these, built on chaos-engineering principles. The distractors here are services that check state rather than test response: Config evaluates configuration, Inspector scans for vulnerabilities, Trusted Advisor checks best practices.

Trap Choosing AWS Config, Inspector, or Trusted Advisor to 'test the incident response plan'; those assess configuration or vulnerabilities, none of them injects a fault to exercise the response.

A FIS experiment template is actions, targets, and stop conditions

An AWS FIS experiment template has three parts: actions (the disruption to inject), targets (the resources, selected by tag or state), and stop conditions (CloudWatch alarms that automatically halt and roll back the experiment if it crosses a threshold). The stop condition is the safety guardrail that keeps a controlled experiment from becoming a real outage.

Trap Running a FIS experiment with no stop condition; without the CloudWatch-alarm guardrail there is nothing to auto-halt and roll back the injected fault before it causes a real outage.

FIS acts on real resources, so run new experiments in pre-production first

FIS performs real actions on real AWS resources, not a simulation, so AWS recommends running a new experiment in a pre-production environment before targeting production. This is why blast-radius controls and stop conditions matter even during a planned test.

Trap Assuming FIS only simulates faults; it injects genuine disruptions on live resources, so an untested experiment aimed straight at production can cause an actual incident.

Resilience Hub assesses resilience; FIS injects the fault

AWS Resilience Hub evaluates an application against defined resiliency targets (RTO/RPO) and recommends where it is weak and what to test, but it does not itself inject faults. FIS is the service that actually runs the disruptive experiment, so the two pair up: Resilience Hub points at the gap, FIS exercises it.

Trap Picking Resilience Hub as the tool that 'tests by injecting faults'; it assesses and recommends, while FIS is the service that performs the fault injection.

Pre-stage Shield Advanced and the SRT before a DDoS event

Shield Advanced is a preparation decision for DDoS: it unlocks the AWS Shield Response Team (SRT) and, with proactive engagement enabled, lets the SRT contact your emergency contacts during an attack instead of waiting for you to open a case. Reaching the SRT also requires a Business or Enterprise Support plan, so that support tier is part of the pre-staging. Shield Standard is free and automatic but includes no response team, so the SRT is the differentiator when the question wants expert help available during the event.

Trap Answering Shield Standard or WAF rate-based rules when the stem asks for expert assistance during a DDoS; neither includes the Shield Response Team, which requires Shield Advanced.

Pre-deploy the Automated Forensics Orchestrator so capture is one trigger away

Preparation can include deploying the Automated Forensics Orchestrator for Amazon EC2, an AWS solution built on Step Functions that automates isolation, plus memory and disk acquisition into a dedicated forensic account, ready to be triggered by a GuardDuty or Security Hub finding. Standing it up in advance means evidence capture follows a tested, repeatable workflow instead of manual snapshotting during the incident.

Post-incident review feeds the next preparation cycle

The post-incident phase exists to improve future response: a permission you lacked mid-incident becomes a new pre-staged role, and a slow manual step becomes an Automation runbook. Treating the lifecycle as a loop is what turns one painful incident into a stronger plan, rather than repeating the same gaps.

Build the plan and runbooks per scenario, not one generic document

AWS Well-Architected (SEC10) frames the deliverable as an incident response plan plus a runbook for each recognizable scenario, such as an exposed credential or an instance beaconing to a known-bad IP. Scenario-specific runbooks are fast to execute because each one already knows its exact steps, where a single generic document forces decisions during the incident.

Add an EventBridge target retry policy plus an SQS dead-letter queue so no security event is lost

Transient failures such as API throttling or downstream network errors can drop automated remediation. Configure the EventBridge rule target with a retry policy (MaximumRetryAttempts / maximum event age) to retry transient failures, and attach an SQS dead-letter queue to capture events that exhaust all retries. DLQ messages carry ERROR_CODE / ERROR_MESSAGE metadata, and a separate consumer can reprocess them — so persistent failures are preserved for investigation rather than lost.

Trap Relying on Lambda's own retries alone: they do not capture events EventBridge could not deliver to the target, which is exactly what the rule-level DLQ preserves.

3 questions test this

An EventBridge rule built by CloudFormation/CLI needs a resource-based policy on its Lambda target

The console auto-adds the permission, but when you create an EventBridge rule with a Lambda target via CloudFormation, the CLI, or an SDK you must explicitly add a resource-based policy (lambda:AddPermission) on the function allowing the events.amazonaws.com service principal — ideally scoped to the rule ARN as SourceArn. Without it the rule looks correctly configured yet the function is never invoked; CloudWatch FailedInvocations / a DLQ confirm the missed deliveries.

Trap Assuming the Lambda execution role is the problem: the execution role governs what the function can do, while the missing resource-based policy is what blocks EventBridge from invoking it at all.

2 questions test this

Filter GuardDuty findings on the numeric severity (>= 7 for high/critical), not a 'HIGH' string label

GuardDuty publishes findings to EventBridge with source 'aws.guardduty' and detail-type 'GuardDuty Finding', and severity is a number from 1.0-10.0 across four tiers: Critical 9.0-10.0, High 7.0-8.9, Medium 4.0-6.9, Low 1.0-3.9. To alert on the top of the range, match detail.severity at or above 7 (which spans High and Critical) — a numeric matcher such as detail.severity {'numeric':['>=',7]} is valid, though AWS examples typically enumerate the values (e.g. [7, 7.0, ... 10.0]). Combine it with a prefix matcher on detail.type (such as 'CryptoCurrency:EC2' or 'UnauthorizedAccess:IAMUser') to target a finding family.

Trap Matching detail.severity against the string 'HIGH': GuardDuty severities are numeric, so a string filter matches nothing and the rule never fires.

3 questions test this

A GuardDuty delegated administrator aggregates member findings onto its own default event bus

Designate a delegated administrator account for GuardDuty in AWS Organizations and findings from every current and future member account are automatically aggregated there and published to the administrator account's default EventBridge event bus. A single EventBridge rule in that account therefore captures organization-wide findings (the accountId field identifies the source) — no per-account event-bus forwarding is needed.

Trap Building per-member-account EventBridge cross-account forwarding rules: the delegated-admin aggregation already centralizes the finding events for you.

4 questions test this

Use the aws:branch action to take different remediation paths by finding severity

Conditional logic in a Systems Manager Automation runbook is implemented with the aws:branch action: it evaluates Choices (commonly StringEquals on a severity input variable) and routes execution to a NextStep, so HIGH findings can disable keys or isolate a resource while MEDIUM/LOW only notify or log. Set isEnd: true on the terminal step of each branch.

Trap Reaching for separate Step Functions states for simple in-runbook branching: aws:branch keeps the conditional severity routing inside one Automation document.

3 questions test this

aws:approve pauses a runbook for human sign-off; MaxConcurrency/MaxErrors govern multi-account rollout

Add the aws:approve action to pause an Automation execution until designated IAM principals approve — the way to gate a production remediation (often combined with aws:branch on an environment tag so non-prod runs straight through). For organization-wide runs, multi-account/multi-Region execution (TargetLocations, aws:executeAutomation) uses MaxConcurrency to limit parallel targets and MaxErrors (a count or percentage) to stop the automation once failures exceed the threshold.

Trap Hard-coding a wait or a Lambda poll for approval: aws:approve is the built-in Automation action that suspends the run for named approvers.

4 questions test this

The cloud incident response lifecycle

Pre-stage access and shrink the blast radius

Codify runbooks and orchestrate the response

Test the plan, and how the exam asks about it

What the exam stem looks like

Why the common distractors are wrong

AWS services that prepare and test an incident response plan

Decision tree

Cheat sheet

Also tested in

References