What's changed: Deepened SOA-C02 Chapter 4 to Associate depth (tables, scenarios, FAQ, traps; localized figures)
4.2Data Protection and Encryption (KMS, ACM)
Understand encryption at rest (KMS for S3/EBS/RDS), encryption in transit (TLS with ACM certificates), and secrets management operations.
Protect data both at rest and in transit. On AWS, KMS protects at rest and TLS (certificates via ACM) protects in transit.
4.2.1Encryption at rest and in transit
- KMS: manages keys for encryption at rest of S3 (SSE), EBS, RDS, etc., with auditable usage.
- ACM: issues and auto-renews TLS certificates, applied to ELB/CloudFront to protect data in transit.
- Secrets Manager / SSM Parameter Store: store passwords/API keys encrypted.
Common on SOA: encryption-at-rest keys = KMS, issue/auto-renew TLS certs = ACM, avoid cert expiry = ACM auto-renewal. Enable EBS/RDS encryption at creation time as a rule.
Data protection separates "at rest" from "in transit." At rest, encrypt with KMS keys. For S3 choose SSE-S3 (AWS-managed key), SSE-KMS (KMS CMK with auditable usage via CloudTrail), or SSE-C (customer-provided key); enable EBS/RDS encryption at creation (existing encryption can’t be toggled in place—copy the snapshot with encryption and recreate). Account-default EBS encryption and S3 default encryption matter operationally. In transit is protected by TLS (HTTPS), with certificates issued and auto-renewed by ACM (applied to ELB/CloudFront/API Gateway; ACM auto-renewal prevents the classic expired-cert outage). Keep secrets (DB passwords, API keys) in Secrets Manager (auto-rotation) or SSM Parameter Store SecureString (KMS-encrypted), never plaintext in code or env vars. Control "who can encrypt/decrypt with which key" via the key policy + IAM to prevent misuse.
| Protect | Means |
|---|---|
| S3/EBS/RDS at rest | KMS (SSE-S3/SSE-KMS/SSE-C) |
| Traffic (in transit) | TLS + ACM cert (auto-renew) |
| Passwords/API keys | Secrets Manager / Parameter Store |
| Existing unencrypted EBS | Encrypt-copy the snapshot and recreate |
Scenario: an audit requires encryption at rest and TLS. Default S3 to SSE-KMS and enable account-default EBS encryption (replace existing volumes via encrypt-copied snapshots). Apply ACM certificates to ELB/CloudFront for public endpoints with auto-renewal to prevent expiry. Move DB credentials to Secrets Manager to eliminate plaintext.
Q. Keys for encryption at rest? KMS. Q. Issue/auto-renew TLS certs? ACM. Q. Existing unencrypted EBS? Encrypt-copy the snapshot and recreate. Q. Where do passwords go? Secrets Manager / Parameter Store (no plaintext). Q. Avoid cert-expiry incidents? ACM auto-renewal.
Watch the mix-ups: (1) Existing EBS encryption can’t be toggled in place—recreate via an encrypted snapshot. (2) SSE-S3 vs. SSE-KMS (the latter lets you manage/audit the key). (3) ACM auto-renewal works only when prerequisites (e.g., DNS validation) hold. (4) Certs are Region-scoped (CloudFront needs us-east-1).
For an existing unencrypted EBS volume, enable encryption while copying its snapshot and recreate the volume from it.
4.2.2Section summary
- At rest = KMS / in transit = TLS (certs via ACM, auto-renewed)
- Manage secrets with Secrets Manager/SSM
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. You want to issue and auto-renew TLS certificates for ELB/CloudFront. What do you use?
Q2. Which service manages keys for encryption at rest of S3/EBS?
Q3. You want to encrypt an existing unencrypted EBS volume. What is the common approach?
Keep track of your progress
The full study guide is free to read. Sign up free to practice with the question bank, track what you have read, review your mistakes, and highlight passages.