Incident Response

Picture a GuardDuty finding firing at 2 a.m.: do you start snapshotting volumes, or do you wish you had already built the runbook that tells you to? That single question is the whole domain. AWS frames cloud incident response on the NIST SP 800-61 lifecycle: preparation, then detection and analysis, then containment, eradication, and recovery, then post-incident activity. The split that organizes these two subtopics is preparation versus everything after the alarm. Incident response planning is the PREPARE half: the runbooks, break-glass access, forensic account, and game-days you stand up before any finding fires. Responding to security events is the RESPOND half: the live forensic capture, containment, eradication, and root-cause analysis you execute when one does. The classic exam trap lives at the seam between them: when a stem says an instance is actively compromised, the tempting answer is to stop or terminate it, but that destroys volatile memory and tips off the attacker. The lifecycle says capture evidence first, then contain, because the preparation phase already gave you the pre-staged access to do so without scrambling.

Read the two subtopics in lifecycle order. Incident response planning covers the preparation phase: pre-stage least-privilege responder access as dedicated break-glass IAM roles (with MFA and full CloudTrail logging) that responders assume only during a declared incident, keep response and forensic work in a separate security account so an attacker who holds the workload account cannot tamper with evidence, codify repeatable steps as Systems Manager Automation runbooks aggregated through OpsCenter, and then prove the plan works by running game-days with AWS Fault Injection Service. Responding to security events covers the live phases: capture EBS snapshots and instance memory before you touch anything, contain a live host by replacing its security groups with a no-rules isolation group plus a deny-all network ACL to cut already-tracked connections, revoke leaked credentials with an AWSRevokeOlderSessions policy rather than only isolating the host, and use Amazon Detective's behavior graph for the eradication and recovery decisions that follow. Each detection service plays exactly one role here: GuardDuty detects, Security Hub aggregates and prioritizes, and Detective investigates root cause, so a stem about root-cause analysis points to Detective, never GuardDuty.

Across this whole domain the default the exam prefers is the one that protects evidence and limits blast radius rather than the one that acts fastest. Preserve before you act: take the forensic copy before any stop, terminate, or reboot, because volatile state is unrecoverable once the host changes. Isolate the work, not just the host: move snapshots, memory images, and logs into a dedicated forensics account and store them write-once in an S3 bucket with Object Lock, so a compromise of the workload account cannot reach the evidence or the responders' tooling. And design for a small blast radius before you need it, since account segmentation, scoped IAM, and resource tagging (for example Status=quarantine) let automation target exactly the affected resource. Between an answer that contains immediately and one that captures evidence first, choose capture; between cleaning up in place and isolating in a separate account, choose isolation.