This chapter covers AWS Key Management Service (KMS) and encryption concepts essential for the DVA-C02 exam. You will learn how KMS works, how to use it to encrypt data at rest and in transit, and the common patterns developers implement. This topic area typically accounts for 5-10% of exam questions, often appearing in the Security domain. Mastery of KMS is critical because encryption is a recurring theme across many services, and the exam tests your ability to choose the right encryption approach for a given scenario.
Jump to a section
Imagine you work for a company that ships sensitive documents overseas. You have a master key that opens the company's main vault, but you cannot use that master key to lock every individual package—if it's compromised, everything is lost. Instead, you use the master key to open a cabinet that contains many smaller, unique keys. For each package, you take one small key, lock the package with it, and then lock that small key inside a smaller lockbox using the master key. You ship the package with the small lockbox attached. The recipient uses the master key (which they also have) to open the lockbox, retrieve the small key, and unlock the package. If a small key is ever compromised, only that one package is affected; the master key remains safe. This is exactly how AWS KMS envelope encryption works: a master key (CMK) encrypts data keys, and those data keys encrypt your actual data. The master key never leaves the KMS service, and data keys are used locally for encryption and then discarded.
What is AWS KMS?
AWS Key Management Service (KMS) is a managed service that lets you create, store, and control cryptographic keys. It is integrated with many AWS services (S3, EBS, RDS, DynamoDB, etc.) to encrypt data at rest. KMS is also used to encrypt data in transit when combined with services like AWS Certificate Manager (ACM) for TLS. The exam focuses on KMS because it is the foundation for encryption in AWS.
Customer Master Keys (CMKs)
A CMK is the primary key resource in KMS. It can be symmetric (AES-256) or asymmetric (RSA or ECC). Symmetric CMKs are used for envelope encryption and are the most common. Asymmetric CMKs are used for encrypt/decrypt outside AWS or for digital signing. CMKs never leave KMS unencrypted; all cryptographic operations happen inside the service.
AWS Managed CMKs: Created automatically when you enable encryption on a service (e.g., S3, EBS). They are free but cannot be deleted or rotated manually.
Customer Managed CMKs: Created by you. You control key policies, rotation, and deletion. You pay $1/month per key plus usage costs.
Custom Key Stores: You can use AWS CloudHSM to create a custom key store where keys are stored in HSM hardware under your control.
Key Policies and IAM
KMS uses key policies to control access to CMKs. A key policy is a resource-based policy attached to the CMK. IAM policies can also grant access, but only if the key policy allows IAM policies to be used (via a default statement). The exam tests that you understand the difference:
Key policy: Directly attached to the key, can grant access to users/roles in other accounts.
IAM policy: Must be combined with a key policy that grants kms:* to the account's IAM policy principal.
Envelope Encryption
Envelope encryption is the process of encrypting data with a data key and then encrypting the data key with a CMK. This is the core pattern for encrypting large data efficiently. The steps are:
Call GenerateDataKey to get a plaintext data key and an encrypted copy.
Use the plaintext data key locally (e.g., in your application) to encrypt the data.
Discard the plaintext data key.
Store the encrypted data key alongside the encrypted data.
To decrypt, retrieve the encrypted data key and call Decrypt to get the plaintext data key.
Use the plaintext data key to decrypt the data.
This pattern ensures the CMK is used only for small operations (encrypting data keys), reducing cost and latency.
Data Key Caching
KMS offers data key caching via the AWS Encryption SDK. You can cache data keys to reduce the number of KMS API calls. The cache has a maximum age, maximum number of keys, and a security threshold (number of uses before re-encryption). The exam may ask about trade-offs: caching improves performance but reduces security because the same data key is reused.
Key Rotation
AWS Managed CMKs: Automatically rotated every 3 years (1095 days).
Customer Managed CMKs: Can enable automatic rotation annually (365 days). You can also manually rotate by creating a new CMK and updating aliases.
Asymmetric CMKs: Cannot be automatically rotated.
Rotation creates new backing key material, but the old material is retained for decrypting old data. The CMK ID remains the same; only the key material changes.
Key Deletion
Deleting a CMK is a destructive action that can render data permanently unrecoverable. KMS enforces a waiting period (7-30 days) before deletion. During this period, the key is disabled and can be cancelled. After deletion, the key material is destroyed.
Encryption Context
Encryption context is a set of key-value pairs that KMS includes in the authentication tag. It is used to provide additional authenticated data (AAD). The same context must be provided during decryption; otherwise, decryption fails. This is a security feature that binds the encrypted data to its context, preventing misuse. The exam often tests that encryption context is not secret but must be consistent.
Grant Tokens
Grants are a way to delegate temporary access to a CMK without modifying key policies. A grant includes a grant token that must be included in API calls. Grants have constraints (e.g., operations allowed, encryption context). They are useful for cross-account access or delegated administration.
Integration with AWS Services
KMS is integrated with many services:
S3: Server-side encryption with KMS (SSE-KMS) uses a CMK to encrypt S3 objects. You can specify a CMK via the x-amz-server-side-encryption-aws-kms-key-id header. S3 supports bucket policies that require SSE-KMS.
EBS: EBS volumes can be encrypted with a CMK. Snapshots and AMIs inherit the encryption status.
RDS: RDS instances can be encrypted at rest using KMS. You cannot encrypt an existing unencrypted instance; you must take a snapshot and restore it as encrypted.
DynamoDB: DynamoDB tables can be encrypted at rest with a CMK (DynamoDB encryption at rest).
Lambda: Environment variables can be encrypted with a CMK using the aws-lambda service.
Secrets Manager: Secrets can be encrypted with a CMK.
Encryption SDK
The AWS Encryption SDK is a client-side library that implements envelope encryption and data key caching. It is available for multiple programming languages. The SDK handles generating data keys, encrypting, and decrypting. It also supports multiple master keys (keyrings) for redundancy.
CloudTrail Logging
All KMS API calls are logged in CloudTrail. This is important for auditing and compliance. The exam may ask about detecting unauthorized key usage via CloudTrail.
Common CLI Commands
# Create a symmetric CMK
aws kms create-key --description "My key"
# Create an alias
aws kms create-alias --alias-name alias/my-key --target-key-id <key-id>
# Generate a data key
aws kms generate-data-key --key-id alias/my-key --key-spec AES_256
# Encrypt data (small, up to 1 MB)
aws kms encrypt --key-id alias/my-key --plaintext fileb://plaintext.txt --output text --query CiphertextBlob | base64 --decode > encrypted.txt
# Decrypt data
aws kms decrypt --ciphertext-blob fileb://encrypted.txt --output text --query Plaintext | base64 --decode > decrypted.txt
# Enable automatic rotation
aws kms enable-key-rotation --key-id <key-id>
# Schedule key deletion
aws kms schedule-key-deletion --key-id <key-id> --pending-window-in-days 7Pricing
Customer managed CMK: $1/month per key.
AWS managed CMK: Free.
API calls: $0.03 per 10,000 requests (symmetric) or $0.05 per 10,000 (asymmetric).
Data key caching may reduce costs.
Limitations
Maximum plaintext size for encrypt and decrypt is 1 MB (for direct encryption without data key).
CMK key material cannot be exported.
KMS is regional; keys do not automatically replicate across regions. You must create keys in each region or use multi-Region keys (available for symmetric CMKs).
Multi-Region Keys
Multi-Region keys allow you to have a single CMK that exists in multiple regions. They have the same key ID and material, enabling cross-region decryption without cross-region API calls. Useful for disaster recovery and global applications.
Create a Customer Managed CMK
In the KMS console or via CLI, create a symmetric CMK. You specify a key policy that defines who can use and manage the key. You can also create an alias for easier reference. The key is stored in the KMS service and never leaves it unencrypted. AWS generates the key material using FIPS 140-2 validated hardware security modules (HSMs). The key ID is returned, which you use in subsequent API calls.
Generate a Data Key
Call `GenerateDataKey` with the CMK ID and a key spec (e.g., AES_256). KMS returns two versions: a plaintext data key (used for encryption) and an encrypted copy (ciphertextBlob). The plaintext key is returned over a TLS-encrypted channel. The encrypted key is stored alongside the encrypted data. The plaintext key should never be stored persistently.
Encrypt Data Locally
Use the plaintext data key to encrypt your data using a client-side encryption library (e.g., AWS Encryption SDK, OpenSSL, or your own implementation). The encryption algorithm is typically AES-GCM, which provides authenticated encryption. The encrypted data (ciphertext) is stored. The plaintext data key is then securely discarded from memory.
Store Encrypted Data and Key
Store the encrypted data and the encrypted data key together (e.g., in the same file or database record). You may also include the encryption context used during generation. The encrypted data key is safe to store because it can only be decrypted by KMS using the same CMK and encryption context.
Decrypt Data with KMS
To decrypt, retrieve the encrypted data key and call `Decrypt` with the encrypted data key and the same encryption context. KMS returns the plaintext data key. Use this plaintext key to decrypt the data locally. After decryption, discard the plaintext key. This ensures the CMK is used only for small operations, keeping costs low and security high.
Enterprise Scenario 1: Encrypting S3 Objects with SSE-KMS
A financial services company stores sensitive customer documents in S3. They must encrypt all objects at rest. They use SSE-KMS with a customer managed CMK. The bucket policy enforces that all PUT requests include the x-amz-server-side-encryption header with value aws:kms. The CMK key policy grants access only to specific IAM roles used by their application. The application uses the AWS SDK to upload objects with ServerSideEncryption: 'aws:kms' and SSEKMSKeyId: alias/my-key. For decryption, the application calls GetObject and KMS automatically decrypts the object if the IAM role has kms:Decrypt permission. This setup ensures data is encrypted at rest and access is controlled via IAM and key policies. Performance is acceptable for objects up to several GB; for larger objects, the application uses multipart upload with SSE-KMS, which requires the same CMK for all parts.
Enterprise Scenario 2: Cross-Account Encryption with Grants
A SaaS provider needs to process data from multiple customers (different AWS accounts). Each customer wants their data encrypted with a CMK in their own account. The SaaS provider's application runs in a central account. The customer creates a grant in their KMS key that allows the SaaS provider's IAM role to use the key for specific operations (e.g., Encrypt, Decrypt). The grant includes an encryption context constraint that ensures the SaaS provider can only encrypt/decrypt with a specific context (e.g., customer-id:12345). The SaaS provider includes the grant token in all KMS API calls. This avoids the need for complex cross-account IAM roles and key policies. Common pitfalls: grant tokens expire after 24 hours (configurable up to 365 days), and the grant must be renewed. Also, the encryption context must match exactly; otherwise, decryption fails.
Enterprise Scenario 3: Database Encryption with RDS and KMS
A healthcare organization stores patient records in RDS (MySQL). They enable RDS encryption at rest using a customer managed CMK. This encrypts the underlying storage, automated backups, read replicas, and snapshots. To encrypt an existing database, they must take a snapshot, create a new encrypted instance from the snapshot, and then point their application to the new instance. They also enable encryption in transit using TLS. The CMK key policy restricts who can manage the key (e.g., DBA team) and who can use it (RDS service). They monitor CloudTrail for any unauthorized Decrypt calls. A common mistake is forgetting that read replicas in other regions must use the same CMK (multi-Region key) or a different key in that region, which complicates replication.
The DVA-C02 exam tests KMS and encryption under Domain 2 (Security), Objective 2.3: Implement encryption in transit and at rest. Expect 3-5 questions. The most common wrong answers come from misunderstanding envelope encryption, key policies vs IAM, and encryption context.
Common Wrong Answers: 1. "Use the CMK directly to encrypt large data." – Wrong because CMK operations are limited to 1 MB payload. The correct approach is envelope encryption with GenerateDataKey. 2. "Store the plaintext data key in a database for later decryption." – Wrong because the plaintext data key should never be stored. Store only the encrypted data key. 3. "Encryption context is secret and must be hidden." – Wrong. Encryption context is not secret; it is additional authenticated data that must match during decryption. 4. "IAM policies alone can grant access to KMS keys." – Wrong. The key policy must also allow IAM policies (default does) but if you remove that statement, IAM policies alone are insufficient. 5. "KMS automatically replicates keys across regions." – Wrong. Keys are regional unless you use multi-Region keys, which must be explicitly created.
Specific Numbers and Terms:
- GenerateDataKey vs GenerateDataKeyWithoutPlaintext: The latter returns only the encrypted data key (no plaintext). Use when you don't need to encrypt locally (e.g., server-side encryption by a service).
- Maximum plaintext size for encrypt/decrypt: 1 MB.
- Default key rotation for customer managed CMKs: annual (365 days).
- Deletion waiting period: 7-30 days.
- Encryption context is a key-value pair (max 16 pairs, total size 131072 bytes).
- Grant token expiration: up to 365 days.
Edge Cases:
- If you lose access to the CMK (e.g., key policy misconfiguration), you cannot decrypt data. Always test key policies.
- When using SSE-KMS with S3, you cannot use multipart upload with a custom CMK if you do not have kms:Decrypt permission for the same key (each part is encrypted with the same data key).
- Asymmetric CMKs: Can be used for encrypt/decrypt outside AWS (e.g., in external systems). The public key can be downloaded, but the private key never leaves KMS.
How to Eliminate Wrong Answers:
- If a question mentions encrypting large data, eliminate any answer that uses encrypt API directly. Look for GenerateDataKey or envelope encryption.
- If a question mentions cross-account access, look for grants or key policies that allow external principals. IAM policies alone cannot grant cross-account access.
- If a question mentions encryption context, remember it must be provided during decryption; it is not secret.
- If a question mentions key rotation, remember that automatic rotation is only for symmetric CMKs (customer managed) and not for asymmetric or AWS managed (except automatic 3-year rotation).
Envelope encryption uses a CMK to encrypt a data key, which then encrypts the actual data. This is the standard pattern for encrypting large data with KMS.
GenerateDataKey returns both plaintext and encrypted data keys. GenerateDataKeyWithoutPlaintext returns only the encrypted key.
CMK operations (encrypt, decrypt) are limited to 1 MB plaintext. For larger data, use envelope encryption.
Customer managed CMKs cost $1/month. AWS managed CMKs are free.
Automatic key rotation for customer managed symmetric CMKs is annual (365 days). AWS managed CMKs rotate every 3 years.
Encryption context is additional authenticated data (AAD) that must match during decryption. It is not secret.
Key deletion has a waiting period of 7-30 days. During this period, the key is disabled and can be cancelled.
Grants provide temporary access to a CMK without modifying key policies. Grant tokens expire up to 365 days.
KMS is regional. Multi-Region keys allow the same key material in multiple regions.
All KMS API calls are logged in CloudTrail for auditing.
Asymmetric CMKs can be used for encrypt/decrypt outside AWS (public key download, private key stays in KMS).
Data key caching reduces API calls but reuses data keys, which may be less secure.
These come up on the exam all the time. Here's how to tell them apart.
SSE-S3 (AES-256)
Uses S3-managed keys (no customer control)
No additional cost
No audit trail for key usage
Cannot enforce use of a specific key
Default encryption for S3
SSE-KMS
Uses customer managed CMK (more control)
Costs $1/month per CMK plus API usage
All key usage logged in CloudTrail
Can enforce specific key via bucket policy
Requires IAM permissions for kms:Encrypt/Decrypt
Mistake
KMS can encrypt data of any size directly.
Correct
KMS encrypt and decrypt APIs have a 1 KB limit (actually 1 MB for plaintext). For larger data, you must use envelope encryption with GenerateDataKey.
Mistake
You can export the private key of a KMS CMK.
Correct
KMS CMKs never leave the service unencrypted. You cannot export the key material. The only exception is custom key stores with CloudHSM, but even then the key remains in the HSM.
Mistake
Encryption context is a secret that must be protected.
Correct
Encryption context is not secret; it is additional authenticated data (AAD) that is included in the authentication tag. It must be provided during decryption but can be stored alongside the ciphertext.
Mistake
AWS managed CMKs support automatic rotation every year.
Correct
AWS managed CMKs rotate every 3 years (1095 days) automatically. Customer managed CMKs can be set to rotate annually. Asymmetric CMKs do not support automatic rotation.
Mistake
IAM policies alone can grant access to a CMK in another account.
Correct
Cross-account access requires a key policy that grants access to the external account's IAM role or user. IAM policies in the external account are not sufficient unless the key policy allows it.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
GenerateDataKey returns both a plaintext data key and an encrypted copy. Use it when you need to encrypt data locally. GenerateDataKeyWithoutPlaintext returns only the encrypted data key. Use it when you want the AWS service (e.g., S3) to handle encryption and you don't need the plaintext key locally. The encrypted key can be stored and later decrypted by KMS.
Yes, but you should use envelope encryption. Call GenerateDataKey to get a data key, use that key to encrypt your data with a client-side library (e.g., AWS Encryption SDK), store the encrypted data key alongside the ciphertext, and later call Decrypt to retrieve the plaintext data key. Avoid using the Encrypt API for large data because it has a 1 MB limit.
For customer managed symmetric CMKs, you can enable automatic rotation annually (365 days). AWS managed CMKs rotate every 3 years (1095 days) automatically. Rotation creates new backing key material; the old material is retained for decrypting old data. The CMK ID and alias remain the same. Asymmetric CMKs cannot be automatically rotated.
Deleting a CMK is permanent and irreversible. You must schedule deletion with a waiting period of 7-30 days. During this period, the key is disabled and can be cancelled. After deletion, any data encrypted with that key becomes permanently unrecoverable. Always ensure you do not need the key before deleting.
Encryption context is a set of key-value pairs that KMS includes in the authentication tag. It is additional authenticated data (AAD) that binds the encrypted data to its context. The same context must be provided during decryption; otherwise, decryption fails. It is not secret and can be stored alongside the ciphertext. It prevents misuse of the ciphertext in different contexts.
Yes, but you need to configure the key policy to allow principals from other accounts. You can also use grants to delegate temporary access. IAM policies alone cannot grant cross-account access; the key policy must explicitly allow the external account. Multi-Region keys can be used across regions but not across accounts without additional configuration.
Customer managed CMKs are created and controlled by you. You can set key policies, enable rotation, and delete them. They cost $1/month. AWS managed CMKs are created automatically when you enable encryption on a service (e.g., S3, EBS). They are free, but you cannot control their policies, rotation (automatic every 3 years), or deletion. They are identified by aliases like aws/s3.
You've just covered KMS and Encryption for Developers — now see how well it sticks with free DVA-C02 practice questions. Full explanations included, no account needed.
Done with this chapter?