Account A owns a KMS CMK that encrypts objects in a shared evidence bucket. Account B’s application role must decrypt those objects. What must be configured?
Select an answer to reveal the explanation.
Short Explanation
Cross-account decrypt needs the key policy to invite Account B’s role—plus that role’s IAM allowing Decrypt. You do not hand-copy key bytes or blast AdministratorAccess. Public buckets skip the security model entirely.
Full Explanation
When Account A’s CMK encrypts objects in a shared evidence bucket and Account B’s application must decrypt them, update the CMK key policy so Account B’s role is allowed kms:Decrypt (and related grants as needed), and ensure Account B’s IAM identity policy also permits those KMS actions. Cross-account ciphertext access fails closed until both key policy and caller IAM align. S3 permissions alone are insufficient when objects are SSE-KMS encrypted under Account A’s key.
Deleting the CMK in Account A and trying to recreate “identical key material by hand” in Account B is not how KMS CMKs work and destroys decryptability of existing ciphertext. Granting Account B AdministratorAccess in Account A without key-policy changes is over-privilege and still may not grant decrypt if the key policy does not allow the principal. Making the S3 bucket public does not bypass KMS authorization for SSE-KMS objects and creates a severe exposure.
Exam caveat: for SSE-KMS, S3 GetObject plus kms:Decrypt on the encrypting key are both required; missing KMS permission often surfaces as an AccessDenied that looks like an S3 problem. Operational check: from Account B’s role, GetObject and decrypt a test evidence object successfully; remove the key-policy allow and confirm failure; restore and document the dual-account permission model.