A county policy requires highly sensitive case files to be encrypted on the client before any upload to Amazon S3, so plaintext never reaches S3 unencrypted even prior to server-side encryption. Which approach correctly distinguishes that requirement?
Select an answer to reveal the explanation.
Short Explanation
Client-side encryption is locking the briefcase before it enters the courthouse mailroom—S3 only ever sees ciphertext. SSE is the mailroom’s own vault; sometimes policy still wants the briefcase locked first.
Full Explanation
When county policy requires highly sensitive case files to be encrypted on the client before any upload to Amazon S3—so plaintext never reaches S3 even prior to server-side encryption—the correct approach is explicit client-side encryption before PutObject. The application or approved client encrypts each file under keys the county controls, and only ciphertext is transmitted and stored. That differs conceptually from relying solely on server-side encryption (SSE-S3/SSE-KMS), where S3 receives plaintext over TLS and then encrypts within AWS. Policy that demands "briefcase locked before the mailroom" is selecting client-side encryption.
Using only SSE-S3 and asserting it is identical to client-side encryption in every policy regime fails the distinction the question tests—SSE protects at rest inside AWS after receipt; it does not keep plaintext off the S3 API boundary. Uploading plaintext and enabling versioning fails confidentiality; versioning is not encryption. Disabling all encryption and marking objects with a confidential tag fails protection—labels are not ciphertext.
Exam caveat: client-side encryption shifts key management and searchable metadata complexity to the client; many designs combine TLS in transit, client-side encryption for ultra-sensitive objects, and SSE-KMS as defense in depth—know which control the scenario is asking for. Operational check: capture a PutObject of a test case file and confirm the stored object bytes are not plaintext readable with ordinary GetObject without the client key material, and document key escrow for lawful access.