An application in account B cannot decrypt objects that account A encrypted with a customer managed key. The role in account B already allows kms:Decrypt. The key policy in account A has no statement for that role. What should change?
Select an answer to reveal the explanation.
Short Explanation
Your badge works in your building, and the other building never put that role on the door list. The key policy has no permission for the other account's role, so decrypt is denied. An allow in the caller's account cannot authorize a key that never named that role.
Full Explanation
A customer managed key allows a principal only when the key policy says so. For a role in another account, the key policy in the key account must permit that role to decrypt, and the role identity policy must permit the call. The identity policy already allows kms:Decrypt, so the missing piece is a key-policy statement for the account B role. Automatic rotation keeps the same key and previous key material for decrypt. It does not name a new principal. A wider IAM policy in account B still cannot pass a key policy that does not allow the role. A multi-Region replica is a separate key resource with its own key policy, and the role would still need to be allowed there; the replica key id alone grants account B nothing. Caveat: the caller also needs access to the object itself, and some clients need kms:DescribeKey before they will use the key. The authorization gap in this incident is the key policy. Operational check: decrypt or GetObject with the account B role should succeed, and a role that was not added to the key policy should still be denied.