Data Protection
Protect data in its three concerns: moving, sitting, and the keys underneath both
Every question in this 18 percent domain is really asking where a piece of data is exposed and which control closes that gap. Data has three concerns: it is in transit while it moves between a client and a service, it is at rest once a service has stored the bytes, and underneath both sits the key and secret layer, the cryptographic material and credentials that make encryption mean anything. Name the concern first and the service follows: an aws:SecureTransport question is in-transit, an S3 SSE question is at-rest, and a rotation or key-origin question is the key layer. The classic trap dresses one concern as another, offering a setting that merely allows TLS when the scenario asks you to prove plaintext is impossible, or pointing at AWS KMS (Key Management Service) when the real ask is rotating a database password.
The domain unfolds in three steps: in transit, then at rest, then key and secret material
Read this page as a map, then follow the three subtopics in order. Data in Transit covers traffic on the wire: enforcing TLS at the load balancer security policy and CloudFront, denying any request where aws:SecureTransport is false, and keeping calls off the public internet with interface and gateway VPC endpoints powered by AWS PrivateLink, plus the automatic Nitro inter-instance encryption. Data at Rest covers stored bytes: choosing the encryption mode (SSE-S3, SSE-KMS, DSSE-KMS, or SSE-C), picking AWS KMS versus AWS CloudHSM, and adding write-once-read-many immutability with S3 Object Lock and Backup Vault Lock for ransomware resilience. Secrets & Key Material is the layer beneath both: AWS Secrets Manager and Parameter Store for credentials, key origin and rotation in KMS, AWS Certificate Manager and AWS Private CA for TLS certificates, and log masking. Each subtopic carries the service tables, numbers, and traps; this overview shows how they fit.
At rest you choose the encryption; in the key layer you manage the keys
The sharpest line in this domain separates two jobs that questions love to blur. The at-rest subtopic is about choosing the encryption for stored data: which SSE mode, KMS or CloudHSM, single or dual layer. The secrets and key subtopic is about managing the keys and credentials themselves: who generates the key material, whether it rotates, where a password lives, which certificate authority signs a cert. Match each kind of sensitive material to the service whose lifecycle fits it, and do not force a password into a key service or a key into a secret store. Two facts settle most ties: AWS KMS is already validated at FIPS 140-3 Security Level 3, so a bare FIPS requirement no longer points to CloudHSM (reach for CloudHSM only for single-tenancy, dedicated hardware, or full key custody), and only symmetric customer-managed KMS keys with AWS-generated material rotate automatically, so a key's origin decides its rotation and recovery story.
The three data-protection concerns and where each is covered
| Concern | Protects against | Key controls | Drill into |
|---|---|---|---|
| In transit | Eavesdropping or tampering on the wire, plaintext network paths | TLS via ELB security policy and CloudFront, deny on aws:SecureTransport false, PrivateLink endpoints, Nitro inter-instance encryption | Data in Transit |
| At rest | Reading stored bytes, plus deletion or overwrite of data | SSE-S3, SSE-KMS, DSSE-KMS, SSE-C, KMS vs CloudHSM, Object Lock and Backup Vault Lock | Data at Rest |
| Key and secret material | Stale, exposed, or unmanaged keys, credentials, and certificates | Secrets Manager, Parameter Store, KMS key origin and rotation, ACM and AWS Private CA, log masking | Secrets & Key Material |