A team enabled dynamic data masking on the email column of a Microsoft Fabric Warehouse table and assumes this stops a particular analyst group from reading the real email addresses. During review, a member of that group reconstructs full addresses by writing a query with a WHERE clause that tests candidate values against the masked column. The team needs to genuinely prevent that group from obtaining the real values. Which action best closes this gap?
- AIncrease the complexity of the dynamic data masking function on the email column so the masked output reveals fewer characters to the analyst group.
- BAdd a row-level security predicate so the analyst group retrieves only rows whose email addresses are already considered non-sensitive.
- CGrant the analyst group the unmask permission on the table so the masking is applied consistently and the inference behaviour stops.
- DApply column-level security by denying the analyst group SELECT on the email column, so they cannot query or infer the real values at all. Correct
Why A is wrong: A stronger mask still leaves the underlying value queryable through predicates and inference, so the group can keep reconstructing addresses; masking changes display, not the access that enables the inference attack.
Why B is wrong: Row-level security limits which rows appear but still returns the real email values on the rows the group can see, so it does not protect the sensitive addresses that remain in scope for that group.
Why C is wrong: Granting the unmask permission would let the group read every real address outright, which is the opposite of the goal; it removes the protection rather than strengthening it.
Why D is correct: Denying SELECT on the email column removes the group's ability to reference it in queries, including WHERE-clause inference, so the real values are genuinely unreachable; masking alone never blocks access, only display.