Lock-operator national IDs and card numbers must stay hidden from DBAs and from the SQL engine itself, and TDE is already enabled. What should you recommend?
Select an answer to reveal the explanation.
Short Explanation
When even the DBA and the engine shouldn’t see the real national ID, that’s Always Encrypted territory. Keep TDE for the files; add Always Encrypted for the columns that must stay client-side secrets.
Full Explanation
When national IDs and similar fields must remain confidential even from DBAs and from the database engine in plaintext, recommend Always Encrypted—or Always Encrypted with secure enclaves when you need richer in-engine operations on encrypted data. Keep TDE for at-rest file and backup protection; add Always Encrypted for those highly sensitive columns so client drivers (and authorized enclaves) perform encryption and decryption with keys the SQL service does not silently hold for arbitrary server-side disclosure. Disabling TDE and relying on NSG rules only addresses network paths, not column confidentiality inside the database. Dynamic data masking alone does not prevent privileged roles from seeing plaintext and is not encryption. Storing national IDs in clear text and granting db_owner to external auditors maximizes exposure. Exam caveat: Always Encrypted requires application and driver support, careful key management, and choices between deterministic and randomized encryption; enclaves change query capability but add attestation and configuration complexity. Operational check: encrypt a pilot column in a non-production water-services database, validate the app can read/write with the column master key available, confirm a DBA session without the key cannot see plaintext, and document key rotation ownership before production.