A library system must hide patron email details from most staff screens and also stop branch clerks from seeing other branches’ patrons. Which combination meets both goals?
Select an answer to reveal the explanation.
Short Explanation
Masking frosts the email on the screen; RLS keeps each clerk inside their own branch’s patron rows—libraries usually need both layers, not just the deadbolt on the disk.
Full Explanation
Using Dynamic Data Masking on email columns together with Row-Level Security that filters by branch meets both library goals: hide patron email details from most staff screens and stop branch clerks from seeing other branches’ patrons. DDM obscures email presentation for roles without UNMASK, while RLS predicates constrain each clerk’s result sets to their branch’s patron rows. Layered together, the library gets attribute-level display privacy and row-level tenancy isolation on the same patron tables without publishing raw rows broadly.
Using only Transparent Data Encryption while granting SELECT on all patron tables to every clerk fails by concept: TDE does not mask emails or filter branches once clerks query inside the engine. Using only Always Encrypted while disabling branch filtering may protect email ciphertext from the engine, but it does not implement branch isolation for clerks who hold keys, and it is heavier than display masking when the requirement is screen hiding plus regional row scope. Publishing an unauthenticated GraphQL endpoint that returns full patron rows removes both controls and exposes library PII publicly.
Exam caveat: DDM and RLS solve orthogonal problems—presentation versus row filter—and are frequently combined in municipal privacy designs. Always Encrypted is for untrusted DBA/engine exposure scenarios; it is not the first tool merely to hide emails on staff screens. TDE remains useful at rest but never substitutes for either DDM or RLS.
Operational check: Apply a masking function on patron email, create an RLS policy predicated on branch assignment, and test three principals: a branch clerk (masked email, own branch only), a clerk from another branch (no rows), and a privileged privacy officer with UNMASK and citywide access (full emails, all branches, audited). Confirm GraphQL/API layers use authenticated, role-bound access. Review that db_owner or UNMASK is not granted casually to front-desk accounts.