Encryption at rest across the stores
Lesson 1 of 5 in Encryption and Masking.
Encryption at rest is table stakes and the exam treats it that way: nobody is asked whether to encrypt, only which switch, on which service, and whether it can still be flipped. That last question is the interesting one, because the answer differs per store and the differences are not guessable.
The pattern underneath is the same everywhere — envelope encryption. The service generates a data key, encrypts your data with it, asks AWS KMS to encrypt that data key under a KMS key, and stores the encrypted data key alongside the ciphertext. Reading it means calling kms:Decrypt on the data key first. Two consequences follow for a data engineer and both show up in questions: every read of encrypted data is a KMS call, which matters for cost and for throttling on a job that opens thousands of files, and the key is a separate authorization from the data, which is why a cross-account read can get past every data permission and fail on the bytes. The internals are taught in depth on the security path at envelope encryption.
Three choices recur, and the words in the stem map onto them cleanly:
- An AWS owned key — invisible, no control, no audit trail of key usage, free. Fine for data with no compliance requirement attached.
- An AWS managed key (
aws/s3,aws/glue,aws/redshift) — visible in your account, rotated by AWS, key usage appears in CloudTrail, and the key policy cannot be edited. That last clause is load-bearing: it means an AWS managed key can never authorise a cross-account read. - A customer managed key — you write the policy, you control rotation, you can disable or schedule deletion, and you can grant another account. This is the answer whenever a requirement mentions cross-account access, a specific rotation period, key separation per dataset, or the ability to make data unreadable by disabling a key.
The question "can I turn it on later?" splits the stores into three groups, and the split is worth memorising because the common belief is wrong for one of them.
| Store | The switch | Enable on existing data? | What the exam asks |
|---|---|---|---|
Amazon S3 | Default bucket encryption: SSE-S3, SSE-KMS, DSSE-KMS or SSE-C | Yes — set default encryption; existing objects keep their original setting until rewritten | That changing default encryption does not re-encrypt what is already there, and that S3 Bucket Keys cut KMS request cost dramatically on a lake with millions of objects |
Amazon Redshift (provisioned) | Cluster encryption with an AWS owned or customer managed key | Yes — Redshift migrates the data to a new encrypted cluster itself | The migration runs with the cluster read-only and status |
Amazon RDS and Aurora | Storage encryption, chosen at creation | No — creation-time only | The migration path: for RDS, copy the snapshot with encryption then restore it; for Aurora, restore the unencrypted cluster snapshot with encryption enabled, because an Aurora cluster snapshot copy cannot add it |
Amazon DynamoDB | Always on — AWS owned, AWS managed or customer managed key | Not applicable; you can change which key, not whether | That encryption cannot be turned off, so a question offering “enable encryption on the table” is describing a non-event |
AWS Glue Data Catalog | Metadata encryption and connection password encryption, set per account | Yes, and they are independent of each other | That every catalog client then needs KMS permission too, so enabling it on a live account breaks crawlers and jobs whose roles were never granted on the key |
AWS Glue jobs | A security configuration: S3 output, CloudWatch Logs, and job bookmarks | Yes — attach it to the job or crawler | That the job bookmark is separately encrypted and is derived sensitive data, since it can hold the maximum value of a source column |
Amazon EMR | An EMR security configuration: EMRFS, local disks, LUKS | Applied at cluster creation | That local disk and EMRFS encryption are separate settings, so “the cluster is encrypted” is an incomplete claim |
Kinesis, Amazon MSK, OpenSearch | Server-side encryption with a KMS key | Kinesis Data Streams: yes, on an existing stream. MSK and OpenSearch: at creation | That a stream is not encrypted by default, so an unencrypted stream carrying personal data is a real finding |
Key terms: AWS Glue Data Catalog encryption at rest, Glue connection password encryption, AWS Glue security configuration, Redshift cluster encryption, S3 Bucket Keys
Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.