An application running under an IAM role has an identity-based policy that allows kms:Decrypt on a customer managed key. When the role calls Decrypt on ciphertext produced by that key, AWS KMS returns an access denied error, yet CloudTrail shows the IAM policy is attached and the key is enabled. The key's policy contains only the statement that grants the account root the kms:* actions for a different key administrator team. Which change lets the role decrypt while keeping least privilege?
- AAttach a second identity-based policy to the role that allows kms:* on every key, since the first policy was too narrow to authorise the Decrypt call against the ciphertext.
- BRecreate the customer managed key with automatic rotation turned on so a fresh key version is issued that the role's existing identity-based policy is then permitted to decrypt.
- CAdd a statement to the key policy that allows the role's ARN to call kms:Decrypt, or enable IAM policies for the key by granting the account principal in the key policy. Correct
- DMove the role into the key administrator team's IAM group so it inherits the kms:* permission the key policy already grants to that team for the different key.
Why A is wrong: Tempting if you assume IAM alone authorises key use, but widening IAM cannot help when the key policy itself never grants the principal, and kms:* breaks least privilege.
Why B is wrong: Tempting because rotation sounds like a reset, but rotation changes backing key material, not access control, so the role is still blocked by the unchanged key policy.
Why C is correct: Correct because a customer managed key is governed by its key policy, which must grant access before any IAM policy can take effect for that key.
Why D is wrong: Tempting since the team has access, but the grant is scoped to a different key and joining an admin group violates least privilege rather than scoping Decrypt narrowly.