Create and Organize Objects in Unity Catalog

Address every object as catalog.schema.object

A production table in Unity Catalog has a name like prod.sales.orders, and that same three-part name identifies it from SQL, Python, or any BI tool attached to the workspace. Every governed object follows this three-level namespace, catalog.schema.object, which replaces the legacy two-level hive_metastore.schema.table layout. The metastore is the top-level container for a region; a catalog is the first level you create inside it; a schema (also called a database) is the second level; and the object itself, a table, view, volume, function, or model, is the third (Unity Catalog object model^[1]). The figure below shows the full hierarchy from the metastore down to the object level.

The catalog is not just an organizational folder. It is the primary unit of data isolation in Unity Catalog, and schemas add a finer layer of organization beneath it (Unity Catalog best practices^[2]). Because isolation lives at the catalog level, the common convention is one catalog per environment, for example dev, test, and prod. Separating environments only by schema inside a single shared catalog is the misread to avoid: it organizes the data but leaves every environment inside the same isolation boundary, so a grant on the catalog reaches all of them. Put each environment in its own catalog instead.

So the three-part name does two jobs at once: it addresses the object, and its first part names the isolation boundary that any grant on it reaches. Get the catalog boundary right and the two levels below it are organization rather than security.

The Unity Catalog three-level namespace: metastore, catalog, schema, then objects. Source: Azure Databricks Unity Catalog object model.

Bind a catalog to specific workspaces

When data and its processing environment share the same isolation requirement, you can go further and bind a catalog to specific workspaces. Workspace-catalog binding restricts a catalog so only the workspaces you assign can reach it; access from an unbound workspace is denied even for a user who holds an explicit SELECT grant on a table inside it (Workspace-catalog binding^[3]). That is how you keep a prod catalog reachable only from production workspaces.

Binding narrows reach; it never widens it. That is the trap worth rehearsing: a user can hold a valid SELECT grant and still be refused, because the workspace they queried from was never bound to the catalog. When a question pairs a correct-looking grant with a denied query, check the binding before you re-read the grant.

Create catalogs and schemas, and pin their storage

Two CREATE statements stand up the containers, and each carries a privilege gate and a storage decision. Start at the top: CREATE CATALOG makes a top-level container inside the metastore, and only a metastore admin or a principal (a user, an account group, or a service principal) granted the CREATE CATALOG privilege on the metastore can run it (Create catalogs^[4]). A frequent slip is expecting CREATE CATALOG to give you a place to put tables directly; it does not. A catalog holds schemas, so a table needs a schema first, created with the two-level name CREATE SCHEMA catalog.schema (Create schemas^[5]). A schema cannot be a top-level object. Whoever runs the CREATE statement becomes the object's first owner, so Databricks recommends reassigning production catalogs and schemas to a group rather than leaving an individual as owner.

The storage decision is where a Hive-metastore habit trips people up. In Unity Catalog you set a schema's managed storage with the MANAGED LOCATION clause, not LOCATION. LOCATION is the legacy Hive-metastore syntax; on a Unity Catalog schema it is rejected, and MANAGED LOCATION is the supported form (Create schemas^[5]). Setting a MANAGED LOCATION requires the CREATE MANAGED STORAGE privilege on the external location (the Unity Catalog object that registers a cloud storage path) that covers the path. Omit the clause and the object inherits managed storage from the level above: managed storage resolves at the lowest level that sets it, the schema first, then the catalog, then the metastore (Managed storage best practices^[2]).

Create a catalog, then a schema inside it

This pair creates a prod catalog and a sales schema, each with its own managed storage; the bracketed keyword is optional and other clauses are omitted:

CREATE CATALOG IF NOT EXISTS prod
  MANAGED LOCATION 'abfss://managed@company.dfs.core.windows.net/prod';
-- ...
CREATE SCHEMA IF NOT EXISTS prod.sales
  MANAGED LOCATION 'abfss://managed@company.dfs.core.windows.net/prod/sales';

Each MANAGED LOCATION path must sit under a Unity Catalog external location you hold CREATE MANAGED STORAGE on. Drop the clause and that object inherits managed storage from its parent instead.

Managed vs external: who owns the files and the drop

One distinction decides who owns your data files and what a DROP destroys, and it applies the same way to tables and to volumes: managed versus external. In a managed object, Unity Catalog owns both the governance and the underlying files, which live in managed storage. In an external object, Unity Catalog governs access to the metadata, but the files stay in a cloud location you manage (Managed vs external assets^[2]).

For tables, a managed table is the default and recommended type. It stores rows in the Delta Lake format unless you request USING iceberg, and you can create one empty, with CREATE TABLE AS SELECT (CTAS), or with CREATE OR REPLACE TABLE (Managed tables^[6]). Dropping a managed table deletes both the metadata and the data files; Unity Catalog keeps them recoverable with UNDROP for a default of seven days, then removes them from cloud storage. An external table is created with a LOCATION clause pointing at a path under a Unity Catalog external location, and DROP TABLE removes only the metadata and leaves the files untouched (External tables^[7]). That difference is the exam's favorite table trap: if the files must survive the drop, the answer is an external table.

Volumes extend the same model to non-tabular data. A volume is a Unity Catalog object under a schema that governs files of any format, such as images, CSVs, and model artifacts, reached through the path /Volumes/catalog/schema/volume (Volumes^[8]). A managed volume stores its files in the schema's managed storage; an external volume, created with CREATE EXTERNAL VOLUME ... LOCATION, registers an existing path under an external location (Create volumes^[9]). The figure groups the four objects by the only question that matters at drop time. The drop rule mirrors tables exactly: dropping a managed volume marks its files for deletion, while dropping an external volume leaves them in place.

Managed objects: Unity Catalog owns the files, so DROP deletes them; external objects keep their files. Source: Azure Databricks tables and volumes docs.

Views and materialized views

A view and a materialized view read almost the same in SQL, but one stores data and one does not, and that single fact drives every question about them. A standard view is a read-only object that saves the text of a SELECT query; creating it writes no data, and only the query text is registered to the schema (Views^[10]). Each time you read the view, Unity Catalog re-runs its query against the base tables, so the results are always current, and the view can restrict or reshape the columns it exposes without copying anything.

A materialized view precomputes and stores its results in an underlying managed table, then keeps them up to date as the source tables change (Views^[10]). When you create one, Unity Catalog automatically provisions a serverless pipeline to build and refresh it, billed as serverless Lakeflow Spark Declarative Pipelines usage; the refresh runs incrementally, merging only changed rows when the query allows, and falls back to a full recompute when it cannot (Standalone materialized views^[11]). You refresh it on a schedule or on update. The trade the exam probes: a materialized view spends storage and a scheduled refresh to make repeated reads fast, while a standard view spends nothing and recomputes on every read. So a materialized view stores data and must be refreshed; a standard view does neither.

Precompute a daily aggregate as a materialized view

This materialized view stores a per-day sales total so a dashboard reads it instantly; the refresh schedule and other options are omitted:

CREATE OR REPLACE MATERIALIZED VIEW prod.sales.daily_totals AS
SELECT date, sum(amount) AS total
FROM prod.sales.orders
GROUP BY date;
-- ...

Because daily_totals is materialized, the sum is computed once per refresh and stored, not recomputed on every dashboard load.

Query external systems in place with federation

Suppose an operational PostgreSQL database holds live order status, and an analyst needs to join it against lakehouse tables for a quick report without waiting for an ingestion pipeline to copy it in. Lakehouse Federation is the Azure Databricks feature for exactly this: governed, read-only access to an external system that you query in place (Lakehouse Federation^[12]).

It takes two objects, created in order. First a connection, a Unity Catalog securable that stores the source's host, JDBC URL, and credentials. Then a foreign catalog, created from that connection, which mirrors the external database's schemas and tables as Unity Catalog objects so they appear alongside your other catalogs (Lakehouse Federation^[12]). Once you grant privileges on the foreign catalog, queries against it are pushed down to the source and run in place; no data is copied into Unity Catalog managed storage. The figure traces the connection, the foreign catalog, and the in-place query. PostgreSQL is one of many supported sources here, alongside MySQL, SQL Server, Oracle, Snowflake, Amazon Redshift, Azure Synapse, Google BigQuery, and other Databricks workspaces.

The contrast to hold onto: only a foreign catalog queries the source in place. An ingestion pipeline (Lakeflow Connect, Auto Loader, or COPY INTO) or a managed table built from the source would copy the data into Databricks storage instead. When higher data volumes and lower latency matter more than avoiding a copy, Databricks actually recommends ingesting with Lakeflow Connect over federating.

Lakehouse Federation: a connection and foreign catalog let queries run in place against the source with no copy. Source: Azure Databricks query federation docs.

Self-service discovery with AI/BI Genie

Business users often need an answer, not a query editor. An AI/BI Genie Agent (formerly called a Genie space) is a domain-specific, natural-language interface where a user asks a question in plain English and Genie returns the generated SQL, a results table, and a visualization (Genie^[13]). It runs over a curated set of Unity Catalog tables that a data analyst registers to the agent, which turns ad hoc data discovery into self-service without anyone writing SQL.

Accuracy comes from curation, not magic. The analyst who builds the agent supplies general instructions in plain language, example SQL queries, SQL expressions that encode business semantics, and verified answers to trusted questions; together these steer how Genie interprets domain terms and business logic (Tune Genie Agent quality^[14]). A vague metric like active customer becomes reliable only once an instruction or example pins down what it means.

One boundary is worth stating plainly, because it is a natural misread. Genie answers from the curated tables it was given plus those instructions, and access is still governed by the querying user's Unity Catalog permissions; it does not roam the whole metastore looking for data (Genie Agents concepts^[15]). Widening what Genie can answer means adding tables and instructions to the agent, not granting it blanket access.

Exam-pattern recognition

Most questions on creating and organizing Unity Catalog objects reduce to picking the right object or clause under a stated constraint. Read the constraint in the stem, then match it.

Isolate production data from development: create a separate catalog per environment, and bind it to the production workspaces if the environment itself must be restricted. The catalog is the isolation unit; separating environments by schema inside one catalog does not isolate them (best practices^[2]).
Set a schema's managed storage: use MANAGED LOCATION. LOCATION is Hive-metastore syntax and is rejected on a Unity Catalog schema (create schemas^[5]).
The files must survive a drop: choose an external table or external volume, defined with LOCATION. A managed DROP deletes the underlying files (managed tables^[6]).
Speed up an expensive, repeated query: a materialized view precomputes and stores results and refreshes them; a standard view recomputes on every read (materialized views^[11]).
Query an external database without copying it: create a connection, then a foreign catalog, and query in place. An ingestion pipeline or managed table would copy the data (Lakehouse Federation^[12]).
Govern images, CSVs, or model artifacts: register a volume and reach files at /Volumes/catalog/schema/volume (volumes^[8]).
CREATE CATALOG versus CREATE SCHEMA: CREATE CATALOG builds a top-level container; a table needs a schema created as CREATE SCHEMA catalog.schema (create catalogs^[4]).
Self-service natural-language questions for business users: an AI/BI Genie Agent over a curated set of Unity Catalog tables, steered by instructions and examples (Genie^[13]).

Managed vs external tables and volumes: storage and DROP

Object	Where data lives	Created with	On DROP
Managed table	Catalog or schema managed storage	CREATE TABLE (Delta by default) or CTAS	Deletes metadata and data files
External table	A path under a Unity Catalog external location	CREATE TABLE ... LOCATION	Deletes metadata only; files remain
Managed volume	Schema managed storage	CREATE VOLUME	Marks the volume's files for deletion
External volume	A path under a Unity Catalog external location	CREATE EXTERNAL VOLUME ... LOCATION	Removes the volume; files remain

Decision tree

Cheat sheet

Sharp facts the exam loves — give these one last read before exam day.

Cheat sheet

Sharp facts the exam loves — scan these before test day.

Unity Catalog addresses data as catalog.schema.object

Unity Catalog organizes every data object in a three-level namespace of catalog.schema.object (tables, views, volumes, functions, and models), replacing the legacy two-level hive_metastore.schema.table layout.

5 questions test this

Use a separate catalog per environment for data isolation

The catalog is the primary unit of data isolation in Unity Catalog, so a common naming convention creates a distinct catalog per environment (for example dev, test, and prod) to segregate data and permissions.

Trap Separating environments only by schema inside one shared catalog weakens the isolation boundary.

6 questions test this

Bind a catalog to specific workspaces to restrict its access

Workspace-catalog binding restricts a catalog so it is accessible only from designated workspaces, enforcing environment isolation and controlled external sharing across a metastore shared by several workspaces.

5 questions test this

CREATE CATALOG makes a top-level container in the metastore

CREATE CATALOG creates the top-level container within the metastore; an optional MANAGED LOCATION sets where its managed tables and volumes store data, otherwise they inherit managed storage from the metastore.

Trap CREATE CATALOG builds a catalog, not a schema; a contained schema needs CREATE SCHEMA catalog.schema.

9 questions test this

Creating a catalog requires the CREATE CATALOG metastore privilege

Only a metastore admin or a principal granted the CREATE CATALOG privilege on the metastore can create a catalog, and the creator becomes its owner with full control over the new object.

Set a schema's storage with MANAGED LOCATION, not LOCATION, in Unity Catalog

CREATE SCHEMA catalog.schema MANAGED LOCATION '' sets a schema's managed storage in Unity Catalog; the LOCATION clause is a Hive-metastore-only syntax and is rejected for Unity Catalog schemas.

Trap LOCATION is not supported for a Unity Catalog schema; use MANAGED LOCATION instead.

6 questions test this

A schema is created two-level as catalog.schema

A schema (database) groups tables, views, and volumes and must be created inside a catalog with the two-level name catalog.schema; it cannot be created as a top-level object.

7 questions test this

MANAGED LOCATION requires CREATE MANAGED STORAGE on an external location

Setting a schema's MANAGED LOCATION requires the CREATE MANAGED STORAGE privilege on the external location that covers the path; without an explicit managed location the schema inherits managed storage from its catalog or the metastore.

Volumes are Unity Catalog objects that govern non-tabular files

A volume is a Unity Catalog object under a schema that governs access to non-tabular data such as images, CSV files, and model artifacts, accessed through the path /Volumes/catalog/schema/volume.

8 questions test this

Managed volumes use Unity Catalog storage; external volumes point at a location

A managed volume stores its files in the schema's managed storage and is fully lifecycle-managed by Unity Catalog, whereas an external volume registers an existing path under an external location for data that Databricks does not own.

Trap Dropping a managed volume deletes its files; dropping an external volume leaves the files in place.

5 questions test this

A view is a stored read-only query that materializes no data

A view is a saved SELECT query that is evaluated each time it is read; it stores no data of its own and can restrict or reshape the columns exposed from its base tables.

17 questions test this

A materialized view stores precomputed results refreshed incrementally

A materialized view precomputes and stores query results and refreshes them incrementally through a Lakeflow declarative pipeline on serverless compute, speeding repeated reads at the cost of storage and scheduled refresh.

Trap A materialized view stores data and must be refreshed; a standard view does neither.

15 questions test this

A table persists data, defaulting to the Delta Lake format

A Unity Catalog table stores rows and columns using the Delta Lake format by default, and can be created empty, with CREATE TABLE AS SELECT (CTAS), or with CREATE OR REPLACE TABLE.

Lakehouse Federation needs a connection first, then a foreign catalog

To federate an external database you first create a connection object that stores the server host and credentials, then create a foreign catalog that uses that connection to mirror the external database's schemas in Unity Catalog.

9 questions test this

Federated queries run in place with no data copy

A foreign catalog runs Lakehouse Federation queries directly against the source system so its schemas and tables appear alongside other Unity Catalog objects and are queried in place, with no data copied into Databricks-managed storage.

Trap An ingestion pipeline or a managed table would copy the data; only a foreign catalog queries the source in place.

10 questions test this

Dropping a managed table deletes its underlying data

A managed table stores its data files in Unity Catalog managed storage, so DROP TABLE removes both the table metadata and the underlying data files.

Trap Dropping an external table removes only the metadata and leaves the files intact.

8 questions test this

An external table is defined with LOCATION and keeps its data on drop

An external table is created with a LOCATION clause pointing at a path under an external location, so Unity Catalog governs only its metadata and DROP TABLE leaves the underlying files untouched.

11 questions test this

AI/BI Genie answers natural-language questions over a curated data set

An AI/BI Genie Agent (formerly called a Genie space) lets business users ask natural-language questions that Genie converts to SQL over a curated set of Unity Catalog tables, enabling self-service data discovery without writing queries.

10 questions test this

Genie instructions and example queries steer accurate answers

Configuring Genie general instructions, example SQL queries, and verified answers guides how Genie interprets domain terms and business logic, improving the accuracy of the answers it generates for data discovery.

Trap Genie relies on the curated tables plus its instructions, not on unrestricted access to the whole metastore.

10 questions test this

A streaming table refresh applies the current definition only to newly arrived rows, and an incompatible definition change fails the next refresh instead of converting history

A streaming table refresh evaluates only the rows that arrived after the last update and appends them, using the current definition for that new data alone: modifying a streaming table definition does not automatically recalculate existing data. Removing a filter does not reprocess previously filtered rows, changing column projections does not affect how existing data was processed, and a join with a static snapshot uses the snapshot state seen at the time of the initial processing, so late-arriving data that would have matched an updated snapshot is ignored and facts can be dropped when dimensions are late. If a modification is incompatible with existing data - modifying the CAST of an existing column is the documented example - the next refresh fails with an error rather than converting the stored rows.

Trap Expecting a routine refresh to reapply an edited definition to rows that were already processed - assuming that removing a filter backfills the rows it used to exclude, that a changed projection rewrites existing rows, or that widening an existing column's CAST is absorbed quietly instead of failing the refresh.

3 questions test this

A materialized view refreshes incrementally only when its query is incrementalizable and its Delta sources have row tracking enabled; otherwise the system recomputes the whole query

Each materialized view refresh resolves to one of two methods: an incremental refresh that identifies changes since the last update and merges only new or modified rows, or a full refresh that reruns the entire query and replaces the stored results. Incremental refresh is conditional - the source data has to sit in Delta tables with row tracking enabled (ALTER TABLE ... SET TBLPROPERTIES (delta.enableRowTracking = true)), and the query structure has to be incrementalizable, which EXPLAIN CREATE MATERIALIZED VIEW will tell you. By default Databricks applies a cost model and picks whichever method is cheaper for that refresh, and a REFRESH POLICY in the definition overrides that choice; recreating a source table drops row tracking and must be re-enabled.

Trap Assuming that because a materialized view stores precomputed results it always updates incrementally, and so expecting cheap incremental refreshes without enabling row tracking on the Delta sources or checking that the query can be incrementalized.

5 questions test this

The comments on a Unity Catalog function and on its parameters are what tell Genie when to call it and what an argument should look like

Genie decides whether a registered function answers the question in front of it from the function's Unity Catalog metadata, not from its logic, because it cannot see inside the body it is calling. The COMMENT clause on the function is where you describe what the function does and therefore when it applies, and a COMMENT on each parameter is where you describe the value expected for it; Databricks documents precise comments as what lets a tool-calling agent know when and how to use a function, and a comment that only restates the function name is its example of ineffective documentation. Treat the comment as part of the trusted asset rather than as documentation: a function with a vague comment is registered, governed and reachable, and is still passed over in favour of generated SQL.

Trap Answering a function that Genie never calls by adding more general instruction text or another example query, when the metadata that decides selection - the function comment and its parameter comments - says nothing about when the function applies.

3 questions test this

Genie can only call a registered Unity Catalog SQL function with user-supplied parameters - it cannot view or modify the function's SQL - and every user of the Genie Agent needs EXECUTE on that function

A SQL function is the trusted-asset shape for logic too complex for a static or parameterized example query: it lives in Unity Catalog, Genie invokes it with parameter values taken from the user's question, and Genie can neither read nor rewrite the SQL inside it, which is why it suits logic that must not be surfaced or altered. That opacity is also the access-control consequence: users of the Genie Agent must hold the EXECUTE privilege on any SQL function used as a trusted asset, so sharing the Genie Agent alone does not make the function usable. Registering the function once also lets the same certified definition be shared across teams rather than restated as instruction text in every Genie Agent.

Trap Assuming that granting a business user access to the Genie Agent is enough for them to get answers from a function-backed trusted asset, or that Genie will adapt the function's SQL to handle a related question - Genie needs an explicit EXECUTE grant on the function and treats its body as a black box it can only call.

3 questions test this

A managed table or volume is written to the schema's managed storage location if the schema has one, otherwise the catalog's, otherwise the metastore's, so the lowest level that defines a location wins.

Unity Catalog resolves managed storage from the most specific level outward: schema first, then catalog, then metastore. Because a workspace newly enabled for Unity Catalog carries no metastore-level managed storage at all, assuming the data will fall back to the metastore is not safe, and the recommended isolation lever is a managed location on the catalog for each environment rather than one on every schema. Several catalogs and schemas may safely share a single managed location, because Unity Catalog isolates each object's data beneath it.

Trap That managed data always lands in the metastore's root storage, or that a location set on the catalog overrides one already set on the schema.

2 questions test this

A catalog or schema managed location is legal only inside an already-registered external location, while metastore-level managed storage must sit outside external locations and no managed storage may overlap an existing external table or volume path.

The path named as a catalog's or schema's managed location must fall inside storage that is already registered in Unity Catalog as an external location, which is why an otherwise well-formed catalog or schema creation is refused when the container was never registered. Metastore-level managed storage is the exception and must not sit inside an external location, and no managed storage at any level may overlap the path of an existing external table or external volume.

Trap That any storage container the workspace can reach may be named as a managed location, and that overlapping an existing external table's path is untidy rather than rejected.

3 questions test this

Altering a catalog's or schema's managed location governs only managed objects created after the change and physically moves no existing table or volume data.

Managed storage is resolved at the moment an object is created, so changing the location later re-points new managed tables and volumes only; everything already written stays where it first landed. A requirement to relocate data that already exists is therefore answered by recreating or copying those objects into the new location, never by the alter statement on its own.

Trap That setting a new managed location on the catalog or schema migrates the managed tables and volumes that are already there into the new container.

2 questions test this

A shallow clone is the answer when a receiving catalog needs a writable copy that may freely diverge with no upfront data duplication, and a deep clone is the answer when the copy must outlive the source, sit in different storage, or go to a team that will never have access to the source's files.

A shallow clone copies metadata only and references the source table's existing data files, so it completes in seconds against a multi-terabyte table and duplicates no bytes; a deep clone physically copies the data and is therefore the choice when the copy must stand on its own. Writes to either clone leave the source untouched, and re-issuing the same clone against an existing target syncs it incrementally instead of rebuilding it, which is what makes a clone the repeatable environment-refresh answer rather than a one-off query-built copy.

Trap That a development copy of a large production table must be a deep clone or a query-built copy so the team can write to it, and that refreshing that copy means dropping and rebuilding it each time.

2 questions test this

Shallow clone applies to Delta tables only and a clone must be managed-to-managed or external-to-external, so a managed source cannot be shallow cloned into an external target.

Unity Catalog requires the clone target to be the same kind of table as its source, and shallow clone additionally supports Delta tables only. A plan to shallow clone a production managed table into an external table in a development container fails on that rule alone, whatever privileges the requester holds, and has to be restructured as a managed target in the development catalog or as a deep clone.

Trap That any governed table can be shallow cloned to any container the user can write to, so the plan only needs the right privileges on the target.

2 questions test this

Running VACUUM on the source of a Unity Catalog shallow clone does not break the clone, because Unity Catalog tracks which source files the clone still references.

Under the legacy metastore a shallow clone could be orphaned when its base table was vacuumed, and that belief is carried forward into Unity Catalog scenarios where it no longer holds. Unity Catalog tracks the source files a clone still depends on, so the clone keeps reading them, and the same reference tracking is why vacuuming the base table can require access to the clone.

Trap That the shallow clone must be recreated, or promoted to a deep clone, before the source table's retention job runs, because VACUUM will remove the files it points at.

3 questions test this

Address every object as catalog.schema.object

Bind a catalog to specific workspaces

Create catalogs and schemas, and pin their storage

Managed vs external: who owns the files and the drop

Views and materialized views

Query external systems in place with federation

Self-service discovery with AI/BI Genie

Exam-pattern recognition

Managed vs external tables and volumes: storage and DROP

Decision tree

Cheat sheet

References