An oral-history metadata table in a Fabric Warehouse includes a column with interview subjects' home addresses. Research analysts need full access to every other column in the table but must be completely blocked from ever retrieving values from the address column. What should the team configure?

Column-level security in a Fabric Warehouse is enforced with T-SQL GRANT/DENY statements scoped to a specific column, so a security principal can be denied SELECT on the address column while retaining full access to every other column in the same table — no masking, no partial value, just an outright block on that one column. Dynamic data masking is the wrong fit here because the requirement is complete denial, not an obscured-but-still-visible value; masking still returns a shaped result (like asterisks or a redacted pattern) rather than refusing the read. A OneLake data access role restricts access by folder or table, not by individual column within a table the group otherwise needs, so it can't carve out one column while leaving the rest open. A sensitivity label classifies and can trigger downstream protection (like encryption on export), but it doesn't itself enforce a query-time column block inside the Warehouse. Operationally, an engineer should run a test query as an analyst account selecting the address column directly and confirm it returns a permission error rather than any value, masked or otherwise.