A county DR runbook restores encrypted Amazon RDS snapshots into a second Region. What must the architect validate so recovery actually succeeds?
Select an answer to reveal the explanation.
Short Explanation
An encrypted snapshot is a locked suitcase—you need the matching key in the DR Region to open it. Multi-Region KMS keys or a planned key copy keep restore from stalling. Deleting the primary first or opening every SG does not unlock crypto.
Full Explanation
A county DR runbook that restores encrypted Amazon RDS snapshots into a second Region succeeds only if the encryption keys protecting those snapshots are available and usable in the DR Region. Customer managed keys are Region-scoped unless you deliberately use multi-Region KMS keys or copy/re-encrypt with a key that exists in the destination Region. Validating key presence—and that the restoring role can call Decrypt—prevents the classic drill failure where the snapshot exists in DR storage but restore fails on cryptography.
Disabling CloudTrail in the DR Region during restore is unnecessary and harmful to auditability. Permanently deleting the primary Region before any restore starts is reckless and unrelated to unlocking encrypted snapshots; DR should prove restore while primary still exists. Opening all security groups to 0.0.0.0/0 before restore does not address KMS and introduces a network exposure that security teams will reject.
Exam caveat: cross-Region encrypted snapshot restore hinges on KMS key strategy (multi-Region key or re-encrypt/copy), not merely snapshot copy permissions. Operational check: in a scheduled DR exercise, copy/restore an encrypted snapshot into the DR Region using the documented key, confirm the restored instance is encrypted with the expected key ARN, and record IAM/KMS permissions required for the restore role.