Start with what each authorization instrument controls
SAA-C03 answer rule
Who controls the key? Key policy. What can this role request? IAM policy. How can a service receive constrained, revocable cryptographic access? Grant.
Key policy: the KMS key’s primary access control
A key policy is a resource-based policy for one KMS key. Unlike many AWS resource policies, a KMS key policy does not automatically give the owning account or key creator permission. The policy must explicitly establish administration and usage paths. A careless replacement can make a customer managed key difficult to manage.
The commonly used account-principal statement enables the account to delegate permissions through IAM policies. Without that permission in the key policy, an IAM Allow for the key is ineffective. This is why “the role has kms:Decrypt” is not enough evidence that decryption will succeed.
- Separate key administrators from key users.
- Scope cryptographic use to required principals and services.
- Protect powerful actions such as
kms:PutKeyPolicy, scheduling deletion and creating grants. - Remember that a key-policy
Resourcevalue of*means the KMS key to which the policy is attached.
IAM policy: constrain the caller and the exact key
An identity-based IAM policy can allow a role to call operations such as kms:Decrypt, kms:Encrypt or kms:GenerateDataKey. For cryptographic access, identify a KMS key by its key ARN in the policy resource. Do not confuse a key ID, alias name or alias ARN with the required key ARN.
Apply least privilege to the operation, KMS key, Region and request context. Conditions such as kms:ViaService can restrict use through an integrated AWS service. Encryption-context conditions can bind cryptographic permission to the expected workload context.
An applicable explicit deny wins. Review identity policies, key policy, permissions boundaries, service control policies and VPC endpoint policies rather than searching only for an allow.
KMS grants: narrow, revocable permissions for a grantee
A grant allows one principal or service principal to perform supported operations on one KMS key. Grants can allow but cannot deny. AWS services that integrate with KMS commonly create grants while provisioning encrypted resources, use them for the required operations and retire them when no longer needed.
Grant constraints can restrict the encryption context. Because grant changes are eventually consistent, a newly created grant may take time to become usable; a grant token can make the new permission available immediately for a request. Treat kms:CreateGrant as sensitive because it can delegate key usage.
Worked scenario: an encrypted EBS volume fails to attach
Situation: An Auto Scaling launch creates an EC2 instance, but attaching a volume encrypted with a customer managed KMS key fails. The EC2 role has an IAM statement allowing kms:Decrypt.
The key policy does not authorize the path
The key belongs to a security account and its policy neither trusts the workload account nor establishes the required cross-account permission. The local IAM allow cannot create permission by itself.
Authorize both sides and constrain service use
Update the key policy to allow the required external account or role, grant the workload role the necessary IAM operations on the exact key ARN, and let the integrated service create or use an appropriate grant. Restrict conditions to the expected service and context.
Then inspect CloudTrail events and the service error rather than broadening to kms:*. Confirm the key is enabled, in the correct Region and referenced by the encrypted resource.
Cross-account KMS access usually needs permission in two accounts
For a principal in Account B to use a customer managed key in Account A, the key policy in Account A must allow the external principal or its account to use the key. An IAM policy in Account B must also allow that principal to call the required KMS operations on the key ARN. AWS managed keys cannot be shared across accounts in this way; design with a customer managed key when cross-account control is required.
Two-sided authorization
Key-owning account: key policy establishes external permission. Caller account: IAM policy delegates the permitted action to the caller. Both must align, and no applicable explicit deny can block the request.
Systematic KMS AccessDenied troubleshooting
- Identify the caller: capture the actual role session or service principal, not the expected role name.
- Identify the key: confirm key ARN, account, Region, key state and whether the resource uses a different key.
- Check the operation: distinguish
Decrypt,Encrypt,GenerateDataKey,ReEncryptand grant operations. - Read the key policy: verify direct permission or account delegation to IAM.
- Read identity controls: check IAM allow, permissions boundary, session policy and organization SCP.
- Evaluate conditions: compare service, encryption context, alias, account and source conditions with the request.
- Inspect grants: confirm the grantee, operations, constraints and propagation; use a grant token when immediate new-grant use is required.
- Inspect the path: include a KMS VPC endpoint policy and integrated-service requirements where applicable.
- Use evidence: correlate CloudTrail events and service logs with synchronized timestamps.
Practice checks with explanations
A role has an IAM allow for kms:Decrypt, but the key policy neither names it nor enables the owning account to delegate through IAM. Will IAM alone grant access?
No. The key policy must establish the relevant permission path; the IAM allow alone is ineffective.
An AWS service needs temporary, constrained use of one KMS key without repeatedly changing policies. What fits?
A KMS grant. It can allow supported operations to one grantee and can later be retired or revoked.
A workload in another account must decrypt with a customer managed key. What must align?
The key policy in the owning account and IAM permission in the caller account, plus conditions and absence of explicit denial.
Common SAA-C03 mistakes
- Assuming the key creator automatically retains permission.
- Checking IAM but ignoring the KMS key policy.
- Using an alias ARN where a key ARN is required in an IAM resource.
- Granting broad
kms:*instead of identifying the failed operation. - Forgetting Region, key state, encryption context or service conditions.
- Treating a grant as a deny mechanism.
- Missing the second permission side in cross-account access.
- Granting unrestricted
kms:CreateGrant.
Frequently asked questions
Does every AWS KMS key need a key policy?
Yes. Every KMS key has exactly one key policy, and that resource policy is the primary access-control mechanism for the key.
Can an IAM policy alone grant access to a KMS key?
Not always. The KMS key policy must explicitly grant the principal access or enable the owning account to delegate access through IAM policies. An IAM allow is ineffective when the key policy does not permit that delegation, although an applicable explicit deny still matters.
When should an AWS KMS grant be used?
Grants are useful for scoped, revocable permissions to perform supported cryptographic operations on one KMS key. AWS services commonly create grants for temporary access while encrypting resources.
Can an AWS KMS grant deny an operation?
No. A grant can allow supported operations but cannot create a deny. Denies come from applicable policies and controls.
Why does KMS Decrypt return AccessDenied when IAM allows it?
Check the key policy, exact key ARN, principal, Region, encryption context, conditions, grants, service path and every applicable explicit deny. IAM permission is only one part of KMS authorization.
Official AWS references
Review the AWS KMS Developer Guide for key policies, IAM policies with KMS, KMS grants and grant best practices. Confirm current exam scope in the official AWS certification guide.