10 Unity Catalog Questions Every $180k Databricks Interview Asks
The answers that pass the $180k governance screen
Every Databricks team treats Unity Catalog as the thing the platform admin set up once and nobody thinks about again. The teams hiring at $180k+ treat it as a senior screen, and they have started failing candidates who can only talk about it as a permissions checkbox.
Three years ago, governance was a specialist topic. You could reach senior as a pure pipeline engineer and never explain how access actually resolves. That window has closed. Lakehouse architectures now route every table, model, and dashboard through one catalog layer, and the interviewer wants to know if you understand what happens when a SELECT hits it.
Here is the pattern I have watched play out in mock interviews and debriefs with colleagues who hire. The mid-level candidate describes Unity Catalog as “the place you set permissions.” The senior candidate describes a privilege-resolution engine with a securable hierarchy, traversal grants, ownership semantics, and a credential broker sitting between users and raw cloud storage. Same feature. Two completely different depths. The second one gets the offer.
Below are the ten questions that separate those two answers. The first two get the full breakdown so you can see exactly where the depth gap opens. The rest come rapid-fire, because once you have the pattern, what you need is coverage, not repetition.
Question 1: “What changed when Databricks moved from the two-level namespace to the three-level namespace?”
The junior answer (rejected): “Unity Catalog adds a catalog on top, so now it’s catalog.schema.table instead of just schema.table. It’s better for organizing tables.”
Why this fails: It describes the syntax change and stops. It treats the third level as cosmetic naming. The interviewer learns nothing about whether you understand the governance model the third level exists to enable.
The senior answer (offer-winning): “The legacy Hive metastore was scoped to a single workspace, so the same schema.table name in two workspaces pointed at two different, unrelated objects. There was no shared identity, no central access model, and no way to govern across workspaces. The three-level namespace exists because the catalog became the unit of isolation and sharing at the account level, not the workspace level. A catalog can be bound to specific workspaces or shared across all of them, which is how you separate prod from dev or one business unit from another while keeping a single source of truth. The namespace change is the visible surface of a much bigger shift: governance moved from per-workspace to per-account, identities are now managed centrally, and the same object has one canonical name everywhere.”
The senior answer reframes a syntax question as an architecture question. That is the entire game with Unity Catalog.
Key concepts to mention:
Legacy Hive metastore is workspace-scoped; Unity Catalog is account-scoped
The catalog is the top-level securable and the unit of isolation and sharing
Catalog-to-workspace binding controls which workspaces see which catalogs
Centralized identity through account-level users and groups
One canonical fully-qualified name across the whole account
What interviewers are testing: Whether you understand that Unity Catalog is an account-level governance shift, not a renaming convention. This question filters out everyone who only learned the new syntax.
Question 2: “Walk me through how a query gets authorized in Unity Catalog.”
The junior answer (rejected): “If the user has been granted access to the table, the query runs. If not, it gets denied.”
Why this fails: It collapses a multi-level resolution process into a single yes/no check. It misses traversal privileges entirely, which is the single most common reason real queries fail with a confusing permission error.
The senior answer (offer-winning): “Authorization walks a securable hierarchy: metastore, then catalog, then schema, then table or view. To read a table, the user needs SELECT on the table, but they also need USE CATALOG on the parent catalog and USE SCHEMA on the parent schema. Those USE grants are traversal privileges. They do not grant data access by themselves, they grant the right to navigate into a container. This is why a user with SELECT on a table still gets an access error if nobody granted them USE on the path above it. Privileges also inherit downward: a SELECT granted at the catalog level flows to every schema and table inside it, which is how you set broad read access once instead of table by table. Ownership sits on top of all of this. The owner of a securable implicitly has full control over it and can grant privileges on it, regardless of explicit grants.”
Key concepts to mention:
Securable hierarchy: metastore to catalog to schema to table
USE CATALOGandUSE SCHEMAare traversal grants, not data grantsPrivilege inheritance flows downward through the hierarchy
Owner has implicit full control and grant authority over a securable
The “I have SELECT but still get denied” failure traces to a missing
USE
What interviewers are testing: Whether you have actually debugged a permissions problem in production. The traversal-grant detail is the tell. Candidates who have only read the docs say “grant SELECT.” Candidates who have fixed a real ticket know the error was a missing USE SCHEMA.
The first two questions show the shape of every Unity Catalog answer that lands: name the mechanism, explain the model underneath it, and connect it to a production failure mode. The remaining eight follow the same standard. Here they are with the senior answer and the hidden evaluation criteria, tightened to the parts that actually move an interview.
Questions 3 through 10: The Rapid-Fire Round
Question 3: “What is the difference between a managed table and an external table in Unity Catalog, and why does it matter?”
Senior answer: Managed tables have their data lifecycle owned by Unity Catalog. They live in a managed storage location defined at the metastore, catalog, or schema level, and dropping the table deletes the underlying data. External tables register data that already lives in a cloud path you control through an external location; dropping the table removes the metadata but leaves the files untouched. The decision matters for governed lifecycle and cost cleanup: managed tables let Unity Catalog handle storage layout and automatic maintenance, while external tables are for data shared with systems outside Databricks or migrated in place.
What interviewers are testing: Whether you understand data ownership and the consequence of a DROP, which is the kind of thing that has caused real incidents.
Question 4: “How does Unity Catalog hand out cloud storage access without giving anyone the keys?”
