Highly sensitive case files must be encrypted in the application before PutObject so AWS never sees plaintext, while ordinary park-photo buckets can use SSE-S3 or SSE-KMS. What contrast should developers apply?
Select an answer to reveal the explanation.
Short Explanation
Client-side encryption locks the briefcase before it leaves city hall—AWS stores ciphertext only. SSE locks it in the AWS vault after upload. Pick client-side when policy says the cloud must never see plaintext.
Full Explanation
Highly sensitive case files that must never appear as plaintext to AWS should use client-side encryption before PutObject: the application encrypts locally (often with a CMK via encryption SDKs) and uploads ciphertext. Ordinary park-photo buckets can rely on SSE-S3 or SSE-KMS where AWS performs server-side encryption of objects it receives as plaintext from the app. Choose client-side when the threat model forbids AWS seeing plaintext; choose SSE for simpler ordinary data.
Client-side and server-side encryption are not identical. SSE encrypts on the service after upload, not in the client before upload. Disabling all encryption because client-side crypto is “unsupported with S3” is false—S3 stores whatever bytes you put, including client-encrypted payloads.
Exam caveat: client-side encryption shifts key and envelope management onto the app—operational complexity is the trade for stronger confidentiality against cloud-side plaintext exposure. Operational check: upload a client-encrypted case file and confirm GetObject without client keys yields ciphertext; upload a park photo with SSE-KMS and confirm AWS console/SSE headers show server-side encryption while the app did not pre-encrypt.