Lesson 23 of 30

KMS & Encryption Fundamentals

Q: Explain how S3 encrypts an object using SSE-KMS with a customer-managed key, and why it doesn't just encrypt the whole object directly with the KMS key.

A strong answer covers: Describes envelope encryption: a locally generated data key encrypts the actual object, and only that data key is wrapped by the KMS key; Explains that raw KMS key material never leaves KMS's boundary, even during decrypt; Names the practical reason this scales — KMS only ever handles a small data key, not bulk object data, regardless of object size; Mentions that a customer-managed key has its own key policy, evaluated independently of IAM policies on the identity side.

Most AWS services don't ask you to write a single line of cryptography to encrypt data at rest — they ask you to point at a KMS key. Understanding what that key actually does is the difference between checking a box and actually reasoning about it.

11 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

Question 1 of 3

An S3 object with SSE-KMS enabled is uploaded. Does KMS encrypt the object's actual bytes directly with the KMS key itself?

No — a locally generated data key encrypts the object, and only that data key is wrapped by the KMS keyYes — the KMS key directly encrypts every byte of the object each time it's uploadedYes, but only for objects smaller than a certain size — larger objects use a different mechanism

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on KMS & Encryption Fundamentals

What interviewers actually ask about this, and what a strong answer has to cover.

Explain how S3 encrypts an object using SSE-KMS with a customer-managed key, and why it doesn't just encrypt the whole object directly with the KMS key.

A strong answer covers

Describes envelope encryption: a locally generated data key encrypts the actual object, and only that data key is wrapped by the KMS key
Explains that raw KMS key material never leaves KMS's boundary, even during decrypt
Names the practical reason this scales — KMS only ever handles a small data key, not bulk object data, regardless of object size
Mentions that a customer-managed key has its own key policy, evaluated independently of IAM policies on the identity side

Likely follow-ups

A role has a full kms:Decrypt IAM permission but a decrypt call still fails against a specific customer-managed key. What else would you check?
What's actually different about an AWS-managed key versus a customer-managed key, beyond who created it?

Practice these with the AI interviewer →

The plain-language idea

KMS (Key Management Service) manages the cryptographic keys most AWS services use to encrypt data at rest — S3, RDS, Secrets Manager, EBS, and others mostly just reference a KMS key and get encryption without the raw key material ever entering your own code. Two kinds of key cover almost every real case:

AWS-managed keys — created and rotated automatically by AWS, one per service per account, zero configuration. You get encryption at rest with no setup, but no control over the key's access policy beyond the service's own IAM permissions.
Customer-managed keys (CMKs) — created and controlled by you in KMS: you own the key policy (who can use and administer it), can enable or disable the key, configure rotation, and audit every use via CloudTrail. This is the kind interviewers usually mean when they ask "how does encryption at rest actually work here."

The mechanism underneath both is envelope encryption: KMS doesn't encrypt your (often large) actual data with the KMS key directly. Instead, a small, unique data key is generated, your data is encrypted locally with that data key, and only the small data key itself gets encrypted ("wrapped") by the KMS key. The wrapped data key is stored alongside the encrypted data. Decrypting later means sending the wrapped data key to KMS to unwrap it, then using the now-plaintext data key locally to decrypt the actual data — the raw KMS key material never has to leave KMS to encrypt or decrypt anything, no matter how much data is involved.

See it in a real thing: an S3 object encrypted with SSE-KMS

An S3 bucket with SSE-KMS (server-side encryption using a KMS key) enabled, referencing a customer-managed key, does roughly this on every upload: generate a fresh data key, encrypt the object with it, encrypt that data key with the referenced KMS key, and store the wrapped data key alongside the object. On download, S3 sends the wrapped data key to KMS to unwrap it, then decrypts the object locally with the now-plaintext data key.

What people usually miss

Watch out

Raw key material never leaves KMS, by design. Even a "decrypt" call sends ciphertext to KMS and gets plaintext back — for envelope encryption specifically, only the small wrapped data key is sent to KMS, never the bulk data. This is why a KMS key can't be "exported": that's not a missing feature, it's the actual security guarantee.
A key policy and an IAM policy are two separate access-control layers that both have to agree, the same relationship an S3 bucket policy has with IAM permissions — an IAM role can have full kms:Decrypt permission and still be blocked if the key's own key policy doesn't grant that role access, and vice versa.
AWS-managed keys can't have their key policy edited or be shared cross-account. Reaching for a customer-managed key is what unlocks fine-grained access control and cross-account key sharing — it isn't just a nicer-to-have version of the same thing, it's a different capability tier.
Encryption at rest via KMS says nothing about data in transit or data already decrypted in application memory. It protects data sitting on disk specifically — a network interception or a compromised running process that reads decrypted data in memory is a genuinely different threat KMS-at-rest encryption doesn't address.

Why this matters in interviews

"How does S3 actually encrypt an object with SSE-KMS, and why doesn't it just encrypt the whole object directly with the KMS key?" tests whether a candidate understands envelope encryption as the real mechanism — a local data key doing the bulk work, only that small key ever touching KMS — rather than a vague "AWS encrypts it," which doesn't explain why raw key material can't leave KMS or how this scales to large objects.