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 →