A bank's deploy role has an identity policy allowing the KMS actions a stack needs, but CloudFormation still fails with AccessDenied on the customer managed key. The key policy names no statement for this role and does not delegate to IAM in the account. What is missing?
Select an answer to reveal the explanation.
Short Explanation
The lock on the box has its own guest list, and this role is not on it. You allowed the call in the identity policy, but a customer managed key still refuses the call when the key policy neither names the role nor lets IAM policies in the account decide. Opening the key to everyone is the wrong kind of fix.
Full Explanation
A KMS key policy is evaluated with IAM. If the key policy does not include the principal and does not contain the statement that enables IAM policies in the account to allow access, an identity-based allow has nothing to attach to and KMS returns AccessDenied. The deploy role needs a key policy statement for the actions it actually calls, such as encrypt, decrypt, or generate data keys, scoped to this key. KMS is an API, not a VPC resource you open with a security group on the key itself. A key policy that allows every principal is an exposure, and pairing it with a later deny does not repair least privilege. A new key does not inherit an allow from an identity policy when its own key policy grants nothing. The same gap would remain. Caveat: if the key policy already enables IAM policies for the account, then the identity policy alone can allow the role, and the fix is that identity statement instead. Operational check: in the IAM policy simulator, evaluate the role against the key ARN for the failing action and confirm the explicit result is allowed before you rerun the stack.