AWS Certified Developer - Associate (DVA-C02) #8 Domain 2-2 Security — Encryption and Secrets
Now that we’ve covered “who accesses” in #7 Authentication and Authorization, this time it’s how you protect the data and secret values themselves. Encryption in DVA comes down to one principle: “don’t keep passwords, API keys, and DB credentials in plaintext in code and environment variables.”
KMS — key management #
Key Management Service (KMS) is a service for creating and managing encryption keys. Most AWS services integrate with KMS to encrypt data at rest.
| Key type | Managed by | Characteristics |
|---|---|---|
| AWS managed key | AWS | Auto-created/managed by the service (aws/s3, etc.). Free |
| Customer managed key (CMK) | You | Directly control key policy, rotation, and deletion. Auditing and fine-grained control |
| AWS owned key | AWS | Shared across many accounts, invisible |
A customer managed key lets you control who can use the key via the key policy, audit key usage with CloudTrail, and enable automatic rotation (once a year). The answer to “I need to audit who decrypted the data and when” is a customer managed key (or SSE-KMS).
Envelope encryption #
You don’t encrypt large data directly with KMS, because the KMS API only encrypts directly up to 4 KB. Instead, you use envelope encryption.
- Request
GenerateDataKeyfrom KMS to get a data key (a pair: plaintext + encrypted). - Encrypt the actual data locally with the plaintext data key.
- Erase the plaintext data key from memory and store the encrypted data key next to the data.
- To decrypt, send the encrypted data key to KMS, get the plaintext key back via
Decrypt, and unlock the data.
The point of envelope encryption: KMS handles only the small data key, and the large data is encrypted locally with that data key. In large-data encryption questions, “encrypt directly with KMS” is usually wrong.
at rest vs in transit #
- at rest (stored data) — storage encryption for S3, EBS, RDS, DynamoDB. Usually integrated with KMS.
- in transit (data in transit) — TLS/SSL. Issue and manage certificates with ACM (Certificate Manager).
S3 server-side encryption #
S3 storage encryption options are an exam regular.
| Option | Key management | Characteristics |
|---|---|---|
| SSE-S3 | Managed by S3 (AES-256) | Simplest. The default |
| SSE-KMS | KMS key | Usage auditing (CloudTrail), key policy control. Per-key permissions |
| SSE-C | Customer provides the key | The customer passes the key directly; AWS doesn’t store it |
| Client-side encryption | Customer encrypts before upload | AWS sees only ciphertext |
If you need “audit who decrypted,” it’s SSE-KMS; if it’s simple, SSE-S3; if you never want to entrust the key to AWS, SSE-C or client-side encryption.
Lambda environment variable encryption #
As seen in #2, environment variables are encrypted at rest. If you need stronger protection, encrypt them with a KMS customer managed key, and you can use the “encryption-in-transit helper” to encrypt them at deploy time to prevent exposure in transit. That said, for sensitive secrets it’s recommended to read them at runtime from Secrets Manager / Parameter Store instead of environment variables.
Secrets Manager vs Parameter Store #
You need to know the difference between these two services that keep secrets and config values out of code.
| Aspect | Secrets Manager | Parameter Store (SSM) |
|---|---|---|
| Primary use | Secrets (DB credentials, API keys) | Config values + secrets (SecureString) |
| Automatic rotation | Built-in (integrated with RDS, etc.) | None (you implement it with Lambda) |
| Cost | Paid per secret | Standard parameters free, Advanced paid |
| Size/hierarchy | Secret-centric | Hierarchical paths (/app/db/host) |
| Integration | Cross-service automatic rotation | Simple store/retrieve |
The key decision: if you need automatic rotation, Secrets Manager; if it’s simple config values or cost matters, Parameter Store. The answer to “periodically auto-rotate RDS credentials” is Secrets Manager. The answer to “store config values hierarchically at no cost” is Parameter Store standard parameters.
Parameter Store can also reference Secrets Manager secrets and KMS keys, so the two are sometimes used together. But “built-in automatic rotation” is a Secrets Manager-only feature.
Exam question patterns #
- “Periodically auto-rotate DB credentials.” → Secrets Manager.
- “Store and retrieve config values hierarchically for free.” → Parameter Store standard parameters.
- “How do you give a password to Lambda?” → Read at runtime from Secrets Manager / Parameter Store (not plaintext environment variables).
- “Audit who decrypted an S3 object.” → SSE-KMS.
- “Trying to encrypt a large file with KMS.” → Envelope encryption (use a data key).
- “Encrypt S3 without ever storing the key in AWS.” → SSE-C or client-side encryption.
- “Manage in-transit encryption certificates.” → ACM.
Common traps #
1) Assuming Parameter Store has automatic rotation #
Built-in automatic rotation is Secrets Manager. Parameter Store requires you to implement it yourself.
2) Encrypting large data directly with KMS #
Direct KMS encryption has a 4 KB limit. Large data uses envelope encryption.
3) Keeping secrets as plaintext environment variables #
Even though environment variables are encrypted, it’s recommended to read sensitive secrets from a secret store.
Wrap-up #
What this post locked in:
- KMS — AWS managed vs customer managed (auditing, control). Direct encryption has a 4 KB limit
- Envelope encryption — encrypt large data locally with a KMS data key
- SSE-KMS allows decryption auditing, SSE-S3 is simple, SSE-C uses a customer key
- Secrets Manager (built-in automatic rotation) vs Parameter Store (free, hierarchical, no rotation)
- Read secrets from a secret store at runtime, not as plaintext in code or environment variables
Next — Domain 3-1 CI/CD #
We’ve finished security. Next is deployment, which carries 24%. In #9 CI/CD, I’ll cover the division of roles among CodeCommit, CodeBuild, CodeDeploy, CodePipeline, and CodeArtifact, buildspec.yml and appspec.yml, and pipeline composition.