An IAM role in Account A has an identity-based policy that allows kms:Decrypt on a specific customer managed KMS key that lives in Account B, naming the correct key ARN. The role attempts to decrypt data with that key and is denied. What is the most likely missing piece?
- Identity-based policies are ignored entirely whenever the target KMS key belongs to a different account
- The role's identity-based policy must instead be rewritten as a service control policy
- KMS keys do not support cross-account access under any configuration
- The KMS key's own key policy in Account B must also explicitly allow the Account A role to use the key; for KMS, both the identity-based policy and the key policy must authorize the action
Why D? And why not the others?
Correct answer: D. The KMS key's own key policy in Account B must also explicitly allow the Account A role to use the key; for KMS, both the identity-based policy and the key policy must authorize the action
AWS KMS requires authorization from both the identity-based policy on the calling principal and the resource-based key policy attached to the KMS key itself, even within a single account, because the default key policy is what delegates authority to IAM in the first place; for cross-account use, the key policy in the key's own account must explicitly name and allow the external principal, or the request is denied regardless of what the caller's own identity-based policy says. The option claiming identity-based policies are simply ignored is wrong because they are still required and still evaluated; the issue is that they are insufficient alone for KMS, not irrelevant. The option suggesting the fix is to rewrite the identity-based policy as a service control policy is wrong because SCPs are guardrails that can only restrict, never grant, permissions, so converting a grant into an SCP would not create the missing authorization at all. The option claiming KMS keys never support cross-account access is wrong because that is precisely what a correctly configured key policy, naming an external account's principal, is designed to enable.
Source: AWS KMS documentation: Key policies in AWS KMS — authorizing cross-account use of a KMS key