How do you handle encryption at rest and in transit in the cloud?

Encryption is table stakes in the cloud, but candidates often overstate what it buys you. A good answer covers both states of data and is honest about the threat model.

In transit — protecting data on the wire

Data moving between clients, services, and regions can be read or modified by anyone on the path. TLS provides confidentiality and integrity for that traffic.

• Enforce TLS everywhere, including internal service-to-service calls — "it's inside the VPC" is not a guarantee against a compromised host or misrouted traffic.
• Reject plaintext explicitly (e.g. a storage policy denying requests where aws:SecureTransport is false), so a misconfigured client can't silently fall back.

At rest — protecting stored data

At-rest encryption protects data on disks, snapshots, and backups so that stolen or improperly decommissioned media is useless.

• Cloud services integrate with KMS using envelope encryption: KMS holds the master key, generates a per-object data key, and the data key encrypts the data. KMS key policies decide who may decrypt.
• Customer-managed keys (CMKs) give you control over rotation, access policy, and revocation; provider-managed keys are simpler but less controllable. Choose based on compliance needs.

The honest limitation

Here's the nuance interviewers probe: at-rest encryption does not stop an authorized request. When a valid IAM principal reads an object, the service decrypts it transparently. So an over-permissioned role or a public bucket policy leaks data despite encryption. Encryption defends against media theft and network sniffing — not against bad access control.

What interviewers look for

Distinguishing the two states and their distinct threats, knowing KMS envelope encryption and CMK vs managed keys, and stating that encryption complements — never replaces — IAM and policy controls.