On this page
An administrator’s read is a narrow result
Hypothetical situation: a platform administrator opens a table during a handover meeting and shows the expected data. The receiving analysts are told that access is ready. On their first working day, one cannot read the table, while another can see a dataset outside the agreed scope. The demonstration proved the administrator’s route worked. It did not test the intended audience.
Begin with a list of responsibilities rather than a list of privileged accounts. Who should read the dataset? Who maintains it? Who should be excluded? Which operation does each person need to perform? Those questions turn a broad access claim into a set of testable expectations.
This exercise concerns Unity Catalog table access and an operational review method. It does not attempt to cover every Databricks runtime, compute configuration or cloud integration. Keep the workspace, compute and identity conditions in the record so the result has a clear boundary.
Before correcting a failed case, capture the intended outcome with the data owner. That prevents a troubleshooting session from gradually widening the audience without an explicit decision. After the correction, repeat both the positive and negative cases. A fix that restores the analyst’s read while also admitting the excluded consumer has not met the original access requirement, even if the first complaint disappears.
Check the permission path
The Databricks-authored Unity Catalog paper published for SIGMOD Companion 2025 describes a concrete table-read requirement: SELECT on the table, USE SCHEMA on its parent schema and USE CATALOG on its catalog. This establishes the documented privilege model before the coverage date. It is not a complete deployment recipe or evidence that your workspace grants those privileges correctly.
For the selected dataset, record the catalog, schema and table. Have an authorised platform owner inspect the effective permissions and relevant group membership for each test identity. Avoid solving a missing-read problem by adding a broad privilege without checking the parent path and intended audience.
Use organisation-approved test identities or an approved impersonation procedure. Do not share passwords or borrow an administrator session to represent an analyst. The test needs to establish whose permissions were exercised. Keep service identities separate from interactive users, even when both access the same dataset.
Test permission and restriction together
Build the expected matrix before running queries. A reporting analyst may need to read a curated table but should not change it. A maintenance identity may need an approved write route without being an acceptable identity for an interactive report. Include a negative test against an approved non-sensitive fixture so a mistaken grant can be discovered without disclosing real restricted data.
Run the intended operation from the route the team will use. Record success, denial or an unexpected result along with the identity and object. If a test fails, distinguish a permission problem from a missing object, a compute issue or another environmental condition. A failed query is not automatically proof that a security boundary is correct.
The matrix is an editorial test aid. It does not introduce undocumented privileges, imply that ownership always behaves like an ordinary grant or claim that one check proves every downstream system is secure. Keep those conclusions within the evidence gathered.
| Identity | Operation | Expected outcome |
|---|---|---|
| Reporting analyst | Read the approved table | Allowed |
| Reporting analyst | Change the approved fixture | Denied unless explicitly authorised |
| Excluded consumer | Read a restricted fixture | Denied |
| Maintenance identity | Run its approved maintenance operation | Allowed only within agreed scope |
Retest the changes that affect access
Keep a named owner for the matrix and identify when it must be repeated. Group membership, object location, grants and the consuming route can change the access conclusion. Store only the evidence needed to reproduce the test; do not export restricted rows into a general project folder.
During handover, ask an analyst to explain what they can do and how to request a change. Ask the platform owner how a departing user or changed role will be handled. An access model is easier to operate when the receiving team understands both its permitted work and its escalation route.
For a team lab, provide a controlled fixture with one missing parent privilege and one unintended read grant. Participants should diagnose the two cases separately, propose the smallest justified correction and repeat the matrix. The exercise develops permission reasoning. It should end with a clearer access record, not a recommendation to make every user an administrator so the demonstration runs smoothly.
Sources & further reading (1)
Historical evidence checked . Review practices and hypothetical exercises are editorial recommendations, not product guarantees.
