A small startup created a customer managed KMS key in its production account and wrote a key policy that lists only the security team role as a key administrator and key user. A developer role has an IAM policy that allows kms:Decrypt on that key, but the developer's application gets an AccessDenied error.
The developer role must be able to decrypt with that key, and the startup wants access to be managed through IAM policies rather than by editing the key policy for each person.
Which change should the security engineer make?
Choose one answer.
AA. Add a statement to the key policy that grants kms:Decrypt to the developer role by its ARN. The IAM policy alone is not enough, so the key policy must name the role directly.
BB. Change the key policy principal to an asterisk, so that every role with an IAM policy can decrypt with the key. This is the simplest way to clear the AccessDenied error for every application at once.
CC. Turn on automatic key rotation for the key, which refreshes the key policy and applies the developer's IAM policy the next time the key rotates.
DD. Add a statement to the key policy that allows the account root principal to perform KMS actions on the key. IAM policies in the account can then grant the developer role access to the key.
Show the answer and explanation
Answer: D
A. Wrong: This fixes the error for one role, but every new person would need a key policy edit. The startup wants IAM policies to manage access, so this option misses the second requirement.
B. Wrong: A wildcard principal lets any AWS principal use the key, which the startup should never allow. Access control on the key would be lost, so this creates serious exposure to fix a simple error.
C. Wrong: Rotation creates new key material for the same key and does not change the key policy or how IAM policies are evaluated. The AccessDenied error would continue until the key policy allows the account.
D. Right: Correct. A key policy that trusts the account root lets IAM policies in that account grant key permissions. The developer's existing kms:Decrypt policy then takes effect, with no key policy edit for each person. Learn more: Default key policy (opens in a new tab)
Explanation
A key policy must allow the account before IAM policies in that account can grant access to a KMS key, and the usual way is a statement that trusts the account root. Adding that delegation lets the developer's existing IAM policy take effect. Wildcard principals and rotation do not fix the cause, and per-person key policy edits conflict with the IAM-managed requirement.
Want more on KMS key policies, grants, multi-Region keys and Private CA? The 5 full-length practice sets have 5 more KMS key policies, grants, multi-Region keys and Private CA questions, 325 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets →