Exams / SCS-C03 / Study guide / Testing incident response (Fault Injection Service, Resilience Hub, game days)
Testing incident response (Fault Injection Service, Resilience Hub, game days): SCS-C03 study notes and practice questions
What to know about Testing incident response (Fault Injection Service, Resilience Hub, game days) for the SCS-C03 exam, from the Incident Response domain (14% of the exam guide), then 2 free questions to test it. Part of the SCS-C03 study guide.
These questions ask how a team can prove its response works before it needs it. You match the test to what must be proven: that people know the procedure, that alerts and automation fire, or that the workload recovers when a component fails. Each method has a different scope, and the exam rewards the one that limits risk.
The three methods
A tabletop exercise walks the team through a scenario on paper or in a meeting. It tests decisions, roles and communication, and it finds gaps in the plan. It touches no resources.
GuardDuty sample findings generate example findings in an account. They show whether alerts, EventBridge rules, tickets and automation react. They do not reproduce real attacker behavior.
AWS Fault Injection Service (FIS) runs controlled experiments against real resources. Actions include stopping or terminating instances, failing over an Aurora or RDS cluster, throttling API calls and disrupting EC2 network traffic through the Systems Manager agent.
How FIS limits risk
An experiment template names targets by resource ARN, tags or filters, so it affects only the intended resources.
Stop conditions are CloudWatch alarms. If one goes into alarm during the experiment, FIS stops the experiment and rolls back where it can.
The experiment runs under an IAM role that you scope to the actions and resources it needs.
A game day combines these: a scripted scenario, a short FIS experiment and sample findings, with the team responding as it would for a real event.
How to choose
Scenario wording
Pick
Find out whether the team knows who decides and who calls whom
Tabletop exercise
Confirm alerts and automation fire for a sample threat in a test account
GuardDuty sample findings
Prove a workload survives instance loss, with a halt switch
FIS experiment with a stop condition
Limit an experiment to instances that carry a test tag
FIS targets selected by tags
Check whether recovery meets RTO and RPO targets
Resilience Hub assessment, then an FIS experiment
Test an attacker technique end to end
Controlled test with written approval and scope, not sample findings
Common traps
Calling sample findings a real attack test. They generate findings only.
Running FIS without stop conditions in a production account.
Targeting every instance in an account because no tag or filter was set.
Using Resilience Hub to test runbooks. It assesses the design of a workload against recovery targets; it does not exercise your response.
Skipping the tabletop and going straight to live experiments, which tests the systems but not the people.
A SaaS startup wants evidence that its incident response works before a real failure happens. When a web server instance stops responding, an Amazon EventBridge rule starts an AWS Systems Manager Automation runbook that replaces the instance and pages the on-call engineer.
The test must run monthly in a staging account that mirrors production. It must stop automatically if the customer-facing error rate in staging rises above a set threshold, and it must produce a repeatable record that the team can review.
Which approach should the security team use to validate the runbook?
Choose one answer.
AA. Stop the tagged instance by hand in the staging console during a weekday meeting, then check whether the runbook and the pager fired, and note the result in the meeting minutes.
BB. Run the experiment against the production web tier during a low-traffic window, since production is the only place where the real instances exist and the load is realistic.
CC. Send a test event that matches the EventBridge rule each month, and treat the runbook start and the page as proof, without stopping any instance or watching the error rate.
DD. Create an AWS FIS experiment template in staging that stops tagged web instances, with a CloudWatch alarm on the error rate as the stop condition, and run it monthly.
Show the answer and explanation
Answer: D
A. Wrong: A manual stop is not repeatable, and nothing halts the test if the error rate rises. A meeting-time test also leaves no defined record for the team to review later.
B. Wrong: Production is not the staging account the requirement names, and the plan has no safe stop condition. A failed test could cause the customer impact that the stop condition exists to prevent.
C. Wrong: A test event proves that the rule starts the runbook, but no instance actually fails, so the replacement is never exercised under real conditions. There is also no stop condition tied to the customer-facing error rate.
Fault Injection Service runs a controlled, repeatable experiment against tagged resources in staging. A stop condition based on a CloudWatch alarm halts the test if customers are affected, and each run gives a record for review. Manual tests, production runs and synthetic events each miss a stated requirement.
A bank has built an automated runbook that isolates a compromised EC2 instance by swapping its security group. Before the runbook is used in production, the security team must show that it works with the same code, the same IAM role and the same tagging rules that production will use.
The test must not affect any production instance, and it must produce evidence that the team can keep for audit. The test must also be repeatable each time the runbook changes.
Which approach should the security team use to test the runbook?
Choose one answer.
AA. Deploy the same runbook, IAM role and tagging rules with infrastructure as code into a dedicated test account, run it against tagged test instances, and keep the execution records.
BB. Run the runbook against production instances during a maintenance window, using a canary tag that limits it to a few servers, so that the team sees real behavior on live systems.
CC. Unit test the runbook code with mocked AWS responses on a developer laptop, and skip any test that runs in an AWS account, since the mocks cover every case the runbook can meet.
DD. Isolate one instance by hand in production during a quiet hour, and write up the result, since a manual check on a live instance shows whether the runbook is correct in practice.
Show the answer and explanation
Answer: A
A. Right: Correct. The same code and role in a separate account proves the runbook and its permissions without touching production. Infrastructure as code makes each test repeatable, and the execution history and CloudTrail records serve as the audit evidence. Learn more: Systems Manager Automation (opens in a new tab)
B. Wrong: A canary tag still touches production instances, which the requirement forbids. A mistake in the runbook or its role would reach live services during the window.
C. Wrong: Mocks do not show whether the real IAM role has the permissions that the runbook needs. The audit requirement also needs real execution records from AWS, which a laptop test cannot produce.
D. Wrong: A manual isolation does not run the runbook, so the team learns nothing about its code or role. It also touches production, and the result cannot be repeated the same way.
Explanation
Testing in a separate account with the same code, role and tags checks the runbook and its permissions without risk to production. Infrastructure as code makes the test repeatable, and the AWS execution records serve as audit evidence. Production runs, mocked tests and manual isolation each break a stated requirement.
Want more on Testing incident response (Fault Injection Service, Resilience Hub, game days)? The 5 full-length practice sets have 7 more Testing incident response (Fault Injection Service, Resilience Hub, game days) questions, 325 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets →
Study Testing incident response (Fault Injection Service, Resilience Hub, game days)