Study guide
2.2 Encryption & AWS KMS
AWS Certified Developer – Associate DVA-C02
Track your progress as you read
Finished sections get a check mark.
1 Introduction: DVA-C02 Overview & Study Plan
1.1 What the AWS Developer Associate Tests 1.2 Exam Format, Scoring & Logistics 1.3 The Four Domains & A Study Plan
2 Chapter 1: Development with AWS Services
1.1 AWS Lambda 1.2 Amazon API Gateway 1.3 Amazon DynamoDB 1.4 Amazon S3 1.5 Messaging: SQS, SNS, EventBridge 1.6 Containers: ECS, ECR, Fargate 1.7 AWS SDK & API Best Practices
3 Chapter 2: Security
2.1 IAM for Developers 2.2 Encryption & AWS KMS 2.3 Secrets Manager vs Parameter Store 2.4 Amazon Cognito
4 Chapter 3: Deployment
3.1 CloudFormation & SAM 3.2 CI/CD with CodePipeline, CodeBuild, CodeDeploy 3.3 Deployment Strategies 3.4 Elastic Beanstalk & Container Deploys
5 Chapter 4: Troubleshooting, Optimization & Exam Strategy
4.1 Observability: CloudWatch & X-Ray 4.2 Performance & Caching 4.3 Common Traps & Final Review
2.2 Encryption & AWS KMS
Key Takeaways Explain This Topic AI
AWS KMS uses envelope encryption: a KMS key encrypts a data key, and the data key encrypts your actual data, so large payloads never travel to KMS
GenerateDataKey returns both a plaintext and an encrypted data key; you encrypt locally, discard the plaintext, and store the encrypted data key beside the ciphertext
Customer managed keys let you set the key policy, enable rotation, and use grants; AWS managed keys are service-controlled and auto-rotate yearly
Automatic rotation applies only to symmetric customer managed keys; the period defaults to 365 days and is configurable between 90 and 2,560 days, and the key ARN never changes
SSE-KMS adds CloudTrail auditing and access control on top of encryption; an S3 Bucket Key reduces KMS request costs on high-volume buckets
Last updated: June 2026
Encryption at Rest vs in Transit
At rest — protecting stored data (S3 objects, EBS volumes, DynamoDB tables, RDS, snapshots). This is AWS Key Management Service (KMS) territory.
In transit — protecting data on the wire with Transport Layer Security (TLS) . You enforce it with a policy Condition: aws:SecureTransport = false → Deny , which rejects any plaintext HTTP request.
Envelope Encryption
A KMS key cannot directly encrypt a payload larger than 4 KB , so KMS uses envelope encryption for real data:
Call GenerateDataKey ; KMS returns a plaintext data key and an encrypted (wrapped) data key .
Encrypt your data locally with the plaintext data key, then discard the plaintext from memory immediately.
Store the encrypted data key next to the ciphertext.
To decrypt, send the encrypted data key to KMS Decrypt to unwrap it, then decrypt the data locally.
This keeps the heavy data local while KMS only ever handles the tiny key. GenerateDataKeyWithoutPlaintext is the variant for systems that want to store an encrypted key now and encrypt later, never holding the plaintext key in the meantime.
Key Types
Key type Who manages it Rotation Cost
Customer managed key (CMK) You edit the key policy You enable; 90–2,560 days (default 365) Per-key monthly fee + API
- AWS managed key ( aws/service ) The service Automatic, yearly, fixed No monthly key fee
- AWS owned key AWS, shared across customers AWS-controlled, invisible Free, no visibility
Use a customer managed key when an answer needs a custom key policy, cross-account sharing, audited rotation, or grants — temporary, fine-grained permissions handed to a principal, often used by integrated AWS services for short-lived operations.
Rotation Facts (Exam Gold)
Automatic rotation works only on symmetric encryption KMS keys whose material AWS KMS generated — not asymmetric, HMAC, or imported-material keys.
The default rotation period is 365 days ; you can configure it from 90 to 2,560 days .
When KMS rotates a key, the key ID and ARN stay the same , so aliases and applications keep working. Old key material is retained so previously encrypted data still decrypts.
Rotating a key does not re-encrypt existing data; new data uses new material, old data uses the retained material.
Service Integration
S3 — SSE-S3 (S3-managed AES-256, no per-object audit trail) vs SSE-KMS (a KMS key, CloudTrail audit, fine-grained access control). Enable an S3 Bucket Key to collapse many KMS calls into one and cut request costs on high-volume buckets. SSE-C lets the caller supply the key.
EBS — volume encryption is transparent; snapshots and any volume restored from an encrypted snapshot inherit encryption automatically.
DynamoDB — encrypted at rest by default ; you choose an AWS owned, AWS managed, or customer managed KMS key.
CloudTrail logs every Decrypt / GenerateDataKey call, which is exactly why SSE-KMS is the answer when auditing key usage is required.
Key Policies, Grants, and Access Control
A KMS key's key policy is the primary access control document — unlike most resources, a CMK is not automatically usable by everyone in the account; the key policy must explicitly delegate to IAM. Three patterns recur on the exam:
Key policy statements name principals and the KMS actions ( kms:Encrypt , kms:Decrypt , kms:GenerateDataKey ) they may perform.
Grants provide temporary, programmatic permissions that AWS services and applications use for short-lived operations; they are easy to create and revoke and avoid editing the key policy.
kms:ViaService conditions restrict a key so it can only be used through a specific service (for example, only via dynamodb.us-east-1.amazonaws.com ).
If an application throws an AccessDeniedException only when encryption is involved, the cause is almost always a missing kms:Decrypt (or GenerateDataKey ) permission on the key policy or the caller's IAM policy — not the data-layer permission.
Choosing the Right Encryption Answer
When a scenario stresses no audit trail needed, simplest, cheapest for S3, the answer is SSE-S3. When it stresses per-key access control, CloudTrail visibility, or compliance , the answer is SSE-KMS with a customer managed key. When it stresses the customer must hold the key material , it is SSE-C or imported key material. For very high request volumes against one bucket, the S3 Bucket Key is the cost-control answer because it dramatically reduces the number of KMS API requests by deriving object keys from a single bucket-level key.
Symmetric vs Asymmetric and Other Key Specs
KMS supports more than the default symmetric key, and the exam expects you to match the spec to the job. Symmetric keys (AES-256) handle the vast majority of encrypt/decrypt and GenerateDataKey work and are the only type eligible for automatic rotation. Asymmetric keys (RSA or elliptic-curve pairs) are for cases where a partner must encrypt with a public key without calling KMS, or for signing and verification ( Sign / Verify ). HMAC keys generate and verify message authentication codes.
A worked example: to let an external system encrypt data it sends you without granting it KMS access, hand out the public half of an asymmetric KMS key; only your account, holding the private half, can Decrypt . Because asymmetric, HMAC, and imported-material keys cannot auto-rotate, you must rotate them manually by creating a new key and re-pointing the alias.