AWS Services
KMS Key Policies vs IAM Policies
Compare KMS key policies, IAM policies, grants, cross-account KMS access, service integrations, encrypted-data failures, and SAA-C03 exam traps.
After this, you will understand
KMS permission issues stop feeling spooky once learners understand that the key itself has a primary policy gate.
A KMS key policy controls access to a key; IAM policies can help only when the key policy allows that IAM path.
Learners add kms:Decrypt to a role and forget that the KMS key policy may not allow the account, role, service, or cross-account path.
Check data permission and key permission separately, then verify key policy, IAM policy, grants, account boundary, Region, and service integration.
Think before readingWhy can kms:Decrypt in an IAM policy still fail?
Reading in progress
This page is saved in your local study history so you can continue later.
Study path
Read these in order
Start with the mechanics, then move into the patterns that explain why the system is shaped this way.
Concepts Covered
- KMS key policies
- IAM policies for KMS
- KMS grants
- Key administrators and key users
- Cross-account key use
- AWS service integrations
- Encrypted S3 and CloudTrail access
- Regional key policy behavior
- Explicit deny
- SAA-C03 KMS traps
1. Plain-English Mental Model
KMS access has a resource-side gate that many AWS services do not have as strongly.
A KMS key policy is the primary policy for the key. IAM policies can allow a principal to use KMS only when the key policy permits that IAM-based access path.
The short model is:
key policy = who the key trusts
IAM policy = which principals get delegated key actions
grant = scoped key permission often used by services
When encrypted data access fails, do not only ask, "Can the caller read the data?" Ask, "Can the caller use the key that decrypts the data?"
2. Why This Service Exists
Encryption without key access control is incomplete.
An S3 object, EBS snapshot, RDS snapshot, CloudTrail log, SQS message, SNS topic, or Secrets Manager secret may be encrypted. But encryption only protects data if key usage is controlled separately from normal data access.
KMS key policies exist because keys are sensitive resources. The key must define who can administer it, who can use it, which services can use it, and whether IAM policies in the account can delegate access.
For SAA-C03, KMS appears in questions where a user has data access but still receives access denied, where a cross-account account needs encrypted data, where CloudTrail or S3 needs a key policy, or where administrators and users must be separated.
3. The Naive Approach And Where It Breaks
The naive approach is:
role has kms:Decrypt -> decrypt should work
That can fail if the KMS key policy does not allow the role, the account, or IAM policies to control access to the key.
Another naive approach is to make every application role a key administrator. That over-grants lifecycle power. A key administrator can change policies, disable keys, or schedule deletion. Most applications only need cryptographic operations such as encrypt, decrypt, generate data key, or describe key.
Another mistake is treating cross-account KMS like same-account IAM. In cross-account designs, the key policy in the key-owning account must allow the external account or principal, and the caller's account must allow the caller to use that key.
KMS permission failures are usually two-gate failures.
4. Core Primitives
A key policy is a resource policy attached to one KMS key. Every KMS key has exactly one key policy.
The default key policy commonly enables the account to use IAM policies to delegate access. Without that key-policy permission, IAM allow statements can have no effect for key use.
An IAM policy can grant KMS actions to a user, group, or role. It is useful for managing access to multiple keys and for actions that are not tied to one key.
A KMS grant is a policy instrument that allows a principal or service principal to use a key for specified operations. AWS services often use grants for service integrations.
Key administrators manage key policy and lifecycle. Key users perform cryptographic operations.
KMS keys are regional unless using multi-Region key features. A key policy affects the key in that Region.
5. Architecture Use Cases
Use key policies to establish who controls a customer managed key.
Use IAM policies to delegate key usage to application roles after the key policy allows that delegation model.
Use grants when AWS services need scoped permissions to use a KMS key for integrated workflows, such as encrypted storage operations.
Use separate admin and user roles:
key admin role -> manage key policy and rotation
app role -> decrypt or generate data keys only
security auditor role -> describe key and view CloudTrail logs
For cross-account encrypted S3 access, grant S3 access through bucket policy or role design and grant KMS use through key policy plus caller-side IAM permission.
For CloudTrail log encryption, ensure the key policy permits the CloudTrail service path and the expected readers.
7. Security Model
KMS security is intentionally strict.
No principal automatically has permission to use a KMS key unless a key policy, IAM policy path, or grant allows it and no explicit deny applies.
The key policy is the resource-side authority. IAM can simplify day-to-day delegation, but IAM does not bypass a key policy that refuses to trust that path.
For cross-account access:
key-owning account -> key policy allows external account or principal
caller account -> IAM policy allows caller to use that key ARN
Service integrations may require service principals, encryption context conditions, or grants. Avoid broad kms:* grants to application roles.
Use CloudTrail to audit KMS API calls and investigate unexpected key use or denied requests.
8. Reliability And Resilience
A KMS key can become a reliability dependency.
If the key is disabled, scheduled for deletion, misconfigured, or blocked by policy changes, dependent data may become unreadable.
Encrypted backups are only recoverable if the destination account or Region can use the needed key. Cross-Region snapshot copy, S3 replication, and disaster recovery plans must include key planning.
Key policy changes should be reviewed like production access changes. A bad key policy can lock out administrators or break applications.
Use aliases for operational friendliness, but be careful in cross-account scenarios where alias resolution can be ambiguous. Key ARNs are safer when account specificity matters.
9. Performance And Scaling
Most managed service integrations hide KMS usage behind the service, but high-volume workloads can create KMS request cost, throttling, or latency.
Envelope encryption reduces direct KMS calls by using data keys for actual data encryption while KMS protects the data keys.
S3 Bucket Keys can reduce KMS request volume for SSE-KMS workloads.
For custom application encryption, design caching and data-key reuse carefully. Caching key material improves performance but changes the security model.
Monitor KMS errors, throttling, and CloudTrail events for sensitive workloads.
10. Cost Model
KMS costs can include customer managed key monthly charges and API request charges.
Using SSE-KMS for high-volume S3 workloads can increase KMS request costs. S3 Bucket Keys may reduce that pressure.
Cross-account and cross-Region encrypted workflows can add storage, transfer, request, and KMS usage costs.
The cheapest key policy mistake is expensive if it prevents recovery. Cost optimization must keep data recoverability and compliance requirements intact.
12. SAA-C03 Exam Signals
"S3 access allowed but decrypt fails" points to KMS permission or key policy.
"Cross-account access to encrypted resource" points to resource access plus KMS key access.
"Separate key administrators from key users" points to key policy and IAM role design.
"CloudTrail logs encrypted with customer managed key cannot be read" points to key policy reader permissions.
"IAM policy has kms:Decrypt but access denied" points to missing key-policy trust or explicit deny.
"AWS service needs to use a key on your behalf" can point to service principal permissions or grants.
13. Common Exam Traps
Do not assume an IAM allow is enough for KMS.
Do not grant key administration to application roles that only need decrypt.
Do not forget cross-account KMS requires both the key-owning account and caller account.
Do not disable or delete keys without mapping dependent data.
Do not confuse Secrets Manager with KMS. Secrets Manager stores secret values; KMS controls encryption keys.
Do not use aliases where a cross-account key ARN is required for clear ownership.
Do not forget KMS Region behavior in replication or disaster recovery.
15. Related Topics
Review AWS Key Management Service, S3 Encryption And KMS Key Policy Traps, Identity Policies vs Resource Policies, and Secure Cross-Account CloudTrail Logging.
Official AWS references:
What to study next
These links keep the session moving: read prerequisites first, then open the systems, concepts, and patterns that deepen this page.
Prerequisites
Read these first if the mechanics feel unfamiliar.
More Links
Additional references connected to this page.