A reviewer claims Transparent Data Encryption stops the lock-lab DBA from reading operator Social Security numbers with SELECT. Why is that claim wrong?
Select an answer to reveal the explanation.
Short Explanation
TDE is a lock on the disk platter, not a blindfold on the DBA. If you can query as an authorized user, you still see Social Security numbers in clear text—stolen drives are the nightmare TDE is built for.
Full Explanation
Transparent Data Encryption encrypts database data files, transaction logs, and backups at rest. Authorized principals who query through the engine still receive plaintext results; the threat model is stolen media, lost disks, and offline backup theft—not hiding columns from DBAs. Claiming TDE encrypts result sets for every principal including dbo confuses TDE with Always Encrypted or application-layer crypto. Saying TDE only protects temporary tables misunderstands scope: permanent user data in the data files is in scope. Equating TDE with Always Encrypted is wrong: Always Encrypted is client-side column encryption where the engine should not see plaintext for protected columns. Exam caveat: pair TDE with strong identity, auditing, and (where needed) Always Encrypted or masking—TDE alone does not satisfy “DBA must not see national IDs.” Operational check: demonstrate to auditors that TDE is enabled and backups are encrypted at rest, then separately show a privileged SELECT returning plaintext to explain why column controls are still on the roadmap for highly sensitive municipal identity fields. Training DBAs on that distinction prevents false confidence that TDE alone meets privacy mandates for citizen identifiers.