Databricks Unity Catalog Interview Questions: Privileges, External Locations, and Access Failures

Unity Catalog interview questions become easier when you identify the operation before naming a privilege. Reading a registered table, writing raw files, discovering metadata, and changing another user's grants are different requests. “The user has access” is too vague to explain why one succeeds and another fails.

Official scope: this guide uses current Databricks-managed Unity Catalog documentation for AWS and its Privilege Model 1.0. It is not a guide to the separate open-source Unity Catalog implementation or a prediction of Databricks hiring questions. The matrices and scenarios are original document-based exercises; they were not executed against a Databricks workspace.

Here, the objective is narrower: explain the missing condition, propose the smallest justified repair, and state what that repair does not establish.

Start with the exact access request

Before inspecting grants, write a sentence such as: “The analyst group wants to query retail.curated.orders from the reporting workspace.” That identifies an actor, an action, an object, and an execution context. A screenshot showing a table name does not establish any of those completely.

Ask whether the failure occurs while opening metadata, running SQL, creating a table, or accessing a storage URI. Capture the complete object name and error, then confirm the job's actual execution identity. A notebook author and a scheduled job's principal may not be the same actor in your scenario.

The securable-objects reference distinguishes catalogs, schemas, tables, volumes, credentials, and external locations. An external location is not simply another level below a table in the three-part name. Model the relevant objects explicitly before tracing permissions.

For the exercises below, assume compatible compute, valid storage access, and no additional policies, row filters, column masks, hidden group grants, or ownership privileges. In a real environment, those assumptions must be checked. The simplified answers are useful precisely because their boundaries are visible.

Why can SELECT alone fail?

Documented rule: an ordinary table read requires USE CATALOG on its catalog, USE SCHEMA on its schema, and SELECT on the table or an applicable inherited grant. The permissions model also separates discoverability through BROWSE from data access.

Original question: an analyst has SELECT on retail.curated.orders and USE CATALOG on retail, but no applicable USE SCHEMA. What would you request?

The narrow repair is usage of retail.curated, provided that scope is approved. Regranting SELECT does not address the identified gap. Granting broad access across the catalog would solve a larger problem than the one presented.

GRANT USE SCHEMA ON SCHEMA retail.curated TO `reporting_analysts`;

This statement is illustrative, not a command executed for this article. The person applying it must have authority to manage the relevant grant. Afterward, repeat the exact intended read using the affected principal rather than validating only with an administrator's session.

Explain the negative result too: schema usage does not independently authorize every table read. That matters when a stakeholder hears “access to the schema” and assumes all its data is now visible. A strong answer names the operation that became possible and the controls that remain necessary.

Solve a three-principal access matrix

Here is an original practice environment. landing_raw covers a raw-file path outside any registered table or volume. All work starts in an allowed workspace, and the location is writable. The grants shown are the complete effective grants for this exercise.

Actor and task	Complete grants
Analyst: query the orders table.	Catalog and schema: both usage privileges. Orders table: SELECT. Raw location: none.
Loader: write raw landing files.	Catalog and schema: both usage privileges. Orders table: none. Raw location: WRITE FILES only.
Steward: manage grants and inspect raw files.	Catalog and schema: both usage privileges. Orders table: MANAGE only. Raw location: READ FILES.

Before reading the answers, decide whether each principal can query the table and whether they can write to the raw path. Then explain which evidence you used instead of replying with a role stereotype such as “loaders can write.”

The analyst can perform the specified table read under these assumptions. Their table grant does not establish permission to write raw landing files. The loader cannot query the table from the listed grants, and the raw write is also missing a prerequisite. The steward can administer table privileges but has not been granted a table read; the location grant permits the exercise's raw read, not a raw write.

The privileges reference establishes two relevant details: WRITE FILES requires READ FILES on the same external location, and MANAGE does not itself provide all data privileges. A steward may be able to grant data access, including to themselves; that is a separate action and a reason to treat management rights seriously.

For rehearsal, change only one cell at a time. Add READ FILES to the loader and recompute the raw-write answer. Add SELECT to the steward and recompute the table-read answer. This tests your ability to reason from the effective permission set rather than memorize the first matrix.

Keep table access separate from raw-file access

An external location associates a storage path with a storage credential. Registered external tables provide a separate object through which data access can be governed. The SQL reference also shows that paths belonging to registered tables have their own access implications.

That is why the matrix deliberately uses an unregistered raw landing path. Do not generalize its answer into “READ FILES always bypasses every table permission” or “SELECT grants arbitrary access to the whole bucket.” Both statements erase the object and access path that the question depends on.

Original follow-up: an analyst needs a daily query result, while an ingestion service needs to place new files in the landing area. Would you give them identical permissions because the data ultimately resides in the same bucket?

Explain their different tasks. The analyst should receive the approved query interface and scope. The ingestion identity should receive the required write path and its prerequisites. If the organization uses volumes for file workloads, evaluate the corresponding volume permissions rather than automatically choosing direct path access.

Your design answer should identify the expected consumer and the boundary being exposed. A storage URL is not a substitute for an access contract. Ask whether the consumer needs records, files, or the ability to create new governed objects, and choose the interface accordingly.

Diagnose four permission failures

These scenarios are document-based exercises, not captured production errors. They add one condition at a time to the simplified matrix.

1. The table grant exists, but a container grant is missing

Use the analyst example above. Check the complete hierarchy and effective group grants before adding anything. The proposed repair should name the missing schema usage privilege, the approved principal, and the exact schema.

Your verification should include a positive check for the requested table and a negative check for an unrelated table that should remain inaccessible. This demonstrates that the repair met the requested scope rather than merely making the error disappear.

2. The loader has only WRITE FILES

The missing read prerequisite is the issue established by this packet. If direct raw-file writing is approved, request the paired privilege on the same location. Do not confuse that with granting table SELECT: the requested operation and securable object are different.

Before recommending the change, ask whether the intended path is genuinely the raw landing area. A copied URI pointing elsewhere would make an otherwise correct permission repair irrelevant. Your answer is conditional on the path matching the governed location.

3. The location is marked read-only

Now give the loader both file privileges, but mark the location read-only. Official behavior: the external-location management guide says read-only mode blocks writes despite underlying IAM or Unity Catalog write permissions. It also notes that changing this setting can take up to 60 minutes to reach all compute.

The remedy is a scope decision: use an approved writable destination or have the responsible owner review whether this location should be writable. Adding more grants does not remove the read-only setting. Do not weaken the intended boundary merely because a job expects a different one.

For verification, record the setting change time and test the intended operation after it has taken effect. A request immediately after a change is insufficient evidence of stable enforcement everywhere.

4. The operation runs from a different workspace

The loader now tries to create an external table from a development workspace, while the external location is isolated to production. Assume all ordinary creation and container privileges have already been satisfied.

The same official guide says location bindings are checked when a location privilege is exercised. It specifically distinguishes creation-time checks from an existing external table continuing to function after its location is later unbound. External-location binding is not an automatic revocation mechanism for all existing table access.

Use the approved workspace or review the isolation policy with its owner. Also inspect the catalog's workspace binding: catalog bindings provide a separate access boundary, including read-only versus read-write catalog access. Do not invent a read-only external-location binding; that is distinct from marking the location itself read-only.

Explain MANAGE and ALL PRIVILEGES without overclaiming

When asked about MANAGE, distinguish administering an object from reading its data. The current model has reduced usage requirements for management at container levels; data access still needs its own prerequisites. Avoid applying one simplified “always needs both usage grants” sentence to every management operation.

The current privilege reference excludes MANAGE, READ METADATA, EXTERNAL USE SCHEMA, and EXTERNAL USE LOCATION from ALL PRIVILEGES. Therefore, the word “all” should not end your reasoning. Identify the object type and the capability the caller actually needs.

Editorial preparation advice: if you do not remember an evolving privilege detail, state the broad distinction and identify the reference you would check. That is more defensible than inventing a grant because it sounds related. Your interviewer can evaluate how you constrain uncertainty as well as what you recall.

Present a repair that another engineer can verify

Use the privilege-management documentation to inspect grants through the appropriate interface. The visibility of grant information depends on the inspecting principal; an incomplete view should not be mistaken for proof that no other grant exists.

SHOW GRANTS ON CATALOG retail;
SHOW GRANTS ON SCHEMA retail.curated;
SHOW GRANTS ON TABLE retail.curated.orders;
SHOW GRANTS ON EXTERNAL LOCATION landing_raw;

These illustrative statements guide evidence collection. Record the affected identity, effective group membership, workspace, object, attempted operation, observed error, and proposed change. Keep credentials and sensitive data out of the troubleshooting note.

A useful handoff reads: “The analyst's table read lacks schema usage. I propose that grant on this schema only. After approval, test the requested query as the analyst and confirm an unrelated table remains denied.” It separates diagnosis, authorization to change access, and verification.

If the operation still fails, return to the assumptions. Check policies, workspace restrictions, storage access, and the actual execution identity before broadening privileges. A correct first repair may expose another independent failure; it does not justify treating every remaining error as insufficient administrator access.

Sources and Further Reading

• Unity Catalog permissions model: usage, management, and inheritance.
• Unity Catalog privileges reference: exact privilege dependencies and exclusions.
• Securable objects reference: object boundaries.
• External locations SQL reference: storage paths and governed access.
• Manage external locations: read-only settings and workspace isolation.
• Workspace-catalog binding: catalog access by workspace.
• Manage privileges: inspection and grant operations.

Documentation checked September 10, 2026. All exercise outcomes are conditional document-based reasoning, not live cloud-test results.