A city IT team shares an encrypted AMI from the production account to a disaster-recovery account so operators can launch recovery instances. The AMI copy uses a customer managed KMS key. What must the architect grant so the DR account can launch instances from that shared AMI?
Select an answer to reveal the explanation.
Short Explanation
Sharing the AMI photo is not enough if the KMS lock still only trusts production. The DR account needs key permission to unwrap the volume when it boots. Bucket policies and “make it public” do not replace that key grant.
Full Explanation
When a city IT team shares an encrypted AMI from production into a disaster-recovery account, the shared AMI is only half of the story. The EBS snapshots behind that AMI remain ciphertext protected by a customer managed KMS key. Launching an instance in the DR account requires the EBS service principal in that account to decrypt the snapshot material, which means the destination account (or a role it assumes) must be authorized in the KMS key policy and, when needed, through KMS grants. Without that cryptographic permission, AMI share succeeds administratively while instance launch fails at decrypt time—exactly the failure mode municipal DR drills expose when teams only tick the AMI-share checkbox.
An S3 bucket policy alone on an AMI store path does not replace KMS authorization. AMI/snapshot encryption is enforced by KMS, not by a generic object ACL narrative, so treating bucket policy as sufficient leaves the DR account unable to unwrap volumes. Making the AMI public so any account can decrypt without key-policy updates is both insecure and conceptually wrong for customer managed keys: publicity of the AMI catalog entry does not grant Decrypt on a CMK, and public sharing of municipal golden images is an anti-pattern for regulated civic workloads. Disabling encryption before sharing, then hoping to re-encrypt after launch in DR, discards the control that justified encryption in the first place and creates an unprotected window plus operational rework that auditors will reject.
Exam caveat: distinguish AMI/snapshot share permissions from KMS key policy. Cross-account encrypted AMI use almost always fails exam distractors that mention only resource sharing. Operational check: from a DR-account role, dry-run launch from the shared AMI, confirm CloudTrail KMS Decrypt/GenerateDataKey events succeed, and document the key policy principals for both production and DR accounts in the runbook.