What you will be able to do
- Name the benefits that Models in Unity Catalog brings over the Workspace Model Registry: centralized access control, auditing, lineage and model discovery across workspaces
- Explain how the three-level namespace and privilege inheritance give models the same governance as tables
- Contrast built-in cross-workspace model access in Unity Catalog with the deprecated token-based remote registry
Key concept
Models in Unity Catalog — The hosted MLflow Model Registry that lives inside Unity Catalog. Registered models become governed securable objects next to tables and files, and no single workspace owns them. Every benefit over the workspace registry comes from this change.
1.Two registries, one recommendation
Databricks offers two hosted versions of the MLflow Model Registry. The older one, the Workspace Model Registry, is now labelled *legacy*. Its models belong to one workspace, and its documentation opens by telling you not to use it if your workspace is enabled for Unity Catalog. The newer one, Models in Unity Catalog, is the one Databricks recommends for governing and deploying models. It works with the open-source MLflow Python client, so your code for logging and registering models looks much the same. What changes is where the model lives and who governs it.
Databricks answers in one phrase: Models in Unity Catalog *extends the benefits of Unity Catalog to ML models*. The docs name four benefits each time they make the case: centralized access control, auditing, lineage, and model discovery across workspaces. The migration guide sums up the same argument as better governance, easy sharing across workspaces and environments, and more flexible MLOps workflows. The table below compares what the legacy registry offered with what Unity Catalog changes.
| Concern | Workspace Model Registry | Models in Unity Catalog |
|---|---|---|
| Access control | Workspace administrators set permissions for all models in that workspace's registry | Unity Catalog privileges, managed in one central place |
| Sharing across workspaces | Possible "with some setup" through a remote Workspace model registry | Built-in support for cross-workspace model access, governance, and audit logging |
| Lifecycle labels | Stage transitions (staging, production, archived) | Recommended replacement for the legacy stage-based registry |
| Capacity | Quota limits on registered models and model versions per workspace (since May 2024) | Databricks' recommended registry for sharing models across workspaces |
Checkpoint 1 of 5· Check yourself
A team lead asks why new models should go in Unity Catalog and not the Workspace Model Registry. Which answer matches the benefit Databricks documents?
The benefit is governance and sharing, not training speed. The workspace registry also had versioning, and Unity Catalog still requires privileges such as CREATE MODEL.
“including centralized access control, auditing, lineage, and model discovery across workspaces”Source: docs.databricks.com
2.Governance: models become securable objects
Unity Catalog organizes everything in a three-level namespace: catalog, schema, object. Every object in that hierarchy is a securable object. A registered model's name has the form <catalog>.<schema>.<model>, and the model is governed the same way as a table. This gives you one place to manage and audit access to both data *and* AI assets. The governance best-practices guide links this to separation of duties and regulatory compliance.
Catalogs and schemas are container objects, so a privilege granted on them is inherited. If you grant a group a privilege on a schema, it applies to every object already in that schema and to every object added later. Creating a model also needs privileges: USE CATALOG and USE SCHEMA on the containers, plus CREATE MODEL (or CREATE FUNCTION) on the schema. You can grant them in Catalog Explorer or with SQL:
GRANT CREATE MODEL ON SCHEMA <schema-name> TO <principal>Every securable has an owner. The owner holds all privileges on the object and can grant them to others, and this works the same for tables and models. Auditing comes from the same central setup. Databricks records audit logs of user activity at the workspace and account level. These logs are a historical record for compliance and policy enforcement, not a debugging tool.
Checkpoint 2 of 5· Check yourself
A platform admin grants a data science group a privilege on the prod.ml_team schema. The next week, someone registers a new model as prod.ml_team.churn_model. What happens?
Schemas are container objects. Privileges granted on them are inherited by child objects created later, including registered models.
“When you grant a privilege on a container object, that privilege automatically applies to all current and future child objects.”Source: docs.databricks.com
Checkpoint 3 of 5· Exam question
A ML platform team runs separate Databricks workspaces for staging and production. They want a newly trained fraud-detection model to be usable for batch scoring jobs in both workspaces immediately after training, without copying files or re-registering the model in each workspace. Which registry choice and mechanism satisfies this requirement?
Correct answer: A — Register the model in Unity Catalog, because models registered there are accessible from any workspace attached to the same metastore.
- A. Correct. A model registered in Unity Catalog is immediately visible and loadable from any workspace attached to the same metastore, so no copying or re-registration is needed.
- B. Incorrect. The workspace-scoped registry stores model versions inside a single workspace and has no metastore-level sharing mechanism, so other workspaces cannot see those versions at all.
- C. Incorrect. Unity Catalog already solves cross-workspace access natively; manually exporting and copying artifacts through DBFS is unnecessary work that also loses registry-tracked version metadata.
- D. Incorrect. The workspace-scoped registry has no cross-workspace grant capability for model versions, so no administrator action can extend its visibility beyond the workspace it lives in.
3.Cross-workspace access without tokens
With the legacy registry, sharing across workspaces took manual setup. Each user or script created a personal access token in the remote workspace and copied it into their local workspace's secret manager. Every API request then had to include that token. The client also had to point at the remote registry explicitly:
client = MlflowClient(tracking_uri=None, registry_uri=registry_uri)
client.transition_model_version_stage(model_name, version, 'Archived')
client.delete_registered_model(model_name)The page that documents this pattern now says the approach is deprecated and points to Models in Unity Catalog. Unity Catalog has built-in support for cross-workspace model access, governance and audit logging, so you don't copy tokens or configure a remote registry URI. The community MLflow Export-Import project can still copy experiments, runs and models between workspaces. It makes copies, though, and is not how Databricks recommends sharing models.
MLflow 3 goes further. When you register a logged model to the Unity Catalog registry, its metrics and parameters come with it. You can then compare model performance across experiments *and workspaces* on one page.
Checkpoint 4 of 5· Check yourself
Which statement about sharing models across workspaces is accurate?
Remote registries with tokens are the deprecated workspace-registry approach. Databricks recommends Models in Unity Catalog, which supports cross-workspace access directly.
“Unity Catalog provides out-of-the-box support for cross-workspace model access, governance, and audit logging.”Source: docs.databricks.com
Checkpoint 5 of 5· Exam question
A Databricks admin wants one team's data scientists to read and score a registered model without letting them modify its aliases or delete versions, while a separate ML engineering team keeps full management rights over the same model. Which approach configures this precisely?
Correct answer: A — Register the model in Unity Catalog and issue separate GRANT statements for privileges such as EXECUTE and MANAGE on the model to each team's principals.
- A. Correct. Unity Catalog privileges such as EXECUTE and MANAGE can be granted independently to different principals on the same securable, giving one team score-only access and another full management rights.
- B. Incorrect. The workspace-scoped registry does not offer fine-grained, privilege-based permissions on individual models; access there is coarser and tied to workspace-level object permissions.
- C. Incorrect. Notebook-level cluster ACLs control who can run compute, not who can read, score, or manage a specific registered model, so they do not enforce the required separation.
- D. Incorrect. Toggling a single Can Manage flag per user in the admin console does not distinguish read/score access from alias or version management, so it cannot express this split.
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.To share a Unity Catalog model with another workspace, you need a remote registry URI and personal access tokens stored as secrets.Why is that wrong?
Token-based remote registries are the deprecated Workspace Model Registry approach. Databricks recommends Models in Unity Catalog for sharing models across workspaces.
Covered in Cross-workspace access without tokens
2.Models in Unity Catalog have their own model-only permission system, so you manage table grants and model grants in different places.Why is that wrong?
Models are securable objects in the same catalog.schema hierarchy as tables, and Unity Catalog manages access control for all of them in one place.
Covered in Governance: models become securable objects
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“Models in Unity Catalog is compatible with the open-source MLflow Python client.”
↩︎ Two registries, one recommendation“CREATE MODEL or CREATE FUNCTION privilege on the schema.”
↩︎ Governance: models become securable objects“including centralized access control, auditing, lineage, and model discovery across workspaces”
↩︎ Key concept“including centralized access control, auditing, lineage, and model discovery across workspaces”
↩︎ Checkpoint - 2.https://docs.databricks.com/aws/en/machine-learning/manage-model-lifecycle/migrate-to-ucOfficial docs
“Databricks recommends using Models in Unity Catalog for improved governance, easy sharing across workspaces and environments, and more flexible MLOps workflows.”
↩︎ Two registries, one recommendation - 3.https://docs.databricks.com/aws/en/machine-learning/manage-model-lifecycle/workspace-model-registryOfficial docs
“If your workspace is enabled for Unity Catalog, do not use the procedures on this page.”
↩︎ Two registries, one recommendation“workspace administrators can set permissions for all models in the Workspace Model Registry”
↩︎ Two registries, one recommendation“Unity Catalog provides out-of-the-box support for cross-workspace model access, governance, and audit logging.”
↩︎ Cross-workspace access without tokens - 4.https://docs.databricks.com/aws/en/data-governance/unity-catalog/access-control/permissions-conceptsOfficial docs
“Every object in this hierarchy is a securable object.”
↩︎ Governance: models become securable objects“When you grant a privilege on a container object, that privilege automatically applies to all current and future child objects.”
↩︎ Checkpoint - 5.https://docs.databricks.com/aws/en/lakehouse-architecture/data-governance/best-practicesOfficial docs
“providing a central place to administer and audit access to these assets”
↩︎ Governance: models become securable objects“audit logs provide a historical record of activity for compliance and other business policy enforcement purposes”
↩︎ Governance: models become securable objects“The Unity Catalog centralizes access controls for all supported securable objects such as tables, files, models, and many more.”
↩︎ Exam trap 2 - 6.https://docs.databricks.com/aws/en/machine-learning/manage-model-lifecycle/multiple-workspacesOfficial docs
“Each user or script that needs access creates a personal access token in the remote registry”
↩︎ Cross-workspace access without tokens“Databricks recommends using Models in Unity Catalog to share models across workspaces. The approach in this article is deprecated.”
↩︎ Exam trap 1“Access to a remote registry is controlled by tokens.”
↩︎ Prediction - 7.
“You can see model performance metrics across all MLflow experiments and workspaces on a single page.”
↩︎ Cross-workspace access without tokens