The lock-lab app must equality-search on a hashed employee ID but must never support grouping on card numbers. Always Encrypted will protect both columns. What should you recommend?

Deterministic Always Encrypted produces the same ciphertext for the same plaintext, which enables equality comparisons, joins, and point lookups on columns such as employee ID. Randomized encryption produces different ciphertext for the same plaintext and is appropriate for values like card numbers that must not support search. Use deterministic for equality-search columns and randomized when search must be denied, and do not also apply dynamic data masking to those Always Encrypted columns. Using randomized encryption on the employee ID equality column breaks the search/join goal, while using deterministic on card numbers can leak equality patterns. Masking Always Encrypted columns is the wrong layering and does not improve joins. Using only deterministic encryption for every column so aggregates and GROUP BY work without enclaves overshares equality information and still will not unlock all operations the engine cannot perform on encrypted data without enclaves. Exam caveat: deterministic encryption has privacy trade-offs (equality inference); randomized is stronger confidentiality with fewer query operations—match the crypto mode to the query pattern, and consider enclaves when you need richer computation. Operational check: encrypt employee ID as deterministic and card number as randomized in a lab database, prove equality search works only on employee ID, prove card lookups by equality fail as designed, and ensure no DDM remains on those columns.