Design and Test an AWS Incident Response Plan (SCS-C03)

The AWS Security Incident Response Guide organizes response into four phases aligned with the NIST incident response lifecycle: preparation; detection and analysis; containment, eradication, and recovery; and post-incident activity. The exam expects you to know what changes when this lifecycle runs in a cloud that is entirely API-driven. Three cloud specifics matter. First, every control-plane action is an API call, so CloudTrail gives you a near-complete record of attacker activity that on-premises responders rarely have — your analysis phase is largely log reconstruction. Second, elasticity makes non-destructive containment the default: you can isolate an instance, snapshot its volumes, and stand up a clean replacement without powering anything off, so evidence preservation and service recovery stop competing. Third, identity is the perimeter — credential compromise is at least as common as host compromise, so playbooks for exposed access keys and hijacked roles sit alongside the traditional compromised-server runbook.

Task 2.1 owns the design and testing of this machinery. Executing containment and forensics on a live event is Task 2.2, and designing the detection pipeline that produces the findings belongs to Domain 1.

The single most tested preparation idea is that responder access must exist before the incident. Creating IAM permissions mid-incident is slow, error-prone, and — if the incident is an IAM compromise — potentially impossible or actively dangerous. Design a dedicated incident response role in every account, scoped to what responders actually need: broad read for investigation, plus targeted containment permissions such as modifying security groups, deactivating access keys, creating EBS snapshots, and tagging resources. Responders assume it cross-account from the security or forensics account, so one identity boundary serves the whole organization; the assumption itself lands in CloudTrail, giving you an audit trail of responder activity.

Alongside it, define a break-glass procedure: a tightly controlled, MFA-protected path to elevated access, with credentials stored out of band and alerting wired so that any break-glass use pages the security team. Break-glass exists for the scenario where normal federation is unavailable or itself compromised.

Preparation also covers being reachable and being able to identify what you are looking at. Register alternate contacts — specifically the security contact — on every account so AWS notifications reach the security team rather than a billing inbox. AWS contacts you through AWS Health events (for example, when your access keys are found exposed publicly) and through Trust & Safety abuse notifications; both are compromise signals your plan must route to responders, alongside your own GuardDuty findings. Finally, a tagging strategy — owner, environment, data classification — is IR infrastructure: when an alarm names an instance ID at 2 a.m., tags are how the responder finds the owning team and judges blast radius without archaeology.

Credential playbooks turn on one distinction the exam probes repeatedly: long-term access keys can be deactivated; temporary credentials cannot.

For an exposed IAM user access key, the playbook's first containment step is to deactivate the key, not delete it. Deactivation immediately stops authentication, is reversible if you disabled the wrong key, and preserves the key ID for correlating CloudTrail history during the investigation. Deletion is an eradication step you take after the investigation confirms the key is unneeded. The playbook then scopes what the key did in CloudTrail and checks for persistence before closing.

For a compromised IAM role (or any principal whose temporary credentials leaked), there is nothing to deactivate — STS credentials remain valid until they expire, and you cannot recall them. The documented pattern is to revoke existing sessions by attaching an inline deny policy conditioned on token age: a statement with "Effect": "Deny" on "Action": "*" and a DateLessThan condition on aws:TokenIssueTime. This is exactly what the IAM console's Revoke active sessions button does, attaching the AWSRevokeOlderSessions inline policy. Every session issued before the cutoff instantly loses all permissions, while legitimate workloads recover by simply obtaining fresh credentials — which is why this beats deleting the role, an irreversible move that breaks every dependent workload and destroys the trust-policy evidence.

Your playbook should encode the full sequence as decision points: contain (deactivate or revoke), scope (CloudTrail: what did the credential touch), hunt persistence (new users, keys, roles, policy changes), then eradicate and rotate. Executing that sequence live is Task 2.2 territory; designing and rehearsing it is 2.1.

Forensics fails when it is improvised. The prepared pattern is a dedicated forensics account: an isolated member account that holds analysis tooling, receives shared evidence, and grants access only to the forensics team. Because it is a separate account, evidence and analysis workloads are outside the compromised account's blast radius, and the attacker's credentials — whatever they were — have no reach into it. Pre-build what the account needs before any incident: hardened analysis AMIs with your disk- and memory-analysis tooling installed, an evidence bucket with restrictive policies and Object Lock-style retention thinking, and the cross-account snapshot-sharing workflow already rehearsed.

AWS publishes a deployable solution the guide names explicitly: the Automated Forensics Orchestrator for Amazon EC2. It uses Step Functions and Lambda to automatically capture disk snapshots and memory from a flagged instance, isolate it, and stage artifacts in the forensics account — turning a 40-step manual runbook into an event-driven pipeline. You should know it as the managed answer to "automate EC2 evidence acquisition at scale."

Blast-radius minimization is the other half of preparation. A multi-account structure is itself an IR control: separating workloads, log archive, security tooling, and forensics into different accounts caps what any single compromise can touch, and centralized, immutable logging in a log-archive account means the attacker cannot erase the record you will investigate with. For availability-threatening events, the guide calls out configuring AWS Shield Advanced protections in advance for internet-facing resources — DDoS response works only when protections, health checks, and escalation paths were associated with the resources before the traffic arrives.

The exam's preferred runbook format is executable. A prose wiki page rots and gets misread under pressure; a Systems Manager Automation document encodes the same procedure as versioned steps that run with IAM-scoped permissions, log every action, and behave identically at 2 a.m. as in rehearsal. Standard response actions — isolate this instance, snapshot these volumes, deactivate this key, tag and quarantine — should each exist as an Automation document that both humans and event-driven automation can invoke. Systems Manager OpsCenter complements this by aggregating operational and security issues as OpsItems, attaching the relevant runbooks alongside each item so the on-call responder has procedure and context in one place. The guide also names Amazon SageMaker AI notebooks as a response-plan tool: notebooks capture investigative analysis — log queries, data correlation, enrichment — as documented, re-runnable steps, useful when analysis is more exploratory than a fixed runbook allows.

For multi-step response, AWS Step Functions orchestrates Lambda functions and Automation documents into a state machine with retries, branching, and explicit approval states. That last part matters: the design principle the exam rewards is automation-ready, human-approved. Wire responders end to end, but insert an approval gate — for example an aws:approve step in an Automation document — before high-impact, hard-to-reverse actions like isolating a production instance or revoking a widely used role's sessions. Low-risk, reversible containment can run fully automatically; destructive steps wait for a human decision made with full context. Amazon Application Recovery Controller rounds out the recovery side, providing readiness checks and routing controls to fail traffic away from an impaired or quarantined environment.

An untested plan is a hypothesis. Task 2.1 explicitly covers recommending procedures to validate IR effectiveness, and you should know the escalating ladder of test types.

Tabletop exercises are the cheapest layer: responders walk a scenario verbally against the written playbook, exposing missing steps, unclear ownership, and stale contact lists without touching infrastructure. Game days execute the plan against realistic simulated incidents in a controlled environment, testing not just the documents but the people, the access paths, and the tooling under time pressure.

Two AWS features make simulations concrete. GuardDuty sample findings let you generate realistic findings of any type on demand — the standard way to verify your pipeline end to end: does the sample finding reach Security Hub, fire the EventBridge rule, trigger the responder, page the on-call? If a sample CryptoCurrency finding does not open an incident, a real one will not either. AWS Fault Injection Service injects real faults — instance terminations, network disruption, API throttling — under controlled, stop-condition-guarded experiments; in an IR context it validates that your detection fires and your recovery procedures actually restore service. AWS Resilience Hub assesses applications against recovery-time and recovery-point objectives, telling you whether the recovery half of your plan is achievable before an incident proves it is not.

Every test ends the same way: a review that feeds playbook iteration. Measure time-to-detect and time-to-contain, record what confused people, update the runbooks, and schedule the next exercise. Also rehearse the unglamorous parts — break-glass access and cross-account role assumption fail most often precisely because they are used least.

Your plan must name the tools responders will use to answer the three investigation questions — who acted, what did they touch, when did it happen — because those tools have preparation prerequisites of their own.

CloudTrail is the backbone. Management events give you every control-plane call with the principal, source IP, and user agent; the plan should assume an organization trail feeding a central, access-controlled archive so the record is complete and tamper-resistant. Remember that data events (S3 object-level operations, Lambda invocations) are not logged by default — if a playbook's scoping step says "determine which objects were read," that answer only exists if data events were enabled during preparation. This is the classic Task 2.1 trap: analysis capability is a preparation decision.

Amazon Detective continuously ingests CloudTrail, VPC Flow Logs, and GuardDuty findings into a behavior graph, so a responder can pivot from a finding to an entity timeline — this role's API calls over time, this instance's traffic, this IP's history — without hand-writing queries. Because Detective needs data enabled before the incident to have history to show, turning it on is a preparation step, not a response step. AWS Security Hub is the aggregation layer: findings from GuardDuty, Macie, Inspector, and partner tools normalized in one place, so triage starts from a single queue instead of five consoles. For arbitrary questions the graph cannot answer, Athena queries the CloudTrail archive directly with SQL.

Encode the toolkit into playbooks as concrete steps — "open the Detective profile for the role session," "run the saved Athena query for this access key ID" — so analysis quality does not depend on who is on call.

Walk the design end to end. Your organization runs 40 accounts; the risk you are planning for is a developer committing an IAM user access key to a public repository.

Triggers. The playbook lists every signal that can start it: an AWS Health event notifying you of an exposed key, a GuardDuty finding such as UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS, a Trust & Safety abuse notification, or a developer self-report. Because you registered security contacts and routed Health events to the security team, none of these dead-ends in an unread inbox.

Steps. (1) Deactivate the key — a pre-authorized, low-risk containment action, so it is fully automated: an EventBridge rule on the Health event invokes a Lambda responder using the pre-provisioned IR role. (2) Revoke sessions on any roles the user could assume, using the aws:TokenIssueTime deny pattern — higher impact, so the Automation document pauses at an approval step for a human. (3) Scope: a saved Athena query pulls every CloudTrail event for the key ID; Detective profiles the user. (4) Hunt persistence: new users, keys, roles, and policy attachments since exposure. (5) Eradicate and recover: delete the key, rotate affected secrets, restore any modified resources. (6) Post-incident: root cause (why was a long-term key in a repo at all?) feeds a control change — replacing user keys with temporary credentials.

Testing. At the next game day, you plant a canary key, trigger the pipeline with GuardDuty sample findings, and time the run. The retro finds the approval page went to a stale rota — the playbook is updated. That loop, not the document, is the deliverable.