A company stores sensitive customer fields in a managed cloud database. The security policy says neither the cloud provider nor the company's own DBAs may ever see these fields in plaintext. Which approach meets this requirement?
Select an answer to reveal the explanation.
Short Explanation
If you lock the box before you hand it over, the courier and the warehouse staff can't peek inside. That's client-side encryption: the data's already ciphertext when it lands in the database. TDE and TLS sound strong, but the database itself still sees plaintext, so anyone who runs the database can too.
Full Explanation
With client-side encryption, the application or its database driver encrypts sensitive values before sending them, using keys that the database server never holds. The database stores and returns only ciphertext, so administrators with full access to the server, backups or the provider's infrastructure see unreadable values; only clients with access to the keys can decrypt. Transparent data encryption protects files at rest, but the engine decrypts pages in memory to process queries, so anyone with sufficient database privileges, and potentially the provider, can read plaintext through normal queries. TLS protects the network hop between application and database; once data arrives, it is decrypted and stored according to the server's own settings. Role-based access control can deny SELECT to DBAs, but administrators can usually alter permissions, and access control does nothing against the provider operating the platform. Exam caveat: client-side encryption limits what the database can do with the data; searching, sorting or indexing encrypted fields is restricted, and the keys must be managed carefully outside the database. Operational check: query the protected columns directly using a DBA account and confirm only ciphertext is returned, then confirm the application decrypts correctly with its authorized keys.