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.

Responder access must exist before the incident. Creating IAM permissions mid-incident is slow and error-prone, and if the incident is an IAM compromise it can be impossible or dangerous. Deploy a dedicated incident response role into every account (CloudFormation StackSets keeps it identical everywhere), scoped to what responders need: broad read for investigation plus targeted containment actions such as changing security groups, deactivating access keys, creating EBS snapshots and tagging. Responders reach it from the security tooling account, and every assumption is recorded in CloudTrail.

Two limits that break responder access in practice

• Role chaining caps the second hop at one hour. A responder who signs in through IAM Identity Center and then assumes the IR role in a member account is chaining roles. A chained AssumeRole that asks for more than 3,600 seconds fails — it is not quietly shortened. If responders need longer sessions, assign them a permission set in the member account so the first hop lands there directly, and let the permission set's session duration apply.
• The IR role is itself a target. An attacker with admin rights in a member account could edit or delete it. Protect it with an SCP that denies changes to the role (iam:UpdateAssumeRolePolicy, iam:DeleteRole, policy attach/detach and similar) unless aws:PrincipalArn matches the StackSets execution role that deploys it.

Break-glass access

Break-glass is the emergency path to elevated access for when normal sign-in is unavailable or compromised, so it must not depend on the thing that failed. If your workforce signs in through IAM Identity Center federated to an external identity provider, an IdP outage or compromise takes Identity Center access down with it; break-glass must not be another Identity Center user. A common design is a small number of IAM users in the security (or dedicated break-glass) account, each with a hardware MFA device, that can assume a break-glass role in member accounts. That is preferable to relying on each member account's root user, which is hard to secure and monitor at scale. Store the credentials out of band (for example a sealed safe or a password vault that does not use the same IdP), and alarm on every use: an EventBridge rule matching the ConsoleLogin event for the break-glass identities (delivered to the Region where the sign-in event is recorded) pages the security team.

Check break-glass against your own guardrails. SCPs apply to every role session in a member account, including sessions assumed from another account, and for a role session aws:PrincipalArn is the role ARN, not the user who assumed it. An SCP exception for break-glass must therefore name the break-glass role's ARN. Rehearse the path in drills — an untested break-glass role that an SCP silently blocks is discovered at the worst moment.

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.

The security alternate contact is how AWS reaches your security team about a problem in an account. AWS sends Trust & Safety abuse notices (for example, reports that your resources are attacking others) and other security notifications to the security contact in addition to the account's root email address, so an account with no security contact routes those warnings to whoever owns the root mailbox — often a billing or provisioning alias.

• Set it on every account centrally. With trusted access enabled for AWS Account Management, the management account or a delegated administrator can call PutAlternateContact for any member account, so one script or pipeline covers the organization.
• New accounts do not inherit it. Automate it at creation: an EventBridge rule on the Organizations CreateAccountResult event invokes a function that sets the contacts.
• AWS Health is a separate channel. Health events (such as notice that an access key was found exposed publicly) appear in the account's AWS Health dashboard and are emitted to EventBridge; they are not delivered by setting the security contact. Route them with EventBridge rules (or AWS Health organizational view) to the same responders.

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

For an exposed IAM user access key, the first containment step is to deactivate the key, not delete it. Deactivation stops authentication immediately and is reversible — if you picked the wrong key, or a production job turns out to depend on it, you reactivate it while you arrange a replacement. Deletion is permanent, so it is an eradication step taken after the investigation confirms nothing legitimate needs the key. (Deletion does not erase the investigation trail: CloudTrail events already recorded keep the access key ID.)

For a compromised IAM role, there is nothing to deactivate — STS credentials stay valid until they expire. The documented pattern is to revoke existing sessions with an inline deny conditioned on token age: "Effect": "Deny" on "Action": "*" with DateLessThan on aws:TokenIssueTime set to the current time. The direction matters: DateLessThan denies credentials issued before the cutoff; DateGreaterThan would deny the fresh sessions and leave the stolen ones working. The IAM console's Revoke active sessions action attaches exactly this as the AWSRevokeOlderSessions policy. Legitimate workloads recover by obtaining new credentials, which is why this beats deleting the role.

What does not end a live session

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

A dedicated forensics account is a separate member account that holds analysis tooling and receives shared evidence, with access limited to the forensics team. Because it is a separate account, the attacker's credentials in the compromised account have no reach into it.

Where the forensics account sits, and why

• Not the compromised account. Anything inside the affected account — a separate VPC, an Object Lock bucket, a restrictive KMS key policy — can still be undone or worked around by an administrator of that account. A separate VPC isolates the network only; S3 Object Lock in governance mode can be bypassed by a principal with s3:BypassGovernanceRetention; a key policy can stop someone reading evidence but not deleting the objects. Only an account boundary removes the attacker's control.
• Not the Log Archive account. Log Archive has one job — immutable, centrally delivered logs — and should hold nothing else. Running analysis instances there and granting investigators broad rights in it widens access to the record you most need intact.
• Not the management account. It cannot be restricted by SCPs and holds organization-wide power; keep workloads, including forensic ones, out of it.

A multi-account structure is itself a blast-radius control. CloudTrail writes to the log archive bucket through the CloudTrail service principal, so no workload principal needs write or delete rights there, and a compromise of a workload account cannot erase the trail you will investigate with.

Evidence that can actually be shared

EBS snapshots encrypted with the AWS managed key aws/ebs cannot be shared with another account, because AWS managed key policies cannot be changed. Plan the forensics flow around a customer managed key whose key policy allows the forensics account: copy the snapshot (re-encrypting under that key) and share the copy. Build and rehearse this before an incident, together with hardened analysis AMIs and an evidence bucket with retention controls.

The Automated Forensics Orchestrator for Amazon EC2 and EKS (the solution the exam guide lists under its earlier name, Automated Forensics Orchestrator for Amazon EC2) is a deployable AWS solution that turns evidence acquisition into an event-driven pipeline built on Step Functions and Lambda. It follows the same pattern as the event-driven remediation below: findings from GuardDuty, AWS Config or third-party tools reach Security Hub CSPM in the security account, EventBridge passes the instance ID to a Step Functions workflow, and the workflow triages the request — whether to acquire evidence (based on the instance's tags) and whether to isolate (based on the Security Hub action selected).

Acquisition then runs as two flows in parallel:

• Memory forensics flow: captures memory through Systems Manager while the instance is still running and stores it in S3. Only after memory is captured is the instance isolated, by attaching a new isolation security group — and only when the chosen action calls for isolation.
• Disk forensics flow: snapshots the EBS volumes and shares the snapshots with the forensics account. It does not wait for isolation.

When acquisition completes, an investigation workflow in the forensics account starts an instance from a forensic AMI, loads the memory data and attaches volumes created from the snapshots. The ordering rule to learn is memory before isolation, and never stop the instance: memory is the most volatile evidence, and stopping, hibernating-and-resuming or terminating an instance loses running processes, network connections and in-memory malware. Stopping the instance to "make it safe" destroys exactly what memory forensics needs.

Prerequisites you must build in advance

• The instance must be a Systems Manager managed node: SSM Agent installed, permissions (an instance profile, or Default Host Management Configuration — which still needs the agent), and a network path to the Systems Manager endpoints (internet or VPC endpoints). Bake the agent and instance profile into every AMI. Disk snapshots need none of this; memory capture does.
• Encryption keys that allow sharing (see the forensics account above).
• Know what isolation does not do. Changing an instance's security group stops new connections, but connections already tracked keep flowing; a network ACL deny on the subnet cuts established sessions at once. The containment detail is covered in the Task 2.2 lesson.
• Auto Scaling. If the instance is in an Auto Scaling group, protect it from scale-in (and detach or suspend replacement as your runbook requires) so the group does not terminate your evidence.

Preparing for a DDoS event with AWS Shield Advanced means everything is associated with your resources before the traffic arrives; nothing on this list can be set up quickly mid-attack.

• Protections on each internet-facing resource (CloudFront distributions, Route 53 hosted zones, Global Accelerator accelerators, Application Load Balancers and Classic Load Balancers, and Elastic IPs — a Network Load Balancer is protected through the Elastic IPs attached to it).
• Health-based detection: associate a Route 53 health check with each protection. Shield then uses the application's health to detect events faster and more accurately. A calculated health check built from CloudWatch alarms (for example on latency and 5xx rates) represents application health better than one probe.
• Proactive engagement lets the Shield Response Team (SRT) contact you when a protected resource's health check goes unhealthy during an event. Its prerequisites: a Route 53 health check associated with each protected resource, a Business or Enterprise Support plan (required for any SRT help), and emergency contacts on file.
• SRT access is a role you authorize: a role trusting drt.shield.amazonaws.com with the AWSShieldDRTAccessPolicy managed policy (historically the "DRT role"). It lets the SRT read your AWS WAF logs and call Shield and WAF APIs to help mitigate. Other data — ALB or CloudFront access logs, packet captures — needs extra bucket grants (up to 10 buckets through the console, more by editing bucket policies), and those buckets must be unencrypted or SSE-S3: the SRT cannot read objects encrypted with KMS keys.

Runbooks belong in executable form. A prose wiki page rots and gets misread under pressure; a Systems Manager Automation runbook encodes the same procedure as versioned steps that run under a scoped IAM role, take parameters, record every step's output and behave the same at 2 a.m. as in rehearsal. Standard response actions — isolate an instance, snapshot its volumes, deactivate a key, tag for quarantine — should each exist as a runbook that humans and event-driven automation can both start.

Running runbooks across accounts

Multi-account, multi-Region Automation uses two roles: an administration role (AWS-SystemsManager-AutomationAdministrationRole) in the central or delegated administrator account that starts the runs, and an execution role in every target account (deploy it with StackSets, scoped to what the runbook does). Custom runbooks must also be shared with the target accounts; AWS-owned runbooks need no sharing.

OpsCenter: where an issue is worked

Systems Manager OpsCenter records operational and security issues as OpsItems, each holding the affected resources, related data, status and associated runbooks a responder can run from the item. Its integration with Security Hub CSPM creates OpsItems from findings (critical and high severity by default) and keeps status in sync in both directions, so closing the OpsItem updates the finding's workflow status.

SageMaker AI notebooks: documented, exploratory investigation

Amazon SageMaker AI notebooks (Jupyter) keep queries, analysis code, results, charts and the analyst's notes together in one document that a colleague can re-run cell by cell and adapt for the next case. Choose a notebook when investigation is exploratory and changes per case — for example, Athena queries over CloudTrail and VPC Flow Logs followed by pandas analysis and a timeline chart. Choose an Automation runbook when the action is fixed and repeatable. Investigation notebooks often run with direct internet access disabled in a private subnet; then each service they call (Athena, S3, STS, SageMaker API and so on) needs a VPC endpoint.

Automatic remediation on AWS is an EventBridge rule that matches a finding or event and starts a response. The target can be a Systems Manager Automation runbook directly (no glue code), a Lambda function when you need logic the runbook cannot express, or a Step Functions state machine for a multi-step flow.

• It is Regional. GuardDuty publishes findings to EventBridge in the Region where they were generated. Deploy the rule in every Region where a detector runs, or forward events from each Region to one central event bus.
• Member findings arrive in the delegated administrator account. With GuardDuty managed through Organizations, the administrator account receives member findings, so central remediation runs there.
• Acting in another account means assuming a role there. The central function or runbook assumes a scoped remediation role in the member account. EC2 has no resource-based policies that could grant cross-account access, and a Lambda function's resource policy only controls who may invoke the function — it gives the function no rights in other accounts.

Automate a step unattended only when it is reversible, preserves evidence and cannot disrupt other workloads or traffic. Test every step against those three questions. Tagging an instance, enabling scale-in protection, snapshotting volumes and deactivating an access key usually pass. Isolating a production instance that serves customers, or revoking sessions on a role many workloads share, can cause an outage — those wait for a human decision.

Systems Manager approval steps

Step Functions approvals

Step Functions has no built-in approval state. Human approval uses a callback task with the .waitForTaskToken integration pattern: the state machine sends a task token (for example to an approver through SNS or an API) and waits until something calls SendTaskSuccess or SendTaskFailure with that token. Three constraints:

• Callbacks work in Standard workflows only; Express workflows support the Request Response pattern only.
• The token must be returned by a principal in the same account as the state machine.
• A fixed Wait state is not an approval: it cannot react to an early decision and continues whether or not anyone agreed.

Amazon Application Recovery Controller (ARC) recovers by moving traffic away from an impaired or quarantined environment — one Availability Zone with zonal shift, or one Region with routing controls (or ARC Region switch plans).

An untested plan is a hypothesis; choose the test by what it must prove. The validation methods form a ladder from cheap to realistic.

Fault Injection Service

AWS Fault Injection Service (FIS) injects real faults — instance stops and terminations, network disruption, API errors, AZ power interruption scenarios — from an experiment template. Stop conditions are CloudWatch alarms named in the template: if one enters ALARM, FIS stops the experiment itself (no EventBridge or Lambda wiring needed). For a multi-account game day, an orchestrator account owns the template, stop conditions and experiment logs, and the template has one target account configuration per target account — that account's ID and an IAM role in it that FIS assumes.

Do not confuse FIS with its neighbours. An ARC zonal shift is a recovery action (it moves traffic), not a failure injection, so it cannot test whether you detect a failure. A custom script lacks managed stop conditions and experiment records.

Resilience Hub

AWS Resilience Hub assesses an application against a resiliency policy that sets RTO and RPO targets per disruption type (application, infrastructure, Availability Zone, Region). An assessment estimates from configuration whether the targets can be met and recommends what to add — alarms, standard operating procedures and FIS experiments. Scheduled (daily) assessments detect drift and can notify an SNS topic. "Policy met" is an estimate, not evidence: FIS proves recovery by injecting the failure and timing it.

Every test ends with playbook iteration: measure time-to-detect and time-to-contain, record what confused people, update the runbooks and schedule the next exercise. Rehearse break-glass and cross-account role assumption too — they fail most often because they are used least.

The plan must name the tools responders use to answer who acted, what they touched and when — and enable them in advance, because most cannot see the past.

CloudTrail settings decided during preparation

• Management events record control-plane calls (principal, source IP, user agent) and are on by default in a trail. An organization trail feeding a central archive keeps the record complete.
• Data events (S3 object reads and writes, Lambda invocations, DynamoDB item operations) are off by default. If a playbook asks "which objects were read?", the answer exists only if data events were on. Scope them with advanced event selectors — for one bucket, a resources.ARN selector with StartsWith the bucket ARN — to control cost.
• Insights events flag unusual API call rates and error rates, for management events and for data events the trail already logs. They record anomalies, not per-object access.
• Log file integrity validation produces digest files that prove delivered logs were not altered — evidence that will be challenged needs it.

Investigation services

Amazon Detective builds a behavior graph from CloudTrail, VPC Flow Logs and GuardDuty findings so a responder can pivot from a finding to an entity's timeline. It does not backfill data from before it was enabled, so turning it on is a preparation step. Athena queries the CloudTrail logs already delivered to S3 with SQL, so it works on history regardless of when you start using it; save tested queries in advance. (CloudTrail Lake is closed to new customers since 31 May 2026 — existing event data stores keep working — so a new account plans on Athena or CloudWatch instead.) AWS Security Hub CSPM aggregates findings from GuardDuty, Macie, Inspector and partners in one place so triage starts from a single queue.

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/MaliciousIPCaller, a Trust & Safety abuse notification, or a developer self-report. Because security contacts are set on every account and an EventBridge rule routes 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, because other workloads may share those roles, so the Automation runbook waits at an aws:approve step for a named approver. (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, a tabletop walks the Health-event and abuse-notice paths with legal and communications in the room, then a sample finding of the relevant type exercises the GuardDuty path end to end, and the run is timed. The retro finds the approval page went to a stale rota — the playbook is updated. That loop, not the document, is the deliverable.