Overview of an AWS Incident Response Plan
An incident response plan in AWS is the formalized, written, and rehearsed sequence of actions your organization takes when a security event occurs in your cloud environment. The SCS-C02 exam treats the incident response plan as more than a document; it expects you to design technical controls, identify the right AWS services for each phase, codify roles and responsibilities, and automate as much of the incident response plan as possible so human responders are freed to make judgment calls instead of clicking through consoles.
The canonical reference for any AWS incident response plan is the AWS Security Incident Response Guide, which adapts NIST SP 800-61 to cloud-native realities. The whitepaper is explicitly cited in the SCS-C02 exam guide knowledge bullets, so every phase — Prepare, Detect, Analyze, Contain, Eradicate, Recover, Lessons Learned — is fair game on the exam. The incident response plan must also be account-aware: AWS Organizations, delegated administration, and cross-account roles change how detection, isolation, and forensics work compared to single-account setups.
This note walks through the SCS-C02 task 1.1 surface area end-to-end: you will see how to deploy the detection stack (GuardDuty, Security Hub, Macie, Inspector, Config, Detective, IAM Access Analyzer), how to wire ASFF findings through EventBridge to Lambda or Step Functions, how to invalidate IAM credentials when they are compromised, how to isolate an EC2 instance for forensic capture, and how to assign clear roles in your incident response plan RACI matrix. Every concept maps back to a specific exam-tested skill, so by the end you should be able to read a long SCS-C02 scenario and pick the correct incident response plan action without re-reading the question stem.
A documented, rehearsed, and partially automated set of procedures that defines how an organization detects, contains, eradicates, and recovers from security events affecting AWS resources, including the technical playbooks, the human roles, and the evidence-preservation rules that satisfy regulatory and forensic requirements. Anchor doc: https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/incident-response-objectives.html
Why SCS-C02 Cares About the Incident Response Plan
Domain 1 of SCS-C02 weighs 14% and three of its task statements (1.1, 1.2, 1.3) all touch the incident response plan directly. Task 1.1 specifically asks you to design and implement the incident response plan, while 1.2 and 1.3 cover the detection feeds and the actual response actions. The exam frequently presents scenarios that look like generic "best architecture" questions but are really testing whether you understand that the incident response plan must include automated containment, not just alerting.
A second reason the incident response plan dominates Domain 1 is that AWS treats it as a shared responsibility boundary. AWS gives you the building blocks (GuardDuty findings, Security Hub aggregation, EventBridge events, Lambda automation), but the customer must assemble them into a coherent incident response plan. The exam tests this assembly, not the existence of individual services.
When you see an SCS-C02 question that describes a compromise (leaked access key, cryptomining EC2, public S3 bucket discovered by Macie), the correct answer is almost always the option that automates containment via EventBridge + Lambda or Step Functions and preserves forensic evidence before remediation. Options that say "manually" or "send an email and wait" are distractors. Reference: https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/incident-response.html
The Seven-Phase AWS Incident Response Lifecycle
The AWS Security Incident Response Guide structures the incident response plan into seven phases. Memorize these in order — exam questions often reference them by name or describe scenarios that map to a specific phase.
Phase 1 — Prepare
Preparation is everything you do before an incident: enable GuardDuty in every account and region, turn on Security Hub with delegated admin, deploy a centralized CloudTrail organization trail, pre-create IAM roles for forensic responders, and pre-stage a clean forensic VPC in an isolated security account. The incident response plan should also include pre-written runbooks stored in Systems Manager Documents.
Phase 2 — Detect
Detection feeds the incident response plan from GuardDuty, Macie, Inspector, IAM Access Analyzer, AWS Config rules, CloudWatch alarms, and third-party tools. All findings should normalize into ASFF and land in Security Hub.
Phase 3 — Analyze
Triage answers the question "is this a real incident?" Use Amazon Detective to pivot from a GuardDuty finding into a graph of related API calls, VPC flows, and Kubernetes audit log entries.
Phase 4 — Contain
Containment limits blast radius without destroying evidence. For IAM, this means setting access keys to inactive or attaching a deny-all policy. For EC2, isolate via security group swap. For S3, apply a restrictive bucket policy.
Phase 5 — Eradicate
Eradication removes the threat: terminate compromised instances after snapshot capture, rotate all secrets, revoke active sessions, patch the root cause vulnerability via Inspector findings.
Phase 6 — Recover
Recovery restores service: launch replacement instances from a hardened AMI, restore data from immutable backups, re-enable application traffic.
Phase 7 — Lessons Learned
Post-incident review feeds back into the incident response plan: update runbooks, add new GuardDuty suppression rules, tighten SCPs, file IaC changes for any drift detected.
P-D-A-C-E-R-L — Prepare, Detect, Analyze, Contain, Eradicate, Recover, Lessons-learned. The exam loves to reorder these in distractors; memorize the sequence so a question that says "after containment but before recovery, what should the team do?" immediately maps to Eradicate. https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/incident-response-lifecycle.html
Roles and Responsibilities — The RACI Matrix
The SCS-C02 exam guide explicitly lists "Roles and responsibilities in the incident response plan" as a knowledge bullet. AWS recommends a RACI-style matrix where each phase has exactly one Accountable owner and clearly named Responsible executors. A typical cloud incident response plan RACI looks like this:
| Phase | IR Commander | Security Engineer | SOC Analyst | App Owner | Compliance Officer |
|---|---|---|---|---|---|
| Detect | I | C | R | I | I |
| Analyze | A | R | R | C | I |
| Contain | A | R | C | C | I |
| Eradicate | A | R | I | C | I |
| Recover | C | C | I | R | I |
| Lessons Learned | A | R | R | R | R |
R = Responsible, A = Accountable, C = Consulted, I = Informed. The IR Commander is the single point of decision authority during the incident; the Security Engineer physically executes the AWS console / CLI commands; the SOC Analyst monitors Security Hub and Detective dashboards; the Application Owner decides whether to accept downtime; the Compliance Officer handles regulator notification.
The incident response plan must also pre-create the IAM roles these humans assume. AWS recommends a dedicated SecurityIncidentResponseRole in a forensic account with permissions to read CloudTrail, take EBS snapshots, run SSM commands, and modify security groups — but not to delete CloudTrail or modify Config rules (separation of duties).
The incident response plan must pre-create cross-account IAM roles so responders never use their daily-driver credentials during an incident. The role should live in a dedicated security tooling account per the AWS Security Reference Architecture and be assumable only via MFA + STS. SCS-C02 questions about "least-privilege incident access" expect this pattern.
Deploying the AWS Detection Stack
A working incident response plan requires telemetry. SCS-C02 task 1.1 lists seven services as the canonical detection stack: AWS Security Hub, Amazon Macie, Amazon GuardDuty, Amazon Inspector, AWS Config, Amazon Detective, and AWS IAM Access Analyzer. You must know what each one does and how to deploy it organization-wide.
GuardDuty — the threat detector
Amazon GuardDuty continuously analyzes CloudTrail management events, CloudTrail S3 data events, VPC Flow Logs, DNS logs, EKS audit logs, RDS login events, and Lambda invocations to detect threats like cryptocurrency mining, anomalous IAM behavior, port scanning, and credential exfiltration. Enable GuardDuty via Organizations delegated admin so every member account is auto-enrolled.
Security Hub — the aggregator
AWS Security Hub consumes findings from GuardDuty, Macie, Inspector, IAM Access Analyzer, Config, Firewall Manager, and dozens of partner products, normalizes them all into ASFF, and runs continuous compliance checks against standards like CIS AWS Foundations, AWS Foundational Security Best Practices, PCI DSS, and NIST 800-53. Aggregate findings cross-region in a single home region.
Macie — the data classifier
Amazon Macie scans S3 buckets for sensitive data (PII, credentials, PHI) using managed and custom data identifiers. Macie findings flow into Security Hub via ASFF, so the incident response plan can trigger automated remediation when sensitive data is found in a public bucket.
Inspector — the vulnerability scanner
Amazon Inspector v2 continuously scans EC2 instances, container images in ECR, and Lambda functions for CVEs and unintended network exposure. Findings normalize to ASFF and feed Security Hub.
AWS Config — the configuration recorder
AWS Config records every resource configuration change and evaluates resources against rules (managed or custom Lambda-backed). Config Conformance Packs let you deploy entire compliance frameworks in one CloudFormation stack.
Detective — the investigation tool
Amazon Detective ingests CloudTrail, VPC Flow Logs, and GuardDuty findings into a behavior graph that lets analysts pivot across entities (IAM principals, EC2 instances, IP addresses) during the Analyze phase.
IAM Access Analyzer — the policy auditor
IAM Access Analyzer finds resources (S3 buckets, IAM roles, KMS keys, Secrets Manager secrets, Lambda functions, SQS queues) that are shared with external principals. New external access generates a finding that flows to Security Hub.
For each of the seven services, designate a single delegated administrator account (typically the Security Tooling account from the SRA) via AWS Organizations. This auto-enables the service in all current and future member accounts and centralizes findings in the home region. Without delegated admin you would invite every account manually — a common SCS-C02 wrong-answer pattern. https://docs.aws.amazon.com/securityhub/latest/userguide/designate-orgs-admin-account.html
ASFF — The Common Currency of the Incident Response Plan
AWS Security Finding Format (ASFF) is the JSON schema that every Security Hub finding follows. The SCS-C02 exam guide lists ASFF explicitly under task 1.1 knowledge. Knowing the key fields is the difference between writing a working EventBridge rule and a broken one.
Critical ASFF fields the incident response plan automation will read:
SchemaVersion— always"2018-10-08"IdandProductArn— uniquely identify the findingGeneratorId— which detector created it (e.g., a GuardDuty rule ID)AwsAccountId— which member account it came fromTypes— taxonomy like"TTPs/Initial Access/UnauthorizedAccess:IAMUser-InstanceCredentialExfiltration"Severity.Label—INFORMATIONAL,LOW,MEDIUM,HIGH,CRITICALResources[]— affected ARNs; this is what your playbook will isolateWorkflow.Status—NEW,NOTIFIED,SUPPRESSED,RESOLVEDRecordState—ACTIVEorARCHIVED
Every finding entering Security Hub — whether from a native AWS service or a third-party SIEM — must be ASFF-compliant. This standardization is what allows your incident response plan to write one EventBridge rule that handles findings from any source.
A standardized JSON schema for security findings, defined by AWS Security Hub, that allows native AWS services and third-party tools to emit findings in a common shape so EventBridge rules and downstream automation can act on them uniformly. Reference: https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-findings-format.html
EventBridge as the Incident Response Bus
Once findings are in ASFF inside Security Hub, Amazon EventBridge is the engine that drives the incident response plan. Security Hub automatically publishes every finding to the default event bus as a Security Hub Findings - Imported event. Your job is to write EventBridge rules with content-filter patterns that match specific finding types and route them to the right target.
A canonical pattern: a single rule matching Types containing UnauthorizedAccess:IAMUser triggers a Step Functions state machine that (1) fetches the IAM user from the finding, (2) calls iam:UpdateAccessKey to set the key inactive, (3) attaches a deny-all policy as a precaution, (4) creates a JIRA ticket via Lambda, and (5) updates the Security Hub finding's Workflow.Status to NOTIFIED.
For higher-severity findings the rule can fan out: same EventBridge rule, multiple targets — Step Functions for automation, SNS for human paging via PagerDuty, Kinesis Firehose for long-term archival in S3 + Athena query.
A frequent SCS-C02 distractor: candidates assume a Security Hub EventBridge rule in us-east-1 will see findings from eu-west-1. It will not. You must enable cross-region aggregation in Security Hub and write the EventBridge rule in the aggregator region. Findings keep their original region in the ASFF Region field but are imported into the aggregator's event bus. Reference: https://docs.aws.amazon.com/securityhub/latest/userguide/finding-aggregation.html
Runbooks vs Playbooks — Don't Mix Them Up
SCS-C02 explicitly distinguishes runbooks from playbooks, and the exam likes to test that you know which is which.
A runbook is a step-by-step procedure for a known, repeatable task — for example, "isolate an EC2 instance for forensic capture." A runbook is deterministic: input → exact steps → output. AWS implements runbooks as Systems Manager Automation Documents (SSM Documents), which you author in YAML or JSON and execute via aws ssm start-automation-execution.
A playbook is a higher-level decision tree that orchestrates multiple runbooks plus human decisions in response to a class of incident — for example, "respond to suspected credential compromise." A playbook contains branching logic ("is the principal a human user or a service role?", "did the attacker access S3 or EC2?") that picks which runbooks to invoke. AWS implements playbooks as Step Functions state machines calling SSM runbooks, Lambda functions, and human-approval steps.
The incident response plan stores both: SSM runbooks for the deterministic mechanics, Step Functions playbooks for the orchestration.
Runbook = how to do one specific task (SSM Document). Playbook = how to handle a class of incident, calling multiple runbooks (Step Functions). If the SCS-C02 question says "the team needs a single deterministic procedure for instance isolation," answer SSM. If it says "the team needs to coordinate isolation, evidence capture, ticketing, and notification," answer Step Functions. https://docs.aws.amazon.com/systems-manager/latest/userguide/automation.html
IAM Credential Compromise Response Sequence
Compromised IAM credentials are the most common SCS-C02 incident scenario. The incident response plan must execute these steps in this exact order — getting the order wrong is a classic exam trap.
Step 1 — Detect. GuardDuty emits an UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS or UnauthorizedAccess:IAMUser/ConsoleLoginSuccess.B finding when an EC2 instance role's credentials are used from outside AWS, or when a root user logs in from an unusual location. CloudTrail data events on S3 buckets can also seed Detective with the attacker's API call history.
Step 2 — Preserve evidence. Before you change anything, ensure CloudTrail is logging to an S3 bucket with S3 Object Lock enabled in compliance mode. Take a manual snapshot of any CloudTrail buckets in the affected account if not already centralized.
Step 3 — Invalidate the credentials. For an IAM user with leaked access keys, call aws iam update-access-key --status Inactive immediately. Do not delete — inactive keys preserve audit trail; deleted keys lose attribution. For an IAM role with leaked temporary credentials, attach an inline deny-all policy with a Condition on aws:TokenIssueTime to revoke active sessions older than now (the revoke active sessions pattern).
Step 4 — Apply a deny-all SCP. If the compromise is severe, attach an SCP at the OU level that denies all actions for the affected account except IR responder roles. This is the AWS equivalent of pulling the network cable.
Step 5 — Rotate. Rotate all other credentials the principal had access to: database passwords in Secrets Manager (use rotation Lambdas), KMS customer-managed keys (rotate or alias-swap), API keys in Parameter Store, third-party tokens.
Step 6 — Investigate root cause. Use Detective to trace the principal's full API history, identify the initial entry vector (was the key in a public GitHub repo? Did an EC2 metadata service IMDSv1 get scraped?), and patch.
Step 7 — Recover and document. Issue new credentials via least-privilege roles, update the incident response plan runbook with any new IOCs, and add a GuardDuty suppression rule only if the finding type is a known false positive.
A high-frequency SCS-C02 distractor offers "delete the access key" as the immediate response to a leaked key. Wrong. Setting the key to Inactive preserves CloudTrail attribution so Detective and forensics can reconstruct what the attacker did with the key. Delete only after the investigation is complete. Reference: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_RotateAccessKey
EC2 Instance Isolation Runbook
When GuardDuty raises a Backdoor:EC2/C&CActivity.B!DNS or CryptoCurrency:EC2/BitcoinTool.B finding, the incident response plan must isolate the instance for forensic capture without destroying volatile evidence. The canonical runbook order:
1. Detach from Auto Scaling Group. Use aws autoscaling detach-instances --no-should-decrement-desired-capacity so ASG launches a replacement and stops sending traffic to the compromised host. The instance survives but is no longer in the load-balanced fleet.
2. Replace the security group with a quarantine SG. Create a security group that allows no inbound and no outbound traffic except to the forensic responder's bastion. Apply via aws ec2 modify-instance-attribute --groups sg-quarantine. This severs C2 traffic without shutting the instance down, so memory contents survive.
3. Snapshot every attached EBS volume. Call aws ec2 create-snapshot on each volume. Tag the snapshot with the GuardDuty finding ID and incident ticket. Copy the snapshot to a forensic account via cross-account KMS-encrypted snapshot copy.
4. Capture a memory dump via SSM. If the instance has the SSM Agent installed (recommended baseline), invoke a Run Command document that runs lime or avml to dump RAM to a forensic S3 bucket with Object Lock enabled.
5. (Optional) Move to a forensic VPC. If you need network-level analysis, swap the ENI to a subnet in an isolated forensic VPC where you can run packet capture without affecting production.
6. Terminate only after evidence is preserved. Termination releases the instance store and ephemeral state, so it must be the last step.
SCS-C02 questions love to scramble this order. The rule: never terminate before snapshotting, never snapshot before isolating (because the attacker could still be writing to disk), and never change SG before detaching from ASG (because the load balancer health check failure could mask attacker activity in CloudWatch noise). Reference: https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/forensics-ou.html
Forensic Account Pattern
The AWS Security Reference Architecture recommends a dedicated Forensics OU containing one or more forensic accounts that are normally empty and locked down. During an incident, EBS snapshots and memory dumps are copied into the forensic account where IR responders can mount them on a sterile analysis instance without contaminating the source environment.
Key controls in the forensic account:
- S3 buckets with Object Lock in compliance mode for evidence
- KMS keys with policies that allow
kms:Decryptonly by named IR roles - SCP that prevents the forensic account from initiating outbound connections to production
- CloudTrail data events on the evidence S3 bucket so every read is itself logged
The auditable, tamper-evident record of who accessed each piece of forensic evidence and when. In AWS this is implemented via S3 Object Lock + CloudTrail data events + KMS key policies that restrict decrypt to named IR roles. The incident response plan must establish chain of custody before any responder downloads a snapshot. https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/forensics.html
Multi-Account Deployment via Delegated Administration
A real-world incident response plan spans an Organization with dozens of accounts. SCS-C02 expects you to know how to deploy each detection service org-wide via delegated administration, not by logging into every member account.
The standard pattern, anchored by the AWS Security Reference Architecture:
- Designate a Security Tooling account in the Security OU.
- From the Organizations management account, register Security Tooling as the delegated administrator for GuardDuty, Security Hub, Macie, Inspector, Config, Detective, and IAM Access Analyzer.
- From the Security Tooling account, enable each service for "all current and future member accounts" via auto-enable settings.
- In Security Hub, designate a single finding aggregator region (typically
us-east-1for North American workloads) and link all other regions to it. - Deploy a centralized Organization Trail writing to a Log Archive account's S3 bucket with Object Lock.
- Cross-account IR roles in every member account, assumable only from the Security Tooling account with MFA.
SRA splits these into two accounts: Log Archive stores immutable logs (Object Lock, no human read access), Security Tooling runs the detection services and analysis. Mixing them is a common SCS-C02 wrong answer. https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/log-archive.html
Automating the Incident Response Plan with Step Functions
When the incident response plan outgrows simple Lambda functions, AWS Step Functions becomes the orchestration layer. A Step Functions state machine can express the EC2 isolation runbook as a deterministic graph: parallel branches for snapshot + memory dump + SG swap, a Choice state to decide whether to invoke the forensic VPC migration, a Wait state for human approval before termination, and built-in retry/catch on every AWS SDK call.
Step Functions integrates natively with EventBridge: a Security Hub finding lands on the bus, an EventBridge rule's target is arn:aws:states:...:stateMachine:IncidentResponse, and the state machine receives the entire ASFF JSON as input. Within the state machine, intrinsic functions extract Resources[0].Id to get the instance ARN, AwsAccountId to know which member account to assume role into, and Severity.Label to branch on critical-vs-high.
A mature incident response plan has multiple state machines — one per incident class (IAM compromise, EC2 compromise, S3 exposure, sensitive-data leak via Macie) — and a top-level "router" state machine that picks which child to invoke based on ASFF Types.
Human-in-the-Loop Approvals
Not every step in the incident response plan should be fully automated. Termination, key deletion, and SCP changes that could lock out humans need a checkpoint. Step Functions implements this via the Wait for Callback (.waitForTaskToken) integration pattern: the state machine pauses, sends a Slack/PagerDuty/email approval request with a callback URL, and resumes only when an approver clicks. The callback URL is short-lived (24h default) and tied to the IR Commander's authenticated session.
For SCS-C02, recognize that automation does not mean unattended. The exam will reward answers that combine automation (instant containment) with human gating (irreversible eradication).
Lessons Learned and Continuous Improvement
The seventh phase of the incident response plan is post-incident review. Within 5 business days of incident closure, the IR Commander runs a blameless retrospective covering: timeline reconstruction, MTTD (mean time to detect), MTTR (mean time to respond), gaps in detection coverage, gaps in runbook coverage, IOCs to add to threat intel feeds, and IaC changes needed to prevent recurrence.
Outputs feed back into:
- New AWS Config rules to detect the misconfiguration that enabled the incident
- New Security Hub custom insights to surface similar patterns proactively
- New GuardDuty suppression rules only for confirmed false-positive types
- Updated SSM runbooks with any manual steps that arose
- Updated Step Functions playbooks if the orchestration logic missed a case
- Updated SCPs if the blast radius could be reduced organization-wide
A common SCS-C02 wrong answer is "update the wiki." The right answer is "submit a CloudFormation/Terraform PR that codifies the new control." The incident response plan is only as strong as the version-controlled infrastructure that backs it. https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec-incident-response-lessons.html
Common SCS-C02 Pitfalls in Incident Response Questions
After reviewing dozens of community write-ups about the SCS-C02 exam, these are the recurring traps in incident response plan questions:
Pitfall 1 — Picking "manual" answers. Any option that says "the SOC analyst will manually..." or "send an email and wait for review" is almost always wrong. The exam favors automated containment.
Pitfall 2 — Forgetting cross-region aggregation. Questions often describe a multi-region workload and ask how to centralize findings. The answer involves Security Hub finding aggregator + organization-wide delegated admin, not per-region SNS topics.
Pitfall 3 — Mixing up Detective and Security Hub. Security Hub aggregates findings; Detective investigates them. Detective is for the Analyze phase, Security Hub for Detect/triage.
Pitfall 4 — Deleting access keys instead of deactivating. Delete destroys attribution. Inactive preserves it. For SCS-C02, always pick Inactive first.
Pitfall 5 — Terminating EC2 before snapshotting. Termination releases instance store and ephemeral disks. Snapshot first.
Pitfall 6 — Using IMDSv1. Many credential-exfiltration scenarios assume IMDSv1; the prevention answer is to enforce IMDSv2 via SCP and Config rule.
Pitfall 7 — Forgetting Object Lock on evidence buckets. Without Object Lock the attacker (or a misconfigured Lifecycle rule) could destroy evidence. Compliance mode for regulated workloads.
Multiple SCS-C02 study reports note that answer options describing console-driven workflows ("the engineer logs into the console and...") are often distractors. AWS prefers automated, API-driven, code-defined responses for the incident response plan. https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/automate-actions.html
Frequently Asked Questions
Q1: What is the difference between a runbook and a playbook in an AWS incident response plan?
A runbook is a deterministic step-by-step procedure for one specific task (e.g., "isolate an EC2 instance"), implemented as an SSM Automation Document. A playbook is a higher-level orchestration that combines multiple runbooks plus decisions and human approvals to handle an incident class, implemented as a Step Functions state machine. The incident response plan uses both: runbooks for mechanics, playbooks for coordination.
Q2: When a compromised IAM access key is detected, should I delete it or deactivate it?
Always deactivate first by setting the key status to Inactive. This stops the attacker immediately while preserving CloudTrail attribution so investigators can reconstruct what the attacker did. Only delete the key after the investigation phase is complete and you no longer need to attribute historical API calls.
Q3: How does ASFF help my incident response plan?
ASFF (AWS Security Finding Format) is a standardized JSON schema that all AWS security services emit findings in. Without ASFF, your incident response plan would need separate parsers for GuardDuty, Macie, Inspector, etc. With ASFF, a single EventBridge rule pattern can match findings from any source, and your Step Functions playbooks have a predictable input shape.
Q4: Can I deploy GuardDuty, Security Hub, and the rest of the detection stack to all my accounts without logging into each one?
Yes — use delegated administration via AWS Organizations. From the management account, register a single Security Tooling account as the delegated admin for each service, then enable "auto-enable for new accounts." Existing accounts are auto-enrolled, and any future member account joins automatically. This is the canonical pattern in the AWS Security Reference Architecture.
Q5: What is the correct order of EC2 instance isolation steps?
- Detach from the Auto Scaling Group (so ASG launches a replacement and the load balancer stops sending traffic), 2) Replace the security group with a quarantine SG that allows no inbound or outbound except to the IR bastion, 3) Snapshot all attached EBS volumes, 4) Capture a memory dump via SSM Run Command, 5) Optionally migrate to a forensic VPC, 6) Terminate only after evidence is preserved. Never terminate first.
Q6: Where should forensic evidence (snapshots, memory dumps, CloudTrail logs) be stored?
In a dedicated forensic account within a Forensics OU, in S3 buckets with Object Lock in compliance mode. The KMS key encrypting the evidence should have a key policy that allows decrypt only by named IR responder roles. CloudTrail data events on the evidence bucket establish chain of custody.
Q7: How do I handle an incident that spans multiple AWS regions?
Enable Security Hub cross-region finding aggregation in a single home region (typically the region closest to your IR team). All findings from all regions flow into the home region's event bus. Write your EventBridge rules in the aggregator region only. The original region is preserved in the ASFF Region field so playbooks can route region-specific actions.
Q8: What roles should I pre-create in my incident response plan?
At minimum: IR Commander (decision authority), Security Engineer (executes containment and eradication), SOC Analyst (monitors detection feeds and triages), Application Owner (assesses business impact), Compliance Officer (handles external notifications). Each role should map to a pre-staged IAM role in the Security Tooling account, assumable only with MFA, with permissions scoped to that phase of the incident response plan.
Q9: Does the SCS-C02 exam require me to memorize ASFF field names?
You do not need to recite every ASFF field, but you must recognize the key ones in scenario questions: Types, Severity.Label, Resources[], AwsAccountId, Workflow.Status, and RecordState. Questions about EventBridge filter patterns or finding suppression often hinge on these fields.
Q10: How does the incident response plan integrate with AWS Organizations SCPs?
SCPs are a containment tool of last resort. During a severe incident, the incident response plan can attach a deny-all SCP to the affected account's OU (with a carve-out for IR responder roles) to immediately revoke all permissions in that account — equivalent to pulling the network cable. SCPs are also used preventively via Lessons Learned to enforce baseline controls like IMDSv2-only or no-public-S3 across the entire organization.
Summary
The SCS-C02 incident response plan is the orchestrated combination of seven phases (Prepare, Detect, Analyze, Contain, Eradicate, Recover, Lessons Learned), seven detection services (GuardDuty, Security Hub, Macie, Inspector, Config, Detective, IAM Access Analyzer), one common finding format (ASFF), one event bus (EventBridge), and a clear RACI matrix of human roles. Master the IAM credential compromise sequence, the EC2 isolation runbook order, and the runbook-vs-playbook distinction, and you will recognize the correct answer in any incident response plan scenario the SCS-C02 exam throws at you. Always favor automated containment, evidence preservation before remediation, deactivation over deletion, and delegated administration over per-account configuration. The incident response plan is the connective tissue of Domain 1 — every other Domain 1 topic (threat detection, compromised resource response) plugs into it.