AWS KMS Encryption Keys, Rotation, Policies, and Data Keys – SAP-C02 Study Guide | AWS Systems Architect Professional

Study guide

Technical reference and lesson notes

Purpose of This Lesson

AWS Key Management Service (AWS KMS) provides centralized creation and control of cryptographic keys used to protect data across AWS services and applications. For the SAP-C02 exam, focus on selecting the correct key type, understanding envelope encryption, distinguishing key-management permissions from cryptographic permissions, and recognizing rotation and key-store limitations.

Key Concepts

KMS keys and key material

A KMS key contains or references the cryptographic key material used to encrypt and decrypt data. Older AWS documentation and exam questions may refer to KMS keys as customer master keys (CMKs).

By default, AWS KMS generates the key material. You can also import key material when you need control over its origin or lifecycle. KMS keys are protected by hardware security modules (HSMs).

KMS supports symmetric and asymmetric KMS keys. Automatic rotation rules differ by key type and by how the key material was created.

KMS key categories

Key category	Who creates and manages it?	Customer control	Typical use
Customer managed key	Customer	Full control over policies, permissions, aliases, and eligible rotation settings	Application-controlled encryption, cross-account access, detailed governance
AWS managed key	AWS, for an AWS service in the customer account	Can be viewed and used through the integrated service, but cannot be directly managed, rotated, or have its key policy changed by the customer	Service-integrated encryption such as Amazon EBS, Amazon SQS, Amazon FSx, or AWS Certificate Manager
AWS owned key	AWS	Not visible or manageable by the customer	Encryption implemented by AWS across its services and infrastructure

An AWS managed key is not the same as an AWS owned key. AWS managed keys exist in the customer account and are associated with a particular integrated service; AWS owned keys are outside the customer’s direct visibility and control.

Direct encryption versus envelope encryption

A KMS key can directly encrypt or decrypt only small payloads—up to 4 KB. It is not intended to encrypt large files, database contents, or high-volume application data directly.

For larger data sets, use envelope encryption:

Generate a data encryption key (DEK) using AWS KMS.
Use the plaintext DEK in application code or an AWS-integrated service to encrypt the data locally.
Ask KMS to encrypt the DEK with a KMS key, producing an encrypted, or wrapped, DEK.
Store the encrypted data together with the encrypted DEK.
When decrypting, use KMS to unwrap the DEK, then use the plaintext DEK to decrypt the data.

AWS KMS does not store, track, or perform bulk encryption operations with plaintext data encryption keys. The application or integrated AWS service must handle DEK usage and lifecycle securely.

External and custom key stores

AWS KMS can use key material that is maintained outside the standard KMS key store:

External key store (XKS): Key material is generated and stored in an external key manager outside AWS. The material does not leave the external HSM or key manager. This can support regulatory or organizational requirements for externally controlled key material, but introduces external dependencies and operational complexity.
Custom key store: KMS keys are backed by an AWS CloudHSM cluster that the customer owns and manages. Cryptographic operations occur in that CloudHSM cluster. Custom key stores do not support asymmetric KMS keys.

These options are appropriate only when the control or regulatory requirement justifies the added operational burden. They are not general-purpose replacements for the standard KMS key store.

Key rotation

For a customer managed symmetric KMS key with key material generated by AWS KMS, automatic rotation is optional and occurs every 365 days when enabled.

Rotation changes the cryptographic key material, but the logical KMS key remains the same. The key ID, ARN, policies, permissions, and aliases do not change. Applications can continue referring to the same key.

Automatic rotation is not available for several key configurations, including:

Asymmetric KMS keys
HMAC KMS keys
KMS keys backed by a custom key store
KMS keys with imported key material

These keys require manual rotation. Manual rotation means creating a new KMS key with a new key ID and moving users or applications to it. An alias can reduce application changes: point the alias to the replacement key while application code continues to use the alias.

AWS managed keys use AWS-controlled rotation behavior and cannot be configured by the customer. AWS owned keys cannot be viewed or managed, and customers cannot enable or disable their rotation.

Key policies, IAM policies, and grants

A KMS key policy is the primary resource-based policy controlling access to a KMS key. It can grant:

Administrative permissions, such as describing the key, managing aliases, and updating key policy settings.
Cryptographic permissions, such as Encrypt, Decrypt, and ReEncrypt.
Permissions for AWS services or principals in other accounts, when the policy and identity permissions are configured appropriately.

Separate administrative and usage statements to enforce least privilege. A key administrator does not automatically need permission to use the key for encryption or decryption, and a workload that encrypts data does not need permission to administer the key.

Grants provide delegated permissions for KMS operations without changing the key policy or an IAM policy. They are useful for temporary or service-managed access. Common grant operations include CreateGrant, ListGrants, and RevokeGrant.

The kms:ViaService condition key can restrict use of a KMS key to requests made through specific AWS services—for example, allowing a key to be used through Amazon EC2 or Amazon RDS while limiting direct use by other request paths.

Cross-account encrypted resources

Cross-account access to an encrypted resource requires more than sharing the resource itself. The relevant KMS key policy must allow the external account or principal to use the key, and the caller generally also needs an appropriate IAM policy.

For operations such as sharing an encrypted EBS snapshot with another account, the receiving workflow needs the necessary KMS permissions, including the ability to decrypt the snapshot’s data key and create the required grant. The exact permissions depend on the service and operation, so evaluate both the resource-sharing policy and the KMS authorization path.

Imported key material and cryptographic erasure

When customer-provided key material is imported into KMS, deleting that material removes the ability to decrypt data protected solely by that material. This is known as cryptographic erasure.

Deleting imported key material is irreversible for that key material. Use it only when permanent data inaccessibility is intended or the material is known to be compromised and an appropriate recovery strategy exists.

Exam-Relevant Takeaways

A KMS key directly encrypts a maximum of 4 KB; use envelope encryption and DEKs for larger data.
Customer managed keys provide the greatest control over policies, aliases, usage, and eligible rotation settings.
AWS managed keys are service-specific and cannot be directly managed or manually rotated by the customer.
AWS owned keys are not visible or controllable in the customer account.
Automatic rotation applies only to eligible symmetric keys with AWS KMS-generated key material.
Automatic rotation preserves the KMS key ID and ARN; manual rotation creates a new key ID.
Aliases can abstract key replacement during manual rotation.
Key policies control access to KMS keys and should separate administration from cryptographic use.
Grants are useful for temporary or delegated permissions without modifying policies.
kms:ViaService restricts key usage to selected integrated AWS services.
Imported key material, custom key stores, asymmetric keys, and HMAC keys have important rotation limitations.
Deleting imported key material can permanently prevent decryption and is a cryptographic-erasure mechanism.

Architecture Decision Guide

Requirement	Recommended approach	Important consideration
Encrypt an S3 object, EBS volume, queue, or other AWS-managed resource with minimal administration	Use the service’s AWS managed key or an AWS owned key, depending on the service’s options	You give up customer control when using AWS managed or AWS owned keys
Need customer-controlled key policy, auditability, or cross-account key access	Use a customer managed KMS key	Configure both key policy and IAM permissions
Encrypt files or application payloads larger than 4 KB	Use envelope encryption with a DEK protected by KMS	Protect and manage DEKs in application or service logic
Replace key material without changing the KMS key reference	Enable automatic rotation on an eligible customer managed key	The logical key identity remains unchanged
Rotate an asymmetric, HMAC, imported-material, or custom-key-store key	Create a replacement key and rotate manually	Use an alias to minimize application changes
Keep key material in an external key manager	Use an external key store	External availability and key-manager operations become dependencies
Use dedicated HSM infrastructure managed by the customer	Use a KMS custom key store backed by CloudHSM	Not available for asymmetric KMS keys; adds cost and operational responsibility
Permanently prevent decryption of data protected by imported material	Delete the imported key material	The operation is irreversible and data may become unrecoverable

Common Exam Traps

Confusing key size with data size: KMS key material can protect large data through envelope encryption, but direct KMS encryption is limited to 4 KB.
Assuming AWS managed keys are fully configurable: Customers cannot change their key policies or configure their rotation schedule.
Assuming every key rotates automatically: Imported, asymmetric, HMAC, and custom-key-store keys require manual rotation.
Expecting a new key ID after automatic rotation: Automatic rotation retains the same logical key ID and ARN.
Treating an alias as a key: An alias is a name that points to a KMS key; it is not key material and does not itself grant permissions.
Granting only IAM permissions: KMS authorization also depends on the key policy and, for some service workflows, grants or service conditions.
Confusing CloudHSM with an external key store: A custom key store uses an AWS CloudHSM cluster managed by the customer; XKS uses an external key manager outside AWS.
Assuming deleting imported key material deletes the ciphertext: The ciphertext may remain, but it can no longer be decrypted using the deleted material.
Using a KMS key as an application data-encryption engine: KMS protects DEKs; application code or an integrated service encrypts the bulk data.

Real-World Engineer Notes

Separate key administrators from key users. A security or platform team can manage key policies while workloads receive only the cryptographic actions they need.
Prefer aliases in application configuration, deployment templates, and key-rotation procedures so manual replacement does not require widespread code changes.
Use kms:ViaService where the key should be usable only through a specific AWS service, especially when direct application calls would be excessive.
Treat imported key material and external key stores as lifecycle and availability dependencies, not merely compliance checkboxes.
Design cross-account encryption workflows early. Resource sharing and KMS authorization are separate control planes.
Record the intended recovery and deletion behavior before disabling or deleting key material. A key policy or key deletion decision can affect backups, snapshots, logs, and replicas.

Quick Reference Summary

KMS key: Logical AWS resource containing or referencing key material.
Customer managed key: Customer-controlled policy and lifecycle.
AWS managed key: AWS-managed service key in the customer account.
AWS owned key: AWS-controlled key not visible to the customer.
Direct KMS encryption limit: 4 KB.
DEK: Data encryption key used for bulk encryption in envelope encryption.
Automatic rotation: Optional, typically every 365 days for eligible customer managed symmetric keys.
Manual rotation: New KMS key and new key ID; aliases reduce application changes.
Grant: Delegated KMS permission that can be created or revoked independently of policies.
kms:ViaService: Limits key use to requests through specified AWS services.
Custom key store: KMS backed by customer-managed AWS CloudHSM.
External key store: KMS integrated with an external key manager.
Cryptographic erasure: Deleting imported key material so protected data cannot be decrypted.

Flashcards

Q: How much data can a KMS key directly encrypt?

A: Up to 4 KB. Larger data should use envelope encryption with a DEK.

Q: What is a data encryption key?

A: A key generated or protected through KMS and used by an application or AWS service to encrypt bulk data.

Q: What happens to a KMS key ID during automatic rotation?

A: The key ID and ARN remain the same while the underlying key material changes.

Q: Which customer managed keys support automatic rotation?

A: Eligible symmetric keys with key material generated by AWS KMS.

Q: Name four key types or configurations that do not support automatic rotation.

A: Asymmetric keys, HMAC keys, custom-key-store keys, and keys with imported key material.

Q: How can an application avoid code changes during manual key rotation?

A: Reference an alias and repoint it to the replacement KMS key.

Q: What is the difference between AWS managed and AWS owned keys?

A: AWS managed keys are service-specific keys in the customer account; AWS owned keys are controlled by AWS and are not visible or manageable by the customer.

Q: What is the purpose of a KMS key policy?

A: It defines administrative and cryptographic permissions for the key.

Q: When are KMS grants useful?

A: When temporary or delegated permissions are needed without modifying key or IAM policies.

Q: What does kms:ViaService do?

A: Restricts KMS key usage to requests made through specified AWS services.

Q: What is a custom key store?

A: A KMS key store backed by a customer-owned and managed AWS CloudHSM cluster.

Q: What does deleting imported key material accomplish?

A: It removes the ability to decrypt data protected by that material, providing cryptographic erasure.

Practice Questions

Question 1

A company encrypts multi-gigabyte objects in an application. Security requires that the application use AWS KMS, but the team is concerned that KMS cannot directly encrypt objects of this size. Which design is correct?

A. Call Encrypt with the entire object as the plaintext.
B. Generate a DEK with KMS, encrypt the object with the DEK, and encrypt the DEK with a KMS key.
C. Store the plaintext object in S3 and use a KMS key only for access control.
D. Create an asymmetric KMS key and use it to encrypt the object.

Correct answer: B

KMS direct encryption is limited to 4 KB. Envelope encryption uses a DEK for bulk data and a KMS key to protect the DEK.

Question 2

A workload uses a customer managed symmetric KMS key with AWS KMS-generated key material. The security team enables automatic rotation. What must the application do when rotation occurs?

A. Replace the KMS key ARN every 365 days.
B. Retrieve the new key ID and update all encrypted data immediately.
C. Continue using the existing key reference; KMS changes the backing key material.
D. Re-encrypt all data because automatic rotation invalidates previous ciphertext.

Correct answer: C

Automatic rotation preserves the logical KMS key ID, ARN, policies, permissions, and aliases. KMS retains the older material as needed to decrypt data encrypted with it.

Question 3

A company imports key material into KMS and later determines that the material may have been compromised. The company wants existing ciphertext protected by that material to become permanently undecryptable. Which action meets the requirement?

A. Disable the KMS key.
B. Delete the key alias.
C. Delete the imported key material.
D. Remove the IAM permissions for Decrypt.

Correct answer: C

Deleting imported key material prevents decryption using that material. Disabling a key or removing permissions can be reversed and does not constitute cryptographic erasure.

Question 4

A security team wants an application role to use a KMS key only when requests are made through Amazon RDS or Amazon EC2. Which control is most appropriate?

A. Add an kms:ViaService condition to the key policy.
B. Use an S3 bucket policy.
C. Configure an AWS WAF rule.
D. Replace the KMS key with an AWS owned key.

Correct answer: A

The kms:ViaService condition key can restrict KMS usage to specified integrated AWS services, such as RDS and EC2.

Question 5

An organization requires KMS-backed keys to remain in a dedicated HSM cluster that the organization owns and manages in AWS. The keys must be used with symmetric KMS operations. Which option should be selected?

A. AWS owned key
B. AWS managed key
C. KMS custom key store backed by CloudHSM
D. External key store only

Correct answer: C

A custom key store uses a customer-owned and managed AWS CloudHSM cluster for key storage and cryptographic operations. An external key store uses an external key manager outside AWS.