Emergency-management DR runbooks currently launch AMIs by hand. What improvement should the architect prioritize?
Select an answer to reveal the explanation.
Short Explanation
When the sirens wail, you want a scripted garage door—not a scavenger hunt for AMI IDs in email. Wire IaC, Auto Scaling, and orchestration into the DR runbook. More screenshots of manual clicks still leave humans on the critical path.
Full Explanation
Emergency-management DR runbooks that still launch AMIs by hand should prioritize automated recovery hooks—infrastructure as code templates, Auto Scaling groups, and orchestration runbooks—so failover is not limited to manual AMI launches under stress. Automation shortens RTO, reduces operator error during disasters, and makes game-day rehearsals repeatable for municipal emergency systems. Screenshots alone cannot keep pace with Regional failover timelines when every minute of citizen alerting matters.
Keeping purely manual AMI launches and only extending the runbook with more screenshots leaves recovery speed capped by human click paths. Removing all recovery automation to avoid CloudFormation drift concerns forever trades a manageable drift problem for unreliable disaster recovery. Storing AMI IDs only in email threads without executable automation guarantees tribal knowledge fails when the on-call engineer is unreachable.
Exam caveat: SAP-C02 favors automated, tested recovery (CloudFormation/CodeDeploy/ASG/Elastic DR orchestration) over runbook-only AMI clicks when RTO is serious. Operational check: encode AMI or launch-template IDs in IaC, trigger a one-button or pipeline-driven recovery in a drill, measure time to healthy service, and store the runbook next to the executable automation—not instead of it.