SCS-C03 · Domain 2 · Incident Response (14%) · Day 1 of 3
Plan, prepare and test incident response
Domain 1 Detection is done (last lecture: Detection Day 4), so you can now spot trouble. Domain 2 is about what happens next. Today covers the work before any attack: the incident response lifecycle, playbooks and runbooks with Systems Manager OpsCenter and Automation, investigation notebooks in SageMaker AI, ready-made access and a forensics account, security tools and Shield Advanced set up in advance, the AWS Security Incident Response service, and testing it all with tabletop exercises, AWS Fault Injection Service and Resilience Hub.
Skill 2.1.1 response plans and runbooksSkill 2.1.2 prepare services for incidentsSkill 2.1.3 test the plan~90 min read + 30 min lab
01
The incident response lifecycle and plan
Domain 1 taught you how to see trouble. Domain 2 asks what you do next. Task 2.1 is about the work before any attack: writing the plan, preparing accounts and tools, and testing that it all works. AWS bases its guidance on the NIST SP 800-61 lifecycle, and the AWS Security Incident Response User Guide splits preparation into three equal parts: people, process and technology.
The most important idea for the exam: in the cloud you cannot walk to a server room. Access, logs, tools and accounts must exist before the incident, or responders lose hours asking for permissions while the attacker keeps working.
Concept profile
Incident response plan, playbooks and runbooks
often confused with Disaster recovery plan
?What is it?
An incident response plan is the high-level document for the whole program: roles (a RACI chart), communication plan, what counts as an incident, and the phases of response. Under it sit playbooks for each kind of event and runbooks for single repeatable tasks.
⚙How does it work?
Preparation: people (roles, training, AWS support options), process (plan, architecture diagrams, playbooks, simulations) and technology (accounts, tags, contacts, access, logs, forensics).
Detection and analysis: an alert or finding arrives; confirm it is real and find the scope.
Containment, eradication and recovery: stop the damage, remove the cause, restore safely.
Post-incident activity: lessons learned, then update the plan, playbooks and controls.
AWS advises building playbooks for expected events and for known alerts such as GuardDuty finding types.
{ }Structure
Four phases in a loop. Preparation is where Task 2.1 lives.
⇄IR plan vs Disaster recovery plan
IR plan and playbooks
Disaster recovery plan
Trigger
Security event: stolen keys, malware, data leak
Outage: Region, AZ or service failure
Main goal
Contain, investigate, keep evidence
Restore service within RTO/RPO
Key worry
Attacker is still active; evidence can be lost
Data loss and downtime
Typical tools
GuardDuty, Detective, OpsCenter, Automation
AWS Backup, Elastic Disaster Recovery, ARC
Exam hint
“compromised”, “unauthorized”, “forensics”
“outage”, “failover”, “RTO”
!Common mistakes the exam tests
Writing one giant plan with no playbooks: responders need short, specific steps for each event type.
Confusing playbook (the whole response to one scenario, with decisions) and runbook (one repeatable procedure, often automated).
Only preparing technology: AWS says people, process and technology are equally important.
Never updating the plan after an incident: post-incident lessons must feed back into preparation.
Forgetting the account contact information: AWS must be able to reach your security team, so use distribution lists, not one person’s email.
✓Benefits and use cases
Faster, calmer response because everyone knows their role.
Fewer human mistakes thanks to tested step-by-step playbooks.
Evidence that auditors can check (documented, rehearsed process).
What goes into a playbook
A good playbook names the event it covers (for example “GuardDuty finding: credentials used from outside AWS”), the roles involved, the data sources to check, the decisions (for example “is this a known pentest?”), the containment steps, how to communicate, and when to escalate. Each step that is the same every time is a good candidate for an automated runbook. AWS publishes sample playbooks you can start from.
Think of it like · a school fire safety program
How a school prepares for emergencies.
AWS concept
Familiar thing
Incident response plan
≈
The school’s safety policy: who leads, who calls parents, what counts as an emergency
Playbook
≈
The fire procedure: alarm, leave by these doors, meet on the field, count the children
Runbook
≈
The exact steps to switch off the gas main
RACI chart
≈
A list on the wall: head teacher decides, caretaker acts, office informs parents
Post-incident activity
≈
The meeting after a drill to fix what went wrong
Preparation
≈
Fire doors, extinguishers and trained staff in place before any fire
Real AWS example · playbook skeleton as a simple structured file
Many teams keep playbooks in version control so changes are reviewed like code.
playbook: IAM-credential-compromise
trigger:
- GuardDuty: UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS
- GuardDuty: CredentialAccess:IAMUser/AnomalousBehavior
roles: {lead: security-oncall, approver: workload-owner, comms: security-manager}
analyse:
- CloudTrail Lake: all API calls by the access key in the last 7 days
- Detective: profile of the IAM principal
contain:
- runbook: deactivate access key (approval required)
- runbook: attach deny-all policy to the principal
escalate: "data access confirmed -> legal + AWS Security Incident Response case"
lessons: update SCPs, rotate secrets, record in post-incident report
The runbook lines point to automated steps; the rest guides human decisions.
Exam-style scenario
A company has just finished a workshop and wants to start its cloud incident response program. Its security team has only basic AWS knowledge, and nobody knows who approves isolating a production instance. What should the team do FIRST?
A. Buy a third-party SIEM.
B. Write an incident response plan with a RACI chart and communication plan, train the team on AWS security services, and build playbooks for the most likely GuardDuty findings.
C. Enable automatic termination of any instance with a GuardDuty finding.
D. Run a red team exercise.
Show the worked answer
Answer: B
AWS guidance starts with people and process: roles, training, a plan and playbooks.
Why not the others
A: A tool without roles and process does not answer who approves actions.
C: Terminating instances destroys evidence and may break production.
D: Red team is the most advanced simulation type; start with tabletop exercises.
How the exam tests this
“Who decides, who acts, who is informed”→ RACI chart in the IR plan.
“Prescriptive steps for one event type”→ Playbook.
“Exact repeatable task, often automated”→ Runbook (Systems Manager Automation).
“Phases of AWS IR guidance”→ NIST SP 800-61 lifecycle.
Systems Manager OpsCenter, Automation runbooks and Incident Manager
Skill 2.1.1 names Systems Manager OpsCenter as an example. OpsCenter turns alarms and events into OpsItems: tickets that hold the affected resources, the data you need and the runbooks you can run. Automation runbooks are the “do it the same way every time” part of your playbooks.
Concept profile
Systems Manager OpsCenter
often confused with Incident Manager
?What is it?
A central place in AWS Systems Manager to view, investigate and resolve operational work items called OpsItems, with the related AWS resources, logs and runbooks on one screen.
⚙How does it work?
OpsItems are created automatically when a CloudWatch alarm enters ALARM, when an EventBridge rule matches an event (for example a Security Hub CSPM finding), from the Security Hub CSPM integration, or manually.
Each OpsItem has a status (Open, In progress, Resolved), priority, severity, up to 100 related resource ARNs and searchable or private operational data.
Use deduplication strings so one problem creates one OpsItem, not hundreds.
From an OpsItem choose a resource and Run automation; OpsCenter keeps a 30-day record of runbooks run for that OpsItem.
{ }Structure
Events become OpsItems; OpsItems launch runbooks.
⇄OpsCenter vs Incident Manager
OpsCenter
Incident Manager
Purpose
Work items for operational and security issues
Major incidents: engage people, chat, timeline
People features
Assign and track
Contacts, on-call schedules, escalation plans
Runbooks
Run Automation from the OpsItem
Response plan starts a runbook
Post-incident
Resolve the OpsItem
Built-in post-incident analysis
Availability
Open to all
Closed to new customers since 7 Nov 2025
!Common mistakes the exam tests
Recommending Incident Manager for a new account today: it is no longer open to new customers (older practice questions may still show it as an answer).
Creating an OpsItem for every event with no deduplication: the team drowns in duplicates.
Putting secrets in searchable operational data: anyone who can view the overview can see it; use private operational data.
Treating a runbook as a document only: in Systems Manager an Automation runbook actually runs steps (API calls, scripts, approvals).
Giving the runbook’s assume role broad admin rights: give it only what its steps need.
✓Benefits and use cases
One queue for security findings and operational alarms.
Responders see the resource, its config and the fix in one place.
Consistent containment with AWS-owned runbooks.
Automation runbooks and Incident Manager
An Automation runbook is a Systems Manager document of type Automation. Its steps can call AWS APIs, run scripts, wait for approval from named principals, and branch on results. AWS provides many owned runbooks, for example AWSSupport-ContainEC2Instance, which isolates an instance for investigation. You can run runbooks by hand, from an OpsItem, from an EventBridge rule, or across many accounts and Regions.
Incident Manager manages large incidents: response plans that say who is engaged, which runbook starts and which chat channel to use; contacts, on-call schedules (rotations of up to 30 contacts) and escalation plans; and post-incident analysis. Since 7 November 2025 it is closed to new customers and gets no new features, but existing customers can keep using it. The exam may still mention it, so know what it does.
Think of it like · a hotel front desk
How a hotel handles guest problems.
AWS concept
Familiar thing
OpsItem
≈
A ticket at the front desk: room 312, broken heater, priority high
Related resources
≈
The room numbers attached to the ticket
Deduplication
≈
Ten calls about the same broken lift become one ticket
Automation runbook
≈
The maintenance checklist the technician follows step by step
Approval step
≈
The manager signs before the technician turns off power to a floor
Incident Manager
≈
The emergency phone tree for a fire: who is called first, who next
Real AWS example · create an OpsItem and run a containment runbook
A responder opens an OpsItem for a suspicious instance, then runs an AWS-owned runbook.
Check the runbook reference for the exact parameter names before use; the pattern (OpsItem, then runbook with a narrow assume role) is what matters.
Exam-style scenario
A company wants a single place where operators see security findings from Security Hub CSPM and operational alarms, see the affected resources, and run approved remediation steps with a record of what was run. It is setting up these tools for the first time in a new organization. What should it use?
A. AWS Systems Manager Incident Manager response plans.
B. Systems Manager OpsCenter with EventBridge rules creating OpsItems, and Automation runbooks run from the OpsItems.
C. An S3 bucket of exported findings.
D. AWS Config conformance packs.
Show the worked answer
Answer: B
OpsCenter aggregates OpsItems from alarms and events, shows related resources, and runs Automation runbooks with history.
Why not the others
A: Incident Manager is not open to new customers since November 2025, and it is for engaging people in major incidents.
C: No workflow, no runbooks.
D: Config checks compliance; it is not a work queue.
How the exam tests this
“Aggregate operational and security issues as work items”→ OpsCenter OpsItems.
“OpsItem from a finding automatically”→ EventBridge rule target OpsCenter (or Security Hub CSPM integration).
“Repeatable containment with approval”→ Automation runbook with approve step.
The second example in skill 2.1.1 is Amazon SageMaker AI notebooks. Not every step can be automated: an analyst often needs to ask a question, look at the answer, and ask a better question. A Jupyter notebook is a page of code cells and their results, so the investigation becomes a repeatable, documented playbook that anyone on the team can re-run.
Concept profile
SageMaker AI notebook for incident investigation
often confused with Automation runbook
?What is it?
A managed Jupyter environment (a notebook instance, or JupyterLab in SageMaker AI Studio) where responders run Python or SQL against security data: CloudTrail Lake, Athena tables over S3 logs, Security Lake, and findings APIs.
⚙How does it work?
Prepare notebooks in advance, one per common playbook: for example “trace an access key”, “list everything a role did”, “find data leaving through a VPC”.
Run the notebook in the forensics or security account, inside a private VPC with direct internet access off and storage encrypted with KMS.
The notebook’s execution role gets read-only investigation permissions (Athena, CloudTrail Lake, logs bucket) and nothing more.
Save results and the notebook itself with the case evidence, so the analysis can be checked later.
{ }Structure
Evidence in, repeatable analysis out.
⇄Notebook vs Automation runbook
Notebook
Automation runbook
Best for
Investigation: open questions, exploring data
Action: same steps every time
Human role
Analyst reads results and decides next query
Optional approval, then it runs
Output
Tables, charts, written findings
Changed resources, execution log
Example
Timeline of a stolen key’s API calls
Isolate an instance, disable a key
Exam hint
“interactive analysis”, “data science”, “Jupyter”
“automate”, “consistent remediation”
!Common mistakes the exam tests
Running investigation notebooks in the compromised production account with admin rights.
Leaving the notebook instance with direct internet access enabled and no VPC.
Writing new queries from zero during every incident: build and test notebooks in the preparation phase.
Using a notebook where the task is a simple repeated action: that belongs in an Automation runbook or Lambda.
Forgetting to stop notebook instances after use: they cost money while running.
✓Benefits and use cases
Fast, repeatable log analysis during an incident.
Teaching new responders with ready-made investigation steps.
Post-incident reports with the exact queries and results.
Think of it like · a detective’s case notebook
How a careful detective works.
AWS concept
Familiar thing
Notebook cell
≈
One question written down with its answer next to it
Re-running a notebook
≈
Following the same checklist at every crime scene
Forensics account
≈
The police lab, away from the crime scene
Read-only execution role
≈
A visitor badge that lets you look at files but not change them
Saved notebook with evidence
≈
The case file handed to the court
Real AWS example · a notebook cell that builds a timeline
Query CloudTrail Lake for every call made by a suspicious access key.
import boto3, time
ct = boto3.client("cloudtrail")
q = '''SELECT eventTime, eventSource, eventName, sourceIPAddress, awsRegion
FROM 0a1b2c3d-event-data-store-id
WHERE userIdentity.accessKeyId = 'AKIAEXAMPLEKEY123'
AND eventTime > '2026-10-01 00:00:00'
ORDER BY eventTime'''
qid = ct.start_query(QueryStatement=q)["QueryId"]
time.sleep(10)
rows = ct.get_query_results(QueryId=qid)["QueryResultRows"]
# -> eventTime | eventSource | eventName | sourceIPAddress
# 10-08 02:14 | iam | CreateUser | 203.0.113.50
# 10-08 02:15 | s3 | ListBuckets | 203.0.113.50
The same cell works for the next incident: only the key ID changes.
Exam-style scenario
A security team investigates suspicious activity several times a month. Each analyst writes Athena queries by hand, results are pasted into chat, and nobody can repeat an analysis later. The team wants an interactive, documented and repeatable way to investigate, without giving analysts access to production accounts. What should it do?
A. Give analysts administrator access to production accounts.
B. Create SageMaker AI notebooks in a dedicated security or forensics account, with prepared investigation notebooks and a read-only execution role for the log data.
C. Write a Lambda function for each possible question.
D. Export logs to analysts’ laptops.
Show the worked answer
Answer: B
Notebooks keep queries, results and notes together and re-runnable, isolated from production.
Skill 2.1.2 starts with provisioning access and minimizing the blast radius. Responders must be able to get into any account in minutes, with permissions that fit the job, and every account must already be built so one compromise cannot spread everywhere.
Concept profile
Pre-provisioned incident response access
often confused with Granting access during the incident
?What is it?
IAM roles (or IAM Identity Center permission sets) for responders, created in every account before any incident, tested regularly, and monitored. Plus an emergency break-glass path for when normal sign-in is broken.
⚙How does it work?
Create roles by job: a read-only investigation role (for example SecurityAudit plus log read) and a narrow containment role (change security groups, deactivate keys, snapshot volumes).
Deploy the roles to all accounts with CloudFormation StackSets or Identity Center, trusting only the security tooling account, with MFA conditions.
Break-glass: a small number of emergency credentials kept safe, with alarms on every use. IAM Identity Center also documents emergency access by direct IdP federation into accounts, in case Identity Center is disrupted.
Test the access on a schedule and alert when IR roles are used outside an incident.
{ }Structure
A security OU, a forensics OU per Region, and IR roles waiting in every workload account.
⇄Pre-provisioned access vs Granting access during the incident
Pre-provisioned access
Access granted during the incident
Time to start
Minutes
Hours or days of tickets
Least privilege
Designed calmly, reviewed
Often “just give them admin”
Tested
Yes, in simulations
First use is in the crisis
Audit
Known roles, alarms on use
Ad hoc users, hard to track
Exam hint
“prepare”, “reduce response time”
Almost never the answer
!Common mistakes the exam tests
Creating long-lived IAM users with access keys for responders instead of roles assumed with MFA.
Break-glass credentials with no alarm: their use should page the security team.
Running forensic analysis in the compromised account: copy evidence to the forensics account.
One giant account for everything: a single stolen admin key reaches every workload and the logs.
Letting workload admins delete the CloudTrail logs: keep logs in a separate log archive account protected by SCPs.
✓Benefits and use cases
Responders start investigating in minutes.
Every responder action is logged under a known role.
Damage from one compromised account stays in that account.
Accounts, tags and the forensics OU
AWS recommends a security OU with a security tooling account and a log archive account, and a forensics OU with a forensics account for each Region you operate in (evidence such as EBS snapshots stays in the Region). A tagging strategy lets responders find owners and data sensitivity quickly. Service control policies limit what any principal in an account can do, for example deny leaving the organization or stopping CloudTrail, so a stolen admin role is less dangerous.
Think of it like · a bank branch
How a bank prepares for a robbery.
AWS concept
Familiar thing
Pre-provisioned IR role
≈
Security staff already have keys to every branch, kept in a log book
Break-glass access
≈
The sealed emergency key behind glass; breaking it sets off an alarm
Forensics account
≈
A separate evidence room the branch staff cannot enter
Log archive account
≈
CCTV recordings kept at head office, not in the branch
Multi-account blast radius
≈
Each branch has its own vault, so robbing one does not open the others
SCPs
≈
Head office rules no branch manager can override
Real AWS example · an IR role that only the security account can assume, with MFA
Deploy this trust policy to every account with StackSets.
999988887777 is the security tooling account. A separate containment role adds only the write actions the playbooks need.
Exam-style scenario
During a recent incident, responders waited six hours for access to the affected account and then were given AdministratorAccess. The CISO wants faster, safer access across 200 accounts. What should the company do?
A. Create an IAM user with admin rights in each account and share the passwords.
B. Pre-deploy read-only investigation and narrow containment roles to all accounts with StackSets, trusting the security tooling account with MFA, alarm on their use, and test them in simulations.
C. Use the management account root user for every incident.
D. Ask AWS Support to grant access during incidents.
Show the worked answer
Answer: B
Pre-provisioned, least-privilege, tested and monitored roles are AWS’s recommended preparation.
Why not the others
A: Shared long-lived admin credentials are a risk themselves.
C: Root should be locked away, and it only covers the management account.
D: AWS Support cannot grant access to your accounts.
How the exam tests this
“Reduce time for responders to get access”→ Pre-provisioned IR roles in every account.
“Access when the IdP or Identity Center is down”→ Break-glass / emergency access, alarmed.
Skill 2.1.2 also says deploying security tools and configuring Shield Advanced protections. Logs and detectors only help if they were running when the attack happened. Most of these services were covered in Domain 1; here the exam asks you to see them as incident preparation. AWS also offers a managed service for the response itself: AWS Security Incident Response.
Concept profile
AWS Security Incident Response (service)
often confused with AWS Support / Shield Response Team
?What is it?
A paid AWS service that monitors and triages threat findings for you, gives you a case portal, and connects you to AWS’s 24/7 Security Incident Response engineers. It follows NIST SP 800-61. It does not create findings itself; it uses GuardDuty and third-party findings sent through Security Hub CSPM.
⚙How does it work?
Triage: automation, threat intelligence and people decide which threat findings are real; posture or compliance findings are not triaged.
Proactive cases are opened automatically when triage finds a genuine threat.
Reactive cases: AWS-supported (escalated to AWS engineers, 15-minute target for first engagement) or self-managed (internal tracking, can be escalated later).
With pre-authorization, engineers can run containment for compromised S3 buckets, EC2 instances and IAM principals; recovery stays your job. Containment preferences have three settings: none (the default), with approval, or automatic; you set them through a Support case, and a StackSet creates the containment roles.
You choose coverage at organization or OU level from a membership account; you must keep CloudTrail and VPC Flow Logs on.
{ }Structure
Six things to have running before day zero.
⇄Security IR service vs AWS Support / Shield Response Team
Turning on GuardDuty or Detective after an attack and expecting history: they analyse what they collect from then on.
Enabling GuardDuty in one account only: use a delegated administrator and auto-enable for new accounts, in every Region.
Expecting Shield proactive engagement without Route 53 health checks on the protected resources and Business or Enterprise Support.
Thinking the Security IR service does disk forensics or recovery: it does log-based investigation and gives recovery advice.
Not enabling the Security IR service in a Region: alerts for that Region are not available.
✓Benefits and use cases
Evidence exists when you need it.
Fewer false alarms reach your team.
Expert help on call for security events and DDoS.
Shield Advanced preparation checklist
From Domain 3 you know what Shield Advanced protects. For incident readiness, configure it before an attack: add protections to CloudFront, Route 53 hosted zones, Global Accelerator, load balancers and Elastic IPs; associate Route 53 health checks (health-based detection); turn on automatic application layer DDoS mitigation; give the SRT permission (an IAM role and, if needed, access to your WAF log buckets); and enable proactive engagement with up to ten contacts. Proactive engagement needs Business or Enterprise Support, and it is not available for events detected by the Anti-DDoS managed rule group.
Think of it like · a house before burglary season
What a careful home owner does in advance.
AWS concept
Familiar thing
CloudTrail org trail
≈
A visitor book at the door that a burglar cannot tear pages from
VPC Flow Logs
≈
Cameras on every road around the house
GuardDuty
≈
A motion alarm that knows normal family movement
Detective
≈
The recorded footage, linked by person and time, ready to replay
Shield Advanced + proactive engagement
≈
A security company that calls you when the alarm goes off
Security IR service
≈
A private detective agency on retainer, already holding a key
Real AWS example · prepare Shield Advanced for proactive engagement
Grant the SRT access, then set emergency contacts and enable proactive engagement.
Then associate a Route 53 health check with each protected resource, or the SRT has no signal to act on.
Exam-style scenario
A retailer with Shield Advanced and Enterprise Support wants AWS DDoS experts to contact its on-call team automatically when a DDoS event starts affecting its public ALB, before customers complain. What must be in place?
A. Shield Standard and a CloudWatch alarm.
B. A Shield Advanced protection on the ALB with an associated Route 53 health check, SRT access, emergency contacts and proactive engagement enabled.
C. The AWS Security Incident Response service only.
D. GuardDuty Runtime Monitoring.
Show the worked answer
Answer: B
Proactive engagement uses health check status to decide when to call your contacts.
Why not the others
A: Shield Standard has no SRT.
C: Security IR handles security incidents; DDoS contact comes from the SRT via Shield Advanced.
D: Runtime threats, not DDoS.
How the exam tests this
“Evidence must exist for future investigations”→ Turn on CloudTrail org trail, flow logs, GuardDuty now.
“Visual investigation of findings later”→ Enable Detective ahead of time.
“SRT should call us during DDoS”→ Proactive engagement + health checks.
“AWS triages findings, 24/7 IR experts, case portal”→ AWS Security Incident Response.
“AWS engineers may contain on our behalf”→ Security IR with pre-authorized containment.
Must remember
Tools must run before the incident.
GuardDuty: delegated admin, all accounts, all Regions.
Proactive engagement: health checks + Business/Enterprise, ≤10 contacts.
Security IR: proactive and reactive cases; AWS-supported = 15 min target.
Security IR contains S3, EC2, IAM if pre-authorized.
Testing the plan: simulations, FIS and Resilience Hub
Skill 2.1.3 asks how to test and validate the plan. An untested plan is a guess. AWS recommends a regular cadence of simulations, from simple tabletop talks to full red team exercises, and two services help test the technical side: AWS Fault Injection Service (FIS) and AWS Resilience Hub.
Concept profile
AWS Fault Injection Service (FIS)
often confused with AWS Resilience Hub
?What is it?
A managed chaos engineering service that runs experiments: it injects real faults into real AWS resources (stop instances, throttle APIs, add latency, disrupt networks) so you can watch how your workload, alarms and runbooks respond.
⚙How does it work?
An experiment template has actions (what to do), targets (which resources, chosen by ID, tags or filters), stop conditions and an IAM role FIS uses.
A stop condition is a CloudWatch alarm on your steady-state metric; if it fires, FIS stops the experiment, and a stopped experiment cannot be resumed.
The safety lever (one per account per Region) stops all running experiments and blocks new ones.
Multi-account experiments can target resources in other accounts.
Pay per minute an action runs; plan first and start in pre-production.
{ }Structure
People tests on the left, technical tests on the right, and Resilience Hub to measure against goals.
⇄FIS vs AWS Resilience Hub
FIS
Resilience Hub
Question it answers
What actually happens when this fails?
Can this app meet its RTO and RPO?
How
Runs real fault experiments
Assesses the app against a resiliency policy
Output
Observed behaviour, alarm and runbook results
Score, gaps, recommended alarms, SOPs, FIS tests
Link
Can be launched from Resilience Hub
Recommends and runs FIS experiments
Exam hint
“inject faults”, “chaos”, “stop condition”
“RTO/RPO”, “resiliency policy”, “drift”
!Common mistakes the exam tests
Running FIS in production with no stop condition: use a CloudWatch alarm on the steady state.
Thinking a stop condition undoes the damage: it stops the experiment; you still need recovery steps.
Giving the FIS role broad admin rights: scope it to the actions and tagged targets.
Using Resilience Hub to inject faults directly: it recommends and launches FIS experiments; FIS does the injecting.
Doing a red team exercise before the team has practised a tabletop, or without reviewing the AWS penetration testing policy.
✓Benefits and use cases
Prove that alarms fire and runbooks work.
Find weak points before an attacker or outage does.
Show auditors that the plan is tested.
Tabletop exercises, game days and Resilience Hub
The AWS Security Incident Response User Guide describes three simulation types. A tabletop exercise is discussion only: stakeholders walk through a scenario to practise roles, communication and playbooks, usually without touching tools (low complexity). A purple team exercise has attackers (red) and responders (blue) working together to test detections, tools and SOPs (medium). In a red team exercise defenders may not know the scope or timing, which is the most realistic test (high). AWS often calls hands-on practice a game day. Start simple and grow, and feed every lesson back into the plan.
Resilience Hub lets you set a resiliency policy with RTO (longest acceptable downtime) and RPO (largest acceptable data loss, measured in time) for four disruption types: application, infrastructure, AZ and Region. It assesses the app, recommends alarms, SOPs and FIS experiments, and reports drift when a change makes the app stop meeting its policy.
Think of it like · an airport emergency program
How airports make sure emergency plans work.
AWS concept
Familiar thing
Tabletop exercise
≈
Managers around a table talking through “a plane lands with a fire”
Purple team / game day
≈
A planned drill: fire crews practise with the people who set up the smoke
Red team
≈
A surprise inspector tries to sneak a fake bomb through security
FIS experiment
≈
Switching off one runway on purpose to see if traffic control copes
Stop condition
≈
The drill ends at once if a real plane is in trouble
Resilience Hub
≈
The inspector’s report: can the airport reopen within its target time?
Real AWS example · FIS experiment template with a stop condition
Stop half of the tagged web instances; stop the experiment if the error alarm fires.
Run with aws fis start-experiment --experiment-template-id EXT.... Emergency stop for everything: aws fis update-safety-lever-state --id default --state "status=engaged,reason=...".
Exam-style scenario
A company wants to prove that its automated detection and recovery work when EC2 instances in a production web tier fail. The experiment must stop automatically if customer-facing error rates go above an agreed level. What should it use?
A. A tabletop exercise.
B. An AWS FIS experiment that stops tagged instances, with a CloudWatch alarm on the error rate as the stop condition.
C. AWS Resilience Hub drift detection only.
D. Manually terminate instances in the console.
Show the worked answer
Answer: B
FIS injects real faults and stop conditions end the experiment when the alarm fires.
Why not the others
A: Discussion only; no real fault or measurement.
C: Drift shows policy compliance changes; it does not inject faults.
D: No guardrail and no repeatable template.
How the exam tests this
“Inject real failures safely”→ AWS FIS.
“Stop the experiment if metrics degrade”→ Stop condition = CloudWatch alarm.
“Stop every running experiment now”→ FIS safety lever.
“Check an app against RTO/RPO”→ Resilience Hub resiliency policy.
“Discussion-only practice of roles”→ Tabletop exercise.
Cheatsheet extras: penetration testing, simulated events and AWS abuse notices
Your cheat sheet has two “real world” topics that belong to preparation: testing your own defences with a penetration test, and what to do when AWS itself tells you something is wrong with an abuse notice. Both are easy exam points if you remember the rules, and both changed since older study material was written.
Older material (and some mock exams) says “ask AWS for approval before any penetration test”. Today you don’t need approval for the services on AWS’s permitted list. You still need approval for other simulated events (red team, phishing simulation, game days that look like attacks), and DDoS tests must follow the separate DDoS simulation testing policy.
Concept profile
AWS penetration testing policy
often confused with Simulated events / DDoS simulation testing
?What is it?
The AWS customer support policy that says what security testing you may run against your own AWS resources without asking AWS first, and what is never allowed.
⚙How does it work?
AWS publishes a list of permitted services, for example EC2 instances, NAT gateways and Elastic Load Balancers, RDS, Aurora, CloudFront, API Gateway, Lambda and Lambda@Edge, Lightsail, Elastic Beanstalk, ECS and Fargate. Check the live list before a test.
For those services you test without prior approval, only against resources in your own accounts.
Prohibited: DNS zone walking through Route 53 hosted zones, DNS hijacking or pharming through Route 53, DoS/DDoS or simulated DoS, port flooding, protocol flooding and request flooding (login or API requests).
DDoS tests: only through an approved AWS partner under the DDoS simulation testing policy.
Anything else that could look like an attack (red team exercise, phishing simulation, command-and-control testing): submit the Simulated Events form first.
{ }Structure
Green: just do it. Amber: ask AWS first. Red: don’t.
⇄Penetration test vs Simulated event / DDoS simulation
Penetration test
Simulated event / DDoS test
Approval
None, for permitted services
Simulated Events form; DDoS only via approved partner
Typical activity
Vulnerability scans, exploit attempts against your app
Red team, phishing, attack traffic floods
Target
Your own resources only
Your own resources only
Exam hint
“What must be done first before a pen test of EC2?” → confirm the service is permitted; no request
“Load-test with DDoS-like traffic” → partner under DDoS simulation policy
!Common mistakes the exam tests
Choosing “submit a request to AWS Support” for a normal pen test of EC2 or RDS: that was the old rule.
Running your own DDoS or flood test “because it’s our own app”: flooding is prohibited.
Zone walking a Route 53 hosted zone as part of reconnaissance: prohibited.
Testing an S3 bucket or another customer’s resources directly as if it were your server.
Ignoring an abuse notice because “nothing looks broken”: AWS expects a reply and action.
✓Benefits and use cases
Test your incident response plan end to end: the pen test should trigger GuardDuty and your playbooks.
Find weaknesses before an attacker does (part of the “prepare” phase).
Meet compliance needs such as PCI DSS requirement 11 (regular testing).
AWS abuse notices
The AWS Trust & Safety team sends an abuse report when your resources are reported for attacking others, hosting malware, sending spam, or when your access keys were found exposed in public. The email goes to the security alternate contact of the account, or to the account email if no security contact is set. You must reply to the report and say what you did; ignoring it can lead to your resources being blocked. Exposed keys also show up as an AWS Health event (AWS_RISK_CREDENTIALS_EXPOSED), and AWS may attach the AWSCompromisedKeyQuarantine policy to the user.
So preparation means: set the security alternate contact on every account (you can do it centrally from the Organizations management account), route AWS Health events to your team with EventBridge, and have a playbook for “AWS says our instance is attacking someone”.
Think of it like · renting a flat
You can test your own locks, but there are house rules, and the landlord will write to you if neighbours complain.
AWS concept
Familiar thing
Permitted pen test
≈
Trying to pick your own front-door lock: no need to call the landlord
Simulated Events form
≈
Telling the landlord before a fire drill so nobody calls the fire brigade
Prohibited flooding / DoS
≈
Blocking the shared stairwell to “test” evacuation: it hurts the neighbours
Abuse notice
≈
A letter from the landlord: “neighbours say loud noise comes from your flat”
Security alternate contact
≈
The phone number on file so the letter reaches the right person
Real AWS example · set the security contact for every account
Run from the management account (trusted access for AWS Account Management must be on). Abuse reports then reach the security team, not a forgotten mailbox.
Loop over aws organizations list-accounts to cover every member account.
Exam-style scenario
A security team plans next month’s exercise: (1) a vulnerability scan and exploit test against their own EC2 web servers and RDS database, and (2) a load test that sends a flood of HTTP requests to the ALB to check auto scaling under DDoS-like traffic. What must they do?
A. Request approval from AWS Support for both activities.
B. Run the EC2 and RDS test without approval; run the flood test only through an approved AWS partner under the DDoS simulation testing policy.
C. Run both without approval, because the resources are their own.
D. Enable Shield Advanced, which allows customers to run their own DDoS tests.
Show the worked answer
Answer: B
EC2 and RDS are permitted services, so no approval is needed. Request flooding and simulated DDoS are prohibited unless done by an approved partner under the DDoS simulation policy.
Why not the others
A: The old rule; approval is no longer needed for permitted services.
C: Owning the resources doesn’t make flooding allowed.
D: Shield Advanced doesn’t change the testing policy.
How the exam tests this
“What must be done before a pen test of EC2/RDS?”→ Nothing to request; check the permitted list and test only your resources.
“Simulate a DDoS against our app”→ Approved partner, DDoS simulation testing policy.
“Red team / phishing simulation”→ Simulated Events form.
“AWS abuse report says our instances attack other hosts”→ Isolate, snapshot, capture memory, investigate, then reply to the report.
“Make sure AWS security notices reach the SOC”→ Security alternate contact + AWS Health events via EventBridge.
Must remember
Permitted services: pen test without approval.
Never: DoS, flooding, Route 53 zone walking.
DDoS tests: approved partner only.
Other attack-like events: Simulated Events form.
Abuse reports go to the security alternate contact; always reply.
15. FIS stop condition = CloudWatch alarm; safety lever per Region.
16. Resilience Hub: RTO/RPO policy, SOPs, drift.
17. Pen test permitted services: no approval. DoS, flooding, zone walking: never.
18. Abuse notice → reply + act. Set the security alternate contact on every account.
10
Core quiz
Check the basics first. Pick an answer, then press Check.
11
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 2.
12
Practice test questions (from your mock exams)
6 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.
13
Hands-on lab (30 minutes, low cost)
Write a mini playbook. Pick one GuardDuty finding type (for example UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS) and write a one-page playbook: trigger, roles, data to check, containment steps, escalation. This is your first tabletop script.
Create an IR role. In a sandbox account, create a role IR-ReadOnly with the SecurityAudit managed policy and a trust policy that requires MFA. Assume it with aws sts assume-role and confirm you can read but not change resources.
Try OpsCenter. Launch one t3.micro instance tagged fis-target=web. Create an OpsItem for it with aws ssm create-ops-item, open it in the console, choose the instance and run the AWS-RestartEC2Instance Automation runbook from the OpsItem. See the run recorded on the OpsItem.
Run an FIS experiment. Create a CloudWatch alarm (for example on StatusCheckFailed for the instance) and an FIS experiment template with action aws:ec2:stop-instances, target tag fis-target=web, startInstancesAfterDuration of 5 minutes, and the alarm as the stop condition. Start it and watch the instance stop and start again.
Practise the emergency stop. Start the experiment again and engage the safety lever: aws fis update-safety-lever-state --id default --state "status=engaged,reason=lab". Check the experiment shows Stopped, then disengage the lever.
Clean up. Terminate the instance, delete the FIS template, alarm, IR role and OpsItem (set it to Resolved). Costs: FIS charges per action-minute, OpsCenter charges per OpsItem, and the instance and alarm cost a little; all should total well under one US dollar if you clean up the same day. Do not subscribe to Shield Advanced or the AWS Security Incident Response service in a personal account: both are paid subscriptions.