An IAM policy grants a role kms:Decrypt on an AWS KMS key, yet the call is denied. Why?

Many AWS engineers learn that IAM identity policies are enough to reach a resource. KMS is the classic exception, and it shows up in cloud interviews because it breaks that mental model.

The mechanism

AWS documents that, unlike other AWS resource policies, a KMS key policy does not automatically give permission to the account or any of its identities. The default key policy therefore contains a statement for the account principal (arn:aws:iam::<account-id>:root) with kms:*. That statement does not grant access to every principal; it allows the account to use IAM policies to delegate the permissions. AWS states that without it, IAM policies that allow access to the key are ineffective, although IAM policies that deny access still work.

Why it matters

• A role with a perfect kms:Decrypt IAM allow still fails if the key policy lacks that enabling statement or has been rewritten.
• A key policy naming a single user risks leaving the key unmanageable if that user is deleted; the account-principal statement reduces that risk.
• Debugging order: check the key policy, then IAM policies, then explicit denies.

Why the distractors fail

A trust policy controls who can assume a role, not what the role can do on a key. KMS does honor IAM policies once enabled. Denies override allows, but nothing here suggests a deny.

What interviewers want

Recognising that KMS evaluates the key policy first and that IAM only works when the key policy delegates to it.