A building department stores permit PDFs in Amazon S3 and uploads them from browsers over HTTPS. Staff ask how encryption at rest differs from encryption in transit for those permits. Which statement is accurate?
Select an answer to reveal the explanation.
Short Explanation
Leave the finished permit binder in a locked vault overnight — that is at rest. Carry the same binder across town in a locked courier pouch — that is in transit. HTTPS (TLS) covers the courier ride; S3 encryption covers the vault. Mixing those up is a classic exam trap.
Full Explanation
Encryption at rest protects stored permit objects on disk (or equivalent durable storage media), while TLS during upload protects the data while it travels across the network. Leave the finished permit binder in a locked vault overnight — that is at rest. Carry the same binder across town in a locked courier pouch — that is in transit. HTTPS (TLS) covers the courier ride; S3 server-side encryption (or similar at-rest controls) covers the vault. It is incorrect that TLS for the upload encrypts objects on S3 disks so separate at-rest encryption is never needed. It is also incorrect to swap the definitions so at-rest protects data moving across the network while TLS only protects idle disk blocks. Claiming S3 server-side encryption and HTTPS solve the same risk, making separate names marketing only, collapses two different threat moments. Distractors fail by merging or swapping rest versus transit protections. Exam caveat: many architectures need both controls for sensitive municipal data; one does not universally obsolete the other. Operational check: require TLS for citizen uploads to the permits bucket or API, enable at-rest encryption on the bucket and any downstream databases, and verify both settings in architecture review checklists before go-live.