SCS-C03 · Domain 2 · Incident Response (14%) · Day 2 of 3
Automated remediation and forensics
In Day 1 you wrote incident response plans and runbooks, prepared accounts and tested the plan with AWS FIS. Today the runbooks run by themselves: EventBridge rules on findings, Security Hub automation rules and custom actions, Config auto-remediation with Systems Manager Automation, Step Functions workflows and the Automated Forensic Orchestrator, and recovery with Application Recovery Controller. Then the evidence side: isolating an instance without destroying it, capturing memory and disks, and storing artifacts in a locked forensic account with a chain of custody.
Skill 2.1.4 automatic remediationSkill 2.2.1 capture and store forensic artifacts~90 min read + 30 min lab
01
Event-driven remediation with EventBridge and Lambda
Day 1 wrote the plan and the runbooks. Today the runbooks start to run by themselves. Skill 2.1.4 asks you to use AWS services to automatically remediate incidents. Almost every automatic answer starts the same way: a security service creates a finding, the finding becomes an event, and an Amazon EventBridge rule sends that event to something that acts.
The three event sources you must know are GuardDuty (threats), Security Hub (all findings in one format) and AWS Config (configuration compliance). The most common targets are Lambda for a small fix, Step Functions for a workflow, Systems Manager Automation for a runbook, and SNS to tell people.
Concept profile
EventBridge rule for security findings
often confused with Polling the findings API on a schedule
?What is it?
A rule on an event bus with an event pattern. When an event matches the pattern, EventBridge sends it to up to five targets, such as a Lambda function, a Step Functions state machine, an SSM Automation runbook or an SNS topic.
⚙How does it work?
GuardDuty sends events with source: aws.guardduty and detail-type: GuardDuty Finding. New findings arrive in near real time.
Repeat occurrences of the same finding are grouped. The default is every 6 hours; the GuardDuty administrator can choose 15 minutes or 1 hour instead.
Security Hub sends Findings - Imported automatically for every new or updated finding, and Findings - Custom Action when an analyst presses a custom action.
Filter on fields inside detail, such as severity, finding type, account ID or resource tags, so the target only runs for what matters.
Add a retry policy and a dead-letter queue so a failed target call is not lost.
{ }Structure
Three finding sources, one rule, the right target for each job.
⇄EventBridge rule vs Polling the findings API on a schedule
EventBridge rule
Scheduled polling
Speed
Seconds after the event
Only as often as the schedule
Cost
Pay per event
Runs even when nothing happened
Code
Pattern is configuration
You write the filter logic
Missed events
Retry + DLQ
Easy to miss between runs
Exam hint
“automatically”, “as soon as”
Rarely the best answer
!Common mistakes the exam tests
Expecting GuardDuty updates to a finding in real time: repeats are grouped (default 6 hours). Only the first occurrence is near real time.
Expecting suppressed GuardDuty findings to reach EventBridge: findings archived automatically by suppression rules are not sent.
Building the rule in every member account: aggregate in the administrator account (GuardDuty and Security Hub) and respond from there.
Giving the Lambda function broad admin rights: give it only the actions the fix needs, for example ec2:ModifyInstanceAttribute.
Auto-remediating everything: for production, a wrong automatic action can cause an outage. Use tags and severity filters, or ask a human first.
✓Benefits and use cases
Revoke a leaked IAM access key a few seconds after GuardDuty sees it used.
Quarantine an EC2 instance that talks to a crypto-mining pool.
Send high severity findings to the on-call team, everything else to a ticket queue.
Think of it like · a smoke alarm system in a hotel
Detect, signal, act, without waiting for a person to walk by.
AWS concept
Familiar thing
Security finding
≈
A smoke detector senses smoke in one room
EventBridge event
≈
The detector sends a signal to the central panel
Event pattern
≈
The panel rule: ‘only floor 3, only heavy smoke’
Lambda target
≈
Sprinklers in that one room turn on
SNS target
≈
The night manager’s phone rings
6-hour grouping of repeats
≈
The panel doesn’t ring again for the same room every minute
Real AWS example · event pattern for high severity EC2 findings
This pattern matches GuardDuty findings with severity 7 or higher about EC2 instances. The rule then starts an isolation Lambda function.
GuardDuty severity is a number: 7.0 to 8.9 is High, 9.0 and above is Critical, so >= 7 catches both.
Exam-style scenario
A company runs GuardDuty in 30 accounts with a delegated administrator. When GuardDuty reports that an IAM access key is being used from a known malicious IP address, the key must be deactivated within one minute, in any account. What is the most operationally efficient design?
A. Ask each account owner to check the GuardDuty console every hour.
B. In the administrator account, create an EventBridge rule that matches the finding type and invokes a Lambda function, which assumes a role in the affected account and deactivates the key.
C. Schedule a Lambda function every 6 hours to list findings.
D. Export findings to S3 and query them with Athena daily.
Show the worked answer
Answer: B
The administrator account receives findings from all members. EventBridge reacts in near real time, and one function with a cross-account role works everywhere.
Why not the others
A: Manual and far too slow.
C: Polling every 6 hours misses the one-minute target.
D: Good for analysis, not for response.
How the exam tests this
“React automatically to a GuardDuty finding”→ EventBridge rule → Lambda.
“One rule for findings from all accounts”→ Rule in the administrator / aggregation account.
“Only react to high severity”→ Filter on detail.severity in the pattern.
“Failed invocations must not be lost”→ Target retry policy + DLQ.
“Get repeat findings every 15 minutes”→ Change the notification frequency (admin).
Must remember
Finding → event → EventBridge rule → target.
GuardDuty: aws.guardduty / GuardDuty Finding.
Repeats grouped: 6 h default, or 15 min / 1 h.
Security Hub: Imported (auto) vs Custom Action (analyst).
Security Hub collects findings from GuardDuty, Inspector, Macie, Config, IAM Access Analyzer and partners into one format, the AWS Security Finding Format (ASFF). The current docs call this service AWS Security Hub CSPM. It gives you two different automation tools, and the exam likes to mix them up.
Automation rules change the finding itself as it arrives, with no code. Custom actions are buttons an analyst presses in the console to send chosen findings to EventBridge, so a person decides and automation does the work.
Concept profile
Security Hub automation rules
often confused with Security Hub custom actions
?What is it?
Rules in the Security Hub administrator account. Each rule has criteria (for example product name, resource tag, account, severity) and actions that update fields of matching findings automatically.
⚙How does it work?
Actions can update Severity, Workflow status (for example SUPPRESSED), Note, Confidence, Criticality, Types, UserDefinedFields, VerificationState and RelatedFindings.
Up to 100 rules per administrator account. Rules are Region-specific, so create them in each Region (or in your aggregation setup).
Lower RuleOrder runs first; a later rule wins when two rules change the same field.
Rules run on new and updated findings from BatchImportFindings after the rule exists. They are not triggered by BatchUpdateFindings.
The updated finding is then sent to EventBridge as Findings - Imported, so a rule there can act on the new severity.
{ }Structure
Automation rules change findings; custom actions let a person send findings onwards.
⇄Automation rules vs Security Hub custom actions
Automation rules
Custom actions
Who starts it
Security Hub, automatically
An analyst in the console
What it does
Updates finding fields
Sends findings to EventBridge
Code needed
No
A target (Lambda, Step Functions…)
Limit
100 rules per admin account
50 custom actions; up to 20 findings at a time
Event detail-type
Findings - Imported (after update)
Findings - Custom Action
!Common mistakes the exam tests
Using a custom action when the requirement says without human interaction: that is an automation rule or an EventBridge rule on Imported findings.
Using an automation rule to fix a resource: automation rules only change the finding. Fixing the resource needs EventBridge plus Lambda, SSM or Step Functions.
Suppressing a noisy control with a rule when the control is not needed at all: disable the control instead; that also stops the checks and their cost.
Forgetting that rules are per Region.
Creating custom actions in a member Region when findings are managed from the aggregation Region: create them in the aggregation Region.
✓Benefits and use cases
Raise to CRITICAL every finding on resources tagged env=prod.
Suppress informational findings from a sandbox account.
A ‘Send to forensics’ button that starts the evidence workflow for findings an analyst picks.
Think of it like · a hospital emergency room
Sorting patients is different from treating them.
AWS concept
Familiar thing
Finding
≈
A patient arriving at the ER
Automation rule
≈
The triage nurse’s fixed rules: chest pain is always red, a scratch is green
Suppressed workflow
≈
‘Sent home, no treatment needed’ written on the chart
Custom action
≈
A doctor presses a button to call the surgery team for this patient
EventBridge target
≈
The surgery team that actually treats the patient
RuleOrder
≈
If two triage rules disagree, the last rule on the list wins
Real AWS example · automation rule that marks prod findings critical
Matches any finding whose resource has the tag env=prod and raises its severity, adding a note.
A second EventBridge rule can now match Severity.Label: CRITICAL in Imported findings and page the on-call team.
Exam-style scenario
A security team wants analysts to review Security Hub findings and, only for the findings they choose, start a workflow that snapshots the instance and opens a ticket. What should the team build?
A. A Security Hub automation rule that sets the workflow status to NOTIFIED.
B. A Security Hub custom action, plus an EventBridge rule matching the Findings - Custom Action event with that action’s ARN, targeting a Step Functions state machine.
C. An EventBridge rule on all Findings - Imported events.
D. An AWS Config rule.
Show the worked answer
Answer: B
Custom actions are the analyst-chosen path. The EventBridge rule matches the custom action ARN and starts the workflow.
Why not the others
A: Automation rules only edit fields; they cannot snapshot or open tickets by themselves.
C: This acts on every finding without a human choice.
D: Config evaluates configuration, it doesn’t react to analyst choices.
How the exam tests this
“Change severity of findings automatically, no code”→ Automation rule.
“Suppress findings from a test account”→ Automation rule → Workflow SUPPRESSED.
“Analyst picks findings to send to a tool”→ Custom action + EventBridge.
“Stop a control’s checks and cost”→ Disable the control.
“Two rules conflict”→ Higher RuleOrder applies last and wins.
Must remember
Automation rules: edit findings, max 100, per Region.
Systems Manager Automation and Config auto-remediation
A Lambda function is code you own and must test. Often AWS has already written the fix as a Systems Manager Automation runbook (an SSM document of type Automation). AWS provides hundreds of them, named AWS-…, AWSConfigRemediation-… and AWSSupport-…. You can also write your own in YAML or JSON.
AWS Config can attach a runbook to a rule as a remediation action. When the rule marks a resource NONCOMPLIANT, Config runs the runbook, either when a person clicks Remediate (manual) or by itself (automatic).
Concept profile
AWS Config auto-remediation
often confused with Config manual remediation
?What is it?
A remediation configuration on a Config rule that runs an SSM Automation runbook against each noncompliant resource automatically, with retries.
⚙How does it work?
Pick the runbook (TargetType: SSM_DOCUMENT) and map its parameters. One parameter can be the resource ID, which Config fills in at run time.
Give an AutomationAssumeRole: the IAM role the runbook uses to make the change. It needs exactly the permissions of the fix.
Set retries: a number of attempts within a number of seconds, for example 5 retries in 300 seconds. Retries only happen if remediation fails, and each one costs an Automation run.
Config uses its last compliance snapshot, so a resource changed in between can be remediated even if it is already compliant.
Use describe-remediation-execution-status to see which step failed and why.
Forgetting the AutomationAssumeRole or giving it too few permissions: the runbook fails.
Writing a Lambda function when an AWS-owned runbook already exists: higher effort.
Auto-remediating a rule that legitimately has exceptions: add exceptions with tags or use manual remediation.
Thinking Config remediation needs Lambda: it runs SSM Automation documents.
Expecting remediation in every account from one rule: deploy rules with remediation using conformance packs or organization rules across accounts.
✓Benefits and use cases
Close security groups that open SSH or RDP to 0.0.0.0/0.
Turn on S3 Block Public Access or default encryption when someone turns it off.
Re-enable CloudTrail log file validation.
Runbooks outside Config
You can start an SSM Automation runbook from many places: an EventBridge rule target, a Step Functions step, a Lambda function, OpsCenter (Day 1) or Incident Manager response plans. Runbooks can run across many accounts and Regions at once, run steps such as aws:executeAwsApi, aws:runCommand and aws:approve (which pauses until a named person approves), and write every step to the execution history. For commands inside an instance, such as collecting memory, use Run Command with the SSM Agent, so you never need SSH keys or open ports.
Think of it like · a building maintenance team
Inspections find problems; a manual tells the team how to fix them.
AWS concept
Familiar thing
Config rule
≈
The safety inspector checking every fire door
NONCOMPLIANT
≈
A fire door found propped open
SSM Automation runbook
≈
The printed repair procedure for that exact problem
Auto-remediation
≈
The caretaker closes the door as soon as the report comes in
AutomationAssumeRole
≈
The caretaker’s master key, which only opens what the job needs
aws:approve step
≈
‘Ask the building manager before changing the lock’
Real AWS example · auto-remediation for open SSH
Attach an AWS-owned runbook to the managed rule restricted-ssh.
RESOURCE_ID tells Config to pass the noncompliant security group’s ID into the runbook.
Exam-style scenario
Developers keep creating security groups that allow SSH from 0.0.0.0/0. The security team wants these rules removed automatically within minutes, with the least custom code, and a record of each fix. What should it do?
A. Write a Lambda function on a 1-hour schedule that scans all security groups.
B. Enable the restricted-ssh AWS Config managed rule with automatic remediation using the AWS-DisablePublicAccessForSecurityGroup runbook and a dedicated AutomationAssumeRole.
C. Use a service control policy to deny ec2:AuthorizeSecurityGroupIngress.
D. Enable GuardDuty.
Show the worked answer
Answer: B
Managed rule plus AWS-owned runbook means no custom code, and Config and SSM keep the compliance and execution history.
Why not the others
A: Custom code and up to an hour of exposure.
C: Blocks all ingress changes, including good ones; an SCP condition can’t easily inspect the CIDR in the request.
D: GuardDuty detects threats, not misconfigurations.
How the exam tests this
“Fix noncompliant resources automatically”→ Config auto-remediation with SSM Automation.
“Least custom code for a common fix”→ AWS-owned runbook.
“Runbook fails with access denied”→ Check AutomationAssumeRole permissions.
“Pause for approval inside a runbook”→ aws:approve step.
“Run commands inside instances without SSH”→ Run Command (SSM Agent).
Must remember
Config remediation runs SSM Automation, not Lambda.
Step Functions workflows and the Automated Forensic Orchestrator
A real response has many steps: decide, isolate, collect evidence, wait for a person, then clean up. Putting all of that in one Lambda function makes it long, fragile and limited to 15 minutes. AWS Step Functions runs each step as a state in a state machine, with retries, error handling, parallel branches and waits built in.
AWS also publishes a ready-made solution that does this for EC2: the Automated Forensic Orchestrator for Amazon EC2 (the exam guide calls it “Automated Forensics Orchestrator”). It is an AWS Solutions implementation you deploy with CloudFormation; it is not a service you turn on in the console.
Concept profile
Step Functions incident workflow
often confused with A single Lambda function
?What is it?
A state machine, written in Amazon States Language, that calls AWS services and Lambda functions in order, in parallel or by choice, and records every step in its execution history.
⚙How does it work?
Task states call more than 200 AWS services directly through SDK integrations, for example ec2:CreateSnapshot, so many steps need no Lambda code at all.
Choice branches on data (severity, tags). Parallel and Map run branches at the same time, for example one snapshot per volume.
Retry and Catch on each state handle errors such as API throttling.
.waitForTaskToken pauses until a human (or another system) sends the token back, which is the usual way to add an approval step.
Standard workflows can run up to 1 year and keep full history; Express workflows run up to 5 minutes for high-volume short jobs.
{ }Structure
One workflow: decide, isolate and collect in parallel, preserve, approve, then fix.
⇄Step Functions vs A single Lambda function
Step Functions
Single Lambda function
Max duration
1 year (Standard)
15 minutes
Human approval
Task token wait
Not practical
Error handling
Retry / Catch per state
Your own try/except
Audit trail
Visual execution history
Only your logs
Best for
Multi-step incident playbooks
One quick action
!Common mistakes the exam tests
Choosing Lambda for a workflow that must wait hours for approval: Lambda stops after 15 minutes.
Choosing Express for a playbook that waits for people: Express stops after 5 minutes.
Terminating the instance as the first step: you lose memory and possibly the disks. Isolate and capture first.
Thinking the Forensic Orchestrator is a managed AWS service: it is a solution you deploy and maintain.
Running analysis tools in the compromised account: the solution and best practice use a separate forensic account.
✓Benefits and use cases
An EC2 compromise playbook: isolate, snapshot, capture memory, notify.
IAM key leak: deactivate key, list recent API calls, open a ticket, wait for owner.
Fan out the same fix to many resources with a Map state.
What the Forensic Orchestrator does
The solution is triggered from Security Hub (for example a custom action on a GuardDuty finding about an EC2 instance, or automatically). Step Functions workflows in a central forensic account then isolate the instance, acquire memory through Systems Manager, take EBS snapshots of the disks, store the artifacts in S3 and run investigation tools on them, and send notifications as each stage finishes. For the exam, remember the pattern rather than the internals: Security Hub or GuardDuty finding → Step Functions → isolate + memory + disk → forensic account. An AWS Security blog post on automated disk collection uses the same pattern: snapshots are copied and re-encrypted with a forensic KMS key, shared with the security account, and processed in a VPC with no internet or NAT gateway, only VPC endpoints.
Think of it like · a fire brigade’s procedure
Many crews, one plan, everything written down.
AWS concept
Familiar thing
State machine
≈
The brigade’s written procedure for a house fire
Choice state
≈
‘If people are inside, rescue first; if not, attack the fire’
Parallel state
≈
One crew gets water, another checks the roof, another blocks the road
Retry / Catch
≈
If the first hydrant is dry, try the next one
waitForTaskToken
≈
Waiting for the chief to say ‘you may enter’
Execution history
≈
The incident log written after every action
Real AWS example · isolation step that waits for approval
Part of an Amazon States Language definition. The snapshot uses an SDK integration (no Lambda). The approval step sends a token to a Lambda function that posts to chat, then waits.
The responder’s ‘Approve’ button calls SendTaskSuccess with the token; ‘Reject’ calls SendTaskFailure.
Exam-style scenario
A company wants a repeatable response to GuardDuty EC2 findings: isolate the instance, snapshot all volumes in parallel, capture memory, copy evidence to a forensic account, and then wait up to 24 hours for an incident manager to approve terminating the instance. Which solution meets these needs with the least custom code?
A. One Lambda function triggered by EventBridge that does every step.
B. An EventBridge rule that starts a Step Functions Standard workflow using SDK integrations, a Parallel or Map state for snapshots, SSM Run Command for memory, and a waitForTaskToken approval step; or deploy the Automated Forensic Orchestrator for Amazon EC2.
C. A Step Functions Express workflow.
D. A Config auto-remediation rule.
Show the worked answer
Answer: B
Standard workflows can wait for a day; SDK integrations and the AWS solution reduce custom code.
Why not the others
A: Lambda stops after 15 minutes and can’t wait 24 hours.
C: Express workflows stop after 5 minutes.
D: Config reacts to configuration, not threat findings, and has no approval wait.
How the exam tests this
“Multi-step response with retries”→ Step Functions.
“Wait for human approval”→ .waitForTaskToken (Standard workflow).
“Snapshot each volume at the same time”→ Map / Parallel state.
“Ready-made EC2 forensics automation”→ Automated Forensic Orchestrator for Amazon EC2.
“Call AWS APIs without Lambda”→ SDK service integrations.
Must remember
Lambda max 15 min; Express 5 min; Standard 1 year.
Approval = waitForTaskToken.
Retry / Catch per state.
Forensic Orchestrator = AWS Solution, not a service.
Recovery with Amazon Application Recovery Controller
Remediation is not only about attackers. Sometimes the fastest safe response is to move traffic away from the part that is broken, for example a bad deployment in one Availability Zone, or a Region you no longer trust during an incident. The exam guide names Amazon Application Recovery Controller (ARC) for this. Its docs still live under the old Route 53 ARC address.
Know three features: zonal shift (move away from one AZ), routing control (on/off switches between Regions) and the newer Region switch (plans that orchestrate a whole multi-Region recovery).
Concept profile
ARC zonal shift
often confused with ARC routing control
?What is it?
A temporary action that moves traffic for a supported, opted-in resource (such as a load balancer) away from one Availability Zone to the healthy AZs in the same Region.
⚙How does it work?
You start it and set an expiry from 1 minute up to 3 days (72 hours). You can extend it, or cancel it at any time to send traffic back.
Zonal autoshift: you authorize AWS to start a shift when AWS telemetry shows an AZ impairment. It needs weekly practice runs, each moving traffic away for about 30 minutes.
Pre-scale first: shifts don’t wait for Auto Scaling, so the other AZs must already carry the load.
ARC doesn’t check the health of your own resources; it moves traffic away from the whole AZ.
Clients that reuse connections can keep using the old AZ for a while; watch per-AZ load balancer metrics.
{ }Structure
Zonal shift moves traffic between AZs; routing control flips traffic between Regions.
⇄Zonal shift vs ARC routing control
Zonal shift
Routing control
Scope
AZs inside one Region
Application replicas in different Regions
Setup
Opt in the resource
Cluster, control panel, Route 53 health checks
Mechanism
Load balancer stops using the AZ
DNS failover via routing control health checks
Duration
Expires (1 min to 72 h, extendable)
Stays until you flip it back
Safety
Practice runs
Safety rules (assertion and gating)
!Common mistakes the exam tests
Using zonal shift for a Region failover: it only works between AZs in one Region.
Shifting away without spare capacity: the remaining AZs get overloaded.
Calling the ARC control plane during a Regional outage: change routing control states through the cluster data plane endpoints (five Regions).
Forgetting safety rules: without them automation could turn every Region OFF.
Thinking zonal autoshift is started by you: AWS starts autoshifts and practice runs.
✓Benefits and use cases
A bad deployment in one AZ causes errors: shift away, then roll back.
Fail over a whole application to a standby Region during an incident.
Prove recovery works with practice runs, like Day 1’s FIS tests.
Region switch
Region switch lets you build a plan made of workflows, steps and execution blocks that run in sequence or in parallel, for example scaling up compute, promoting a database and redirecting traffic. Plans work across accounts, support active/passive (failover and failback) and active/active (shift away and return), can be started by hand or by CloudWatch alarms, and have a data plane in each Region so a plan can run without the Region you are leaving. Older study material may not mention it.
Think of it like · a motorway operator
Moving cars away from trouble without fixing the road first.
AWS concept
Familiar thing
Zonal shift
≈
Closing one lane after a crash; cars use the other lanes
Expiry
≈
The ‘lane closed’ sign has an end time unless renewed
Zonal autoshift
≈
The motorway authority closes the lane for you when its cameras see a problem
Practice run
≈
A planned weekly lane closure to check the other lanes cope
Routing control
≈
A big switch that sends all traffic onto a different motorway
Safety rule
≈
A lock so nobody can close both motorways at once
Real AWS example · start a zonal shift
Shift traffic for an ALB away from one AZ for two hours.
The AZ is given as an AZ ID (euw1-az2), which is the same in every account, not an AZ name like eu-west-1b.
Exam-style scenario
During an incident, a new release deployed only to instances in one Availability Zone causes errors behind an Application Load Balancer. The team needs to stop sending users to that AZ immediately while it investigates, then return traffic with one action. Capacity in the other AZs is already sufficient. What should it do?
A. Use ARC routing control to fail over to another Region.
B. Start an ARC zonal shift away from the affected AZ for the ALB, then cancel the shift after the rollback.
C. Delete the subnet in that AZ.
D. Change the Route 53 record TTL.
Show the worked answer
Answer: B
Zonal shift is fast, temporary and reversible inside one Region.
Why not the others
A: A Region failover is far bigger than needed and needs a standby Region.
C: Destructive and slow to undo; also destroys evidence.
D: TTL alone doesn’t move traffic away from an AZ.
How the exam tests this
“Move traffic away from one bad AZ”→ Zonal shift.
“AWS should shift for us during AZ problems”→ Zonal autoshift (+ weekly practice runs).
“Switch app traffic between Regions”→ Routing control.
“Prevent all switches turning off”→ Safety rules.
“Orchestrate a full multi-Region recovery”→ Region switch plan.
Must remember
Zonal shift: 1 min to 72 h, extendable.
Autoshift: AWS starts it; practice runs weekly ~30 min.
Pre-scale; shifts don’t wait for scaling.
Routing control cluster: 5 Regions, use data plane.
Skill 2.2.1 asks you to capture and store logs and system data as forensic artifacts. The first instinct, “terminate the hacked instance”, is the wrong answer on this exam. Terminating destroys the memory and, by default, the root volume. Instead you contain the instance so it can do no harm, and keep it alive while you collect evidence.
Concept profile
Forensic isolation of an EC2 instance
often confused with Stopping or terminating the instance
?What is it?
Cutting an instance off from the network and from your application, while it keeps running, so you can collect memory, disk and metadata as evidence.
⚙How does it work?
Protect: turn on termination protection (and stop protection), set the instance to keep volumes on termination, and tag it with a case ID and Quarantine.
Isolate: replace all its security groups with a forensic security group that has no rules, or only allows your forensic workstation. Detach it from its Auto Scaling group (or Auto Scaling replaces it and may terminate it) and deregister it from load balancer target groups.
Connection tracking: changing a security group does not drop existing tracked connections. Add a deny rule in a network ACL to cut them now (NACLs are stateless).
Remove or restrict the instance profile role and revoke its active sessions, because stolen credentials keep working outside the instance.
Collect in order of volatility: memory and running state first (through SSM Run Command), then EBS snapshots of every volume, then logs.
⇄Isolation vs Stopping or terminating the instance
Isolation
Stop / terminate
Memory (RAM)
Kept and can be captured
Lost
Disks
Kept; snapshot any time
Root volume deleted on terminate by default
Attacker access
Blocked by SG + NACL
Gone, but so is evidence
Malware behaviour
Can still be observed
Can’t be studied
Exam hint
“preserve evidence”, “investigate”
Only after evidence is safe
!Common mistakes the exam tests
Terminating or stopping first: memory is gone and attackers’ tools in RAM can’t be studied.
Changing only the security group and expecting the attacker’s open session to drop: tracked connections continue until they time out.
Leaving the instance in its Auto Scaling group: it may be replaced and terminated.
Logging in with SSH to look around: you change the evidence and may run attacker tools. Use SSM with read-only collection scripts.
Forgetting the instance role’s temporary credentials: revoke sessions with an inline deny on aws:TokenIssueTime (the console’s ‘Revoke active sessions’).
✓Benefits and use cases
Investigating a crypto-mining finding without losing the miner’s binary in memory.
Legal cases that need a full, hashed disk image.
Keeping a compromised host for later root cause analysis on Day 3.
What counts as an artifact
Memory: a full RAM image, collected with a tool run through SSM Run Command and written straight to S3 or to a new EBS volume, never to the suspect disk. Disk: an EBS snapshot of every attached volume; snapshots are point-in-time, incremental and stored by AWS, and you can tag them and copy them to another account. Instance metadata: instance ID, AMI, launch time, security groups, IAM role, network interfaces, tags, captured with describe-instances and saved as JSON. Logs: CloudTrail events for the instance role, VPC Flow Logs for its network interface, Route 53 Resolver query logs for its DNS lookups, plus OS and application logs. GuardDuty Malware Protection can also scan the instance’s EBS volumes and keep the snapshots when it finds malware.
Think of it like · a police crime scene
Secure first, collect carefully, never clean up early.
AWS concept
Familiar thing
Termination protection
≈
Police tape: nobody may remove the car from the scene
Forensic security group
≈
Officers at the door: nobody gets in or out
Network ACL deny
≈
Cutting the phone line so the suspect can’t keep talking to a partner
Memory capture
≈
Photographing footprints before the rain washes them away
EBS snapshot
≈
Making an exact copy of the suspect’s diary
Terminating first
≈
Towing and crushing the car before anyone looks inside
Real AWS example · isolate and preserve an instance
The commands a Lambda function or Step Functions workflow would run, in order.
# 1 protect and tag
$ aws ec2 modify-instance-attribute --instance-id i-0abc --disable-api-termination
$ aws ec2 create-tags --resources i-0abc --tags Key=case,Value=IR-4711 Key=status,Value=Quarantine
# 2 isolate: detach from ASG and swap to the empty forensic SG
$ aws autoscaling detach-instances --instance-ids i-0abc \
--auto-scaling-group-name web-asg --no-should-decrement-desired-capacity
$ aws ec2 modify-instance-attribute --instance-id i-0abc --groups sg-0forensic
# 3 metadata, then 4 snapshot every volume with tags
$ aws ec2 describe-instances --instance-ids i-0abc > IR-4711-metadata.json
$ aws ec2 create-snapshots --instance-specification InstanceId=i-0abc \
--description "IR-4711 evidence" --copy-tags-from-source volume \
--tag-specifications 'ResourceType=snapshot,Tags=[{Key=case,Value=IR-4711}]'
create-snapshots takes crash-consistent snapshots of all volumes of the instance at the same moment, without stopping it.
Run the memory capture (step 3) with aws ssm send-command before anyone reboots the instance.
Exam-style scenario
GuardDuty reports that an EC2 instance in an Auto Scaling group is communicating with a command-and-control server. The security team must stop the communication immediately, keep the instance running for memory analysis, and preserve the disks. Which combination of actions is best?
A. Terminate the instance and let Auto Scaling launch a clean one.
B. Enable termination protection, detach the instance from the Auto Scaling group, replace its security groups with an isolation security group, add a network ACL deny for the C2 address, capture memory with SSM Run Command, and snapshot all volumes.
C. Stop the instance and create an AMI.
D. Change the security group only and SSH in to check running processes.
Show the worked answer
Answer: B
This contains the instance (including existing tracked connections) and preserves memory and disks.
Why not the others
A: Destroys memory and probably the root volume.
C: Stopping loses memory.
D: Existing tracked connections survive a security group change, and SSH changes the evidence.
How the exam tests this
“Preserve evidence of a compromised instance”→ Isolate, don’t terminate.
Storing evidence: forensic account, Object Lock and chain of custody
Evidence is only useful if you can prove nobody changed it. That means keeping it away from the compromised account, in storage that cannot be deleted or overwritten, with a written record of who touched it. AWS answers have three parts: a separate forensic account, an S3 bucket with Object Lock, and hashes plus a chain of custody log.
Concept profile
S3 Object Lock (compliance mode)
often confused with Object Lock governance mode
?What is it?
A write-once-read-many (WORM) setting on S3 object versions. In compliance mode, no user, not even the root user, can overwrite or delete a protected version or shorten its retention until the date passes.
⚙How does it work?
Object Lock needs S3 Versioning. Locks apply to object versions; a simple delete only adds a delete marker, and a permanent delete of a locked version returns 403.
Retention period: a retain-until date, set per version or as a bucket default in days or years. You can extend it but never shorten it.
Governance mode: users with s3:BypassGovernanceRetention can override it with a special header. Good for testing.
Legal hold: protection with no end date, separate from retention; it stays until someone with s3:PutObjectLegalHold removes it.
In compliance mode, the only way to delete a locked object early is to close the AWS account.
{ }Structure
Evidence leaves the workload account, is locked in the forensic account, and every touch is recorded.
⇄Compliance mode vs Object Lock governance mode
Compliance mode
Governance mode
Root user can delete
No
Yes, with bypass permission
Change mode / shorten
Never
With s3:BypassGovernanceRetention
Use for
Legal evidence, regulators
Testing, internal protection
Mistake cost
Can’t undo until retention ends
Can be fixed
Exam hint
“no one, including root”
“special permission can override”
!Common mistakes the exam tests
Storing evidence in the compromised account: an attacker with admin rights can delete it.
Choosing governance mode when the question says no one, including administrators: that is compliance mode.
Forgetting versioning: Object Lock requires it.
Sharing a snapshot encrypted with the default aws/ebs key: AWS managed keys can’t be shared. Copy it with a customer managed key that the forensic account may use.
Analysing the original snapshot directly: create a new volume from a copy, attach it to a forensic workstation in an isolated VPC, and record hashes before and after.
✓Benefits and use cases
Evidence that must stand up in court.
Keeping CloudTrail and VPC Flow Log copies safe from an attacker who gains admin access.
Legal hold on everything related to one case.
Forensic account and chain of custody
Create a dedicated forensic account (often in a security OU) with very few people allowed in, strict SCPs, its own KMS keys and an analysis VPC with no internet gateway or NAT gateway, only VPC endpoints. Prepare it before an incident, as Day 1 said. The chain of custody records for each artifact: what it is and its hash (for example SHA-256), who collected it, every person or process that touched it, when (in UTC), where it is stored and why. Step Functions execution history, CloudTrail and S3 server access logs help prove who did what. Logs are artifacts too: turn on CloudTrail log file validation so digest files can prove log files weren’t changed, and keep VPC Flow Logs and Route 53 Resolver query logs in a central log archive bucket.
Think of it like · a bank’s safe-deposit vault
Valuables go to a separate, locked building with a sign-in book.
AWS concept
Familiar thing
Forensic account
≈
A separate vault building, not the shop that was robbed
Object Lock compliance
≈
A time-lock safe: not even the bank manager can open it before the date
Governance mode
≈
A safe the manager can open with a special key
Legal hold
≈
A court order: the box stays shut until the judge says otherwise
Hash
≈
A seal on the evidence bag; a broken seal shows tampering
Chain of custody
≈
The sign-in book recording every person who handled the bag
Real AWS example · evidence bucket and a locked artifact
Create the bucket with Object Lock, set a compliance default retention, upload with a hash, add a legal hold.
Creating the bucket with Object Lock turns on versioning automatically.
Test with governance mode and a short retention first: a compliance-mode mistake cannot be undone.
Exam-style scenario
A company must keep evidence from security incidents for 7 years. Regulators require that nobody, including administrators and the root user, can delete or change the evidence during that time. Evidence comes from many workload accounts. What should the security team do?
A. Store evidence in each workload account’s S3 bucket with versioning and MFA delete.
B. Store evidence in a dedicated forensic account in an S3 bucket with Object Lock in compliance mode and a 7-year default retention, with SSE-KMS and a chain-of-custody record including hashes.
C. Use S3 Object Lock governance mode in the workload accounts.
D. Store evidence in S3 Glacier Flexible Retrieval with a lifecycle rule.
Show the worked answer
Answer: B
Compliance mode blocks everyone including root; a separate account keeps evidence away from attackers in the workload accounts.
Why not the others
A: Root in the workload account can still remove MFA delete and delete data; the attacker may control that account.
C: Governance mode can be bypassed with a permission.
D: Lifecycle and storage class don’t stop deletion.
How the exam tests this
“No one, including root, may delete evidence”→ Object Lock compliance mode.
“Admins with special permission may override”→ Governance mode.
“Hold until a lawsuit ends, no fixed date”→ Legal hold.
Cheatsheet extras: when automated response doesn’t fire
The cheat sheet’s “troubleshooting scenarios” chapter keeps coming back to one question: the automation is built, so why did nothing happen? For incident response the usual suspects are three: the event never reached Lambda, Lambda ran but wasn’t allowed to act, or Run Command never reached the instance. Older material says “CloudWatch Events”; today the same service is Amazon EventBridge (same events, same rules).
Concept profile
Lambda function policy (resource-based policy)
often confused with Lambda execution role
?What is it?
A resource-based policy on the Lambda function that says who may invoke it, for example events.amazonaws.com for an EventBridge rule or s3.amazonaws.com for an S3 event notification.
⚙How does it work?
Execution role = what the function can do (stop instances, change security groups, write logs, use a KMS key).
Function policy = who can call the function (lambda:InvokeFunction).
The console adds the function policy for you when you pick Lambda as a target. CloudFormation, CDK and the CLI don’t: add AWS::Lambda::Permission / aws lambda add-permission.
Scope it with SourceArn (the rule or bucket ARN) and, for S3, SourceAccount.
Signs in CloudWatch: the rule’s MatchedEvents rises but Invocations fails (FailedInvocations), and the function shows no invocations.
{ }Structure
Three gates: can the event call Lambda, can Lambda act, can the command reach the instance.
⇄Function policy vs Execution role
Function policy
Execution role
Answers
Who may invoke the function?
What may the function do?
Type
Resource-based policy on the function
IAM role assumed by Lambda (trust: lambda.amazonaws.com)
Symptom when missing
Function never runs; rule shows FailedInvocations
Function runs; AccessDenied in its logs (or no logs at all)
Add the actions (and KMS key policy access if needed)
Exam hint
“event not invoking Lambda”
“Lambda can’t stop the instance / write logs”
!Common mistakes the exam tests
Adding lambda:InvokeFunction to the execution role to fix “EventBridge can’t invoke”: the caller needs it in the function policy.
Forgetting logs:CreateLogGroup, CreateLogStream, PutLogEvents in the execution role: the function runs but you can’t see why it failed.
Lambda can’t decrypt or use a KMS key: the key policy must allow the role too.
Run Command “Undeliverable” on private instances: no outbound HTTPS path and no VPC endpoints for ssm, ssmmessages, ec2messages.
Instance not listed as a managed node: missing instance profile or SSM Agent stopped.
✓Benefits and use cases
Quick diagnosis of a playbook that “did nothing” during a test or a real incident.
Least privilege on both sides: only the rule can call the function, and the function can only do its job.
Reliable Run Command for memory capture and isolation scripts.
Run Command not running on some instances
The cheat sheet lists three checks, and the exam likes them: the SSM Agent is running (it is preinstalled on many Amazon Linux and Windows AMIs), the instance can reach the Systems Manager endpoints (security groups and NACLs must allow outbound HTTPS 443, or you add interface VPC endpoints), and the agent logs show the error (/var/log/amazon/ssm/errors.log and amazon-ssm-agent.log on Linux, %PROGRAMDATA%\Amazon\SSM\Logs on Windows). Add a fourth from today’s docs: the instance profile needs AmazonSSMManagedInstanceCore (or Default Host Management Configuration).
Cheat-sheet example of event-driven response: a CloudTrail CreateVolume event with encrypted=false → EventBridge → Lambda that alerts through SNS or quarantines the instance. Today the simpler fix is to prevent it: turn on EBS encryption by default in every Region, and use an SCP or a Config rule (encrypted-volumes) as the guardrail and detector.
Think of it like · a building alarm company
The alarm went off, but nobody came. Was the call blocked, was the guard not allowed in, or was the radio dead?
AWS concept
Familiar thing
EventBridge rule
≈
The alarm panel that phones the guard company
Function policy
≈
The guard company’s list of numbers it accepts calls from
Execution role
≈
The keys the guard carries: which doors he can open
SSM Agent + 443 path
≈
The radio inside the building: no signal, no instructions
errors.log
≈
The radio’s own fault log
Real AWS example · let one EventBridge rule invoke the response function
This is the step CloudFormation and the CLI don’t do for you.
The SourceArn condition stops any other rule (or account) from calling the function.
Exam-style scenario
A team deploys, with CloudFormation, an EventBridge rule for high-severity GuardDuty EC2 findings that targets a Lambda function which isolates the instance. During a test, the rule’s MatchedEvents metric increases and FailedInvocations increases too. The function has no invocations and no logs. What is the most likely fix?
A. Add lambda:InvokeFunction to the function’s execution role.
B. Add an AWS::Lambda::Permission that allows events.amazonaws.com to invoke the function, with the rule ARN as SourceArn.
C. Add logs:PutLogEvents to the execution role.
D. Enable GuardDuty Runtime Monitoring.
Show the worked answer
Answer: B
The rule matches but can’t call the function: the function policy is missing. The console would have added it; CloudFormation doesn’t.
Why not the others
A: The execution role controls what the function does, not who may call it.
C: Would explain missing logs only if the function ran; it never ran.
D: Findings already arrive (MatchedEvents rises).
How the exam tests this
“EventBridge / S3 event doesn’t trigger Lambda”→ Add the function (resource-based) policy.
“Lambda runs but can’t act / no logs”→ Fix the execution role (and KMS key policy).
“Run Command doesn’t work on some instances”→ SSM Agent running, outbound 443 or endpoints, check errors.log, instance profile.
“CloudWatch Events” in an old question→ Read it as EventBridge.
Must remember
Function policy = who calls; execution role = what it does.
Check the basics first. Pick an answer, then press Check.
12
Hard quiz
Harder than most real exam questions on purpose, with one “choose two” and one matching question. Aim for 9 out of 12 before Day 3.
13
Practice test questions (from your mock exams)
7 questions taken from your own SCS-003 mock exams and matched to today’s topics. Each answer was checked against current AWS behaviour; where a mock’s answer was outdated or wrong, the explanation says so. The source is shown at the end of each explanation.
14
Hands-on lab (30 minutes, low cost)
Create an SNS topic with your email address. In EventBridge, create a rule with the pattern {"source":["aws.guardduty"],"detail-type":["GuardDuty Finding"]} and the topic as target. If GuardDuty is on (30-day free trial for new accounts), run aws guardduty create-sample-findings --detector-id DETECTOR_ID and watch the emails arrive.
Create a test security group in the default VPC with an inbound rule for TCP 22 from 0.0.0.0/0. Turn on the AWS Config managed rule restricted-ssh (Config must be recording; it charges per configuration item and rule evaluation).
Add automatic remediation to the rule with the runbook AWS-DisablePublicAccessForSecurityGroup, the GroupId parameter set to the resource ID, and an AutomationAssumeRole that may revoke ingress. Re-evaluate the rule and check in Systems Manager Automation that the runbook ran and the rule is gone.
Launch a t3.micro (Free Tier where eligible). Create an empty security group forensic-isolation. Run the commands from section 06: enable termination protection, add tags, swap to the isolation group, save describe-instances output and run create-snapshots.
Create an S3 bucket with Object Lock enabled. Upload a small file with a governance mode retention of 1 day and try to delete that version: you get 403. Do not use compliance mode in a personal account, or you cannot delete the object until retention ends.
Clean up: turn off termination protection and terminate the instance, delete the snapshots (charged per GB-month), delete the security groups, the Config rule and remediation (or stop the recorder), the EventBridge rule and SNS topic. Delete the governance-locked object with the bypass header after a day, or wait for the retention, then delete the bucket. Archive the GuardDuty sample findings.