A Contributor reports that a staging table used by the nightly ETL job no longer appears anywhere in the Warehouse's object list for their account, even though they can still see and query every other table. What is the most likely, and expected, cause?
Select an answer to reveal the explanation.
Short Explanation
This isn't a bug — it's the museum's back-of-house storeroom doing exactly what it's supposed to do. Object-level security was set up to make that one staging table invisible to that group, while every gallery table stays open as normal.
Full Explanation
This behavior is the expected, intended effect of object-level security: when a principal's access to a specific table object is denied, that table disappears from their visible object list entirely while every other table they're permitted to see remains unaffected — exactly what the Contributor is describing. Storage exhaustion would produce load or write failures, not a table selectively vanishing from one account's view while others presumably still see it. Row-level security filtering every row would still leave the table itself visible with zero rows returned on query, not make the table disappear from the object list altogether. Dynamic data masking changes column values inside a query result; it has no mechanism for hiding a table's existence or removing it from an object list. The correct diagnostic path is to check the Warehouse's object-level permissions for the staging table and confirm a DENY exists for the Contributor's security group — which, in this case, is a working control, not an incident to fix. An operational check: query the permission catalog views for that table and confirm the expected DENY entry is present.