An analyst has been granted read access to a ticketing table with dynamic data masking applied to the card-number column, but her queries still return the masked pattern instead of full values, even though her manager insists she needs to see real numbers for reconciliation. What is most likely missing?
Select an answer to reveal the explanation.
Short Explanation
Read access and seeing through the mask are two separate keys. Having permission to open the drawer doesn't automatically remove the tint on the glass — someone still has to hand her the specific pass that lets her see clean through it.
Full Explanation
Dynamic data masking is independent of ordinary table read permission: a principal can have full SELECT rights on a table and still see masked values on protected columns unless they additionally hold the UNMASK permission (or belong to a group explicitly exempted from the mask) for that column. The analyst's symptom — masked results despite valid table access — is the textbook signature of a missing UNMASK grant, not a broader access problem. Making her a Warehouse Admin would be a drastic overcorrection that grants far more than card-number visibility and isn't how masking exemptions are normally managed; the properly scoped fix is the UNMASK grant on that column alone. Switching the masking function from partial to full would make the situation worse for everyone else, not solve her specific visibility need, and doesn't address permissions at all. Row-level security controls which rows return, not whether visible rows show masked or real column values, so it wouldn't produce this particular symptom of full rows with a masked column. The operational fix is to grant UNMASK on the card-number column to her account or her security group, then re-run her query to confirm full values now appear.