What you will be able to do
- Explain why aliases, tags and deployment jobs give more flexible lifecycle management than the workspace registry's fixed stages
- Map workspace registry permissions to their Unity Catalog privileges
- Recognize the limits and defaults that now push new work toward Models in Unity Catalog
1.From fixed stages to aliases, tags and deployment jobs
The Workspace Model Registry tracked a model's lifecycle with stages such as Staging and Production. You could search for a model or call it by stage. To move a version between stages, someone filed a transition request that needed human approval. One reason Databricks gives for preferring Unity Catalog is "more flexible MLOps workflows", and the replacement for stages is where that flexibility comes from.
Unity Catalog splits a stage's two jobs between two tools. Aliases are for *calling* a model, and tags are for *labelling* it. The meaning also changes. In the workspace registry, several versions could share a stage, and a reference returned the latest one. In Unity Catalog, an alias points to exactly one model version. You can set tags on a model or on a model version, up to 50 tags per object, and you can search for models by tag in Catalog Explorer.
Promotion moves to deployment jobs. Each task in a deployment job does the work a stage used to do. Deployment jobs support more complex workflows than the workspace registry did, and they still allow human approvals.
| Need | Workspace Model Registry | Models in Unity Catalog |
|---|---|---|
| Call a specific model version | By stage; several versions could share a stage and the latest was used | By alias; each alias points to one specific model version |
| Label versions (e.g. Production, Archived) | Stage | Tags on the model or model version |
| Move a version through its lifecycle | Stage transition requests with human approval | Deployment jobs, which still accommodate human approvals |
| Number of lifecycle names | Four fixed stages | Up to 10 custom, reassignable aliases |
Checkpoint 1 of 6· Check yourself
A team used to keep three model versions in the Staging stage at once. After moving to Unity Catalog, they set an alias called Staging. What does that alias point to?
Unlike a stage, a Unity Catalog alias points to a single model version. To label several versions, use tags.
“In Unity Catalog, an alias is assigned to a unique model version.”Source: docs.databricks.com
Checkpoint 2 of 6· Exam question
A compliance team needs to verify, for an existing production model version, exactly which Delta tables and feature tables were used to train it, without relying on notes the original data scientist may or may not have kept. Which registry capability directly supports this audit requirement?
Correct answer: A — Unity Catalog automatically captures lineage from the training tables to the registered model version, viewable in the Lineage tab for that model.
- A. Correct. Unity Catalog tracks lineage between the tables read during training and the resulting registered model version automatically, and compliance can inspect it directly in the Lineage tab.
- B. Incorrect. The workspace-scoped registry has no automatic table-to-model lineage tracking; it only records stage transitions and version metadata, not upstream data dependencies.
- C. Incorrect. Unity Catalog captures lineage automatically at training time, so requiring a manually attached diagram would defeat the purpose and reintroduce reliance on the data scientist's notes.
- D. Incorrect. Reconstructing lineage by manually reading logged parameters from an MLflow run is error-prone and depends on the data scientist having logged table names as parameters in the first place.
Sources1
2.Catalogs express environment and governance, not deployment status
The namespace itself becomes a governance tool. The registration examples in the Unity Catalog docs create models such as prod.ml_team.iris_model. A model in a prod catalog belongs to the prod environment and follows that catalog's rules. For example, you can set privileges so that only admins can delete from the prod catalog. The catalog does not tell you that the version is serving production traffic. Aliases track that.
In the workspace registry, a stage carried both meanings at once. In Unity Catalog, the catalog and schema record the environment and governance, which rarely change and are protected by privileges. An alias records deployment status, and you can move it to another version without changing any grants.
Checkpoint 3 of 6· Check yourself
A new version is registered as prod.ml_team.iris_model. What does the prod catalog tell you about it?
The catalog, schema and model name reflect the environment and its governance rules. Deployment status is managed separately with model aliases.
“The model version's enclosing catalog, schema, and registered model reflect its environment (prod) and associated governance rules”Source: docs.databricks.com
Sources2
3.Workspace permissions become account-level privileges
Workspace registry permissions applied inside one workspace. Unity Catalog replaces them with account-level privileges in a single permission model. The mapping is not one-to-one. Stages no longer exist, so the two stage-management permissions become tags plus deployment jobs. Every action in the table also requires USE CATALOG and USE SCHEMA.
| Workspace model registry | Unity Catalog | Notes |
|---|---|---|
| Can read | EXECUTE | — |
| Can edit | CREATE MODEL VERSION + APPLY TAG | Cannot edit the Description of models or model versions |
| Can manage staging versions | APPLY TAG + deployment job | Deployment jobs control movement through lifecycle stages |
| Can manage production versions | APPLY TAG + deployment job | Deployment jobs control movement through lifecycle stages |
| Can manage | MANAGE | — |
Checkpoint 4 of 6· Match them up
Match each workspace registry permission to its Unity Catalog equivalent
Tap a term, then the definition that fits it.
Read maps to EXECUTE, and manage maps to MANAGE. Edit becomes the right to add versions and tags. Stage management becomes tags plus deployment jobs.
“Workspace Model Registry permissions are replaced by account-level Unity Catalog permissions.”Source: docs.databricks.com
Sources1
4.Why new work defaults to Unity Catalog
Apart from what Unity Catalog adds, the workspace registry now has its own constraints:
- Quotas. Since May 2024, each workspace has limits on the total number of registered models and model versions. Databricks advises deleting models you no longer need or changing your retention strategy to stay under them.
- Disabled for new accounts. Since April 2024, the workspace registry is disabled for workspaces in new accounts whose default catalog is in Unity Catalog.
- Not the default. Suppose the workspace's default catalog is in Unity Catalog and you run Databricks Runtime 13.3 LTS or above, or MLflow 3. Models are then created in and loaded from that catalog automatically. MLflow 3's default registry URI is databricks-uc. To use the workspace registry instead, you must call mlflow.set_registry_uri("databricks").
You can migrate existing models. With MLflow client 3.4.0 or above, Databricks recommends copy_model_version(). If the destination Unity Catalog model doesn't exist yet, the call creates it. Plan for one difference: Models in Unity Catalog require a model signature.
Checkpoint 5 of 6· Fill the gap
This snippet copies version 1 of a workspace registry model into Unity Catalog. Which method completes it?
import mlflow
from mlflow import MlflowClient
# Registry must be set to workspace registry
mlflow.set_registry_uri("databricks")
client = MlflowClient(registry_uri="databricks")
src_model_uri = f"models:/my_wmr_model/1"
uc_migrated_copy = client. ? (
src_model_uri, "mycatalog.myschema.my_uc_model"
)copy_model_version() is the recommended migration API (MLflow client 3.4.0 or above). It reads from the workspace registry, so the code sets the registry URI to "databricks" first.
Source: docs.databricks.comCheckpoint 6 of 6· Check yourself
A data scientist on MLflow 3 calls the registration API without setting a registry URI. Where does the model get registered?
MLflow 3's default registry URI is databricks-uc. You must select the workspace registry explicitly with mlflow.set_registry_uri("databricks").
“The default registry URI in MLflow 3 is databricks-uc, meaning the MLflow Model Registry in Unity Catalog will be used.”Source: docs.databricks.com
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.A model version registered in the prod catalog must be the one serving production traffic.Why is that wrong?
The catalog reflects only the environment and its governance rules. Model aliases track which version is deployed.
Covered in Catalogs express environment and governance, not deployment status
2.A user with "Can edit" in the workspace registry keeps the same edit rights in Unity Catalog, including editing descriptions.Why is that wrong?
Can edit maps to CREATE MODEL VERSION + APPLY TAG. Those privileges don't allow editing the Description of models or model versions.
Covered in Workspace permissions become account-level privileges
3.Moving to Unity Catalog removes human approval from model promotion, because stage transition requests no longer exist.Why is that wrong?
Deployment jobs now handle lifecycle movement. They support more complex workflows and still allow human approvals.
Covered in From fixed stages to aliases, tags and deployment jobs
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.https://docs.databricks.com/aws/en/machine-learning/manage-model-lifecycle/migrate-to-ucOfficial docs
“In Unity Catalog, stages have been replaced by aliases for calling a model and by tags for labeling models.”
↩︎ From fixed stages to aliases, tags and deployment jobs“Deployment jobs allow you to customize the model lifecycle and accommodate more complicated workflows than the Workspace Model Registry.”
↩︎ From fixed stages to aliases, tags and deployment jobs“Unity Catalog allows at most 50 tags per object.”
↩︎ From fixed stages to aliases, tags and deployment jobs“Workspace Model Registry permissions are replaced by account-level Unity Catalog permissions.”
↩︎ Workspace permissions become account-level privileges“Users with these privileges are not able to edit the Description of models or model versions.”
↩︎ Exam trap 2“Deployment jobs still accommodate human approvals.”
↩︎ Exam trap 3“Instead of four fixed stages, you can create up to 10 custom and reassignable aliases.”
↩︎ Prediction“In Unity Catalog, an alias is assigned to a unique model version.”
↩︎ Checkpoint - 2.
“but not its deployment status. To manage the deployment status, use model aliases.”
↩︎ Catalogs express environment and governance, not deployment status“Using the prod catalog doesn't necessarily mean that the model version serves production traffic.”
↩︎ Exam trap 1“The model version's enclosing catalog, schema, and registered model reflect its environment (prod) and associated governance rules”
↩︎ Checkpoint“The default registry URI in MLflow 3 is databricks-uc, meaning the MLflow Model Registry in Unity Catalog will be used.”
↩︎ Checkpoint - 3.https://docs.databricks.com/aws/en/machine-learning/manage-model-lifecycle/workspace-model-registryOfficial docs
“the Workspace Model Registry imposes quota limits on the total number of registered models and model versions per workspace”
↩︎ Why new work defaults to Unity Catalog“Starting in April 2024, Databricks disabled Workspace Model Registry for workspaces in new accounts where the workspace's default catalog is in Unity Catalog.”
↩︎ Why new work defaults to Unity Catalog - 4.https://docs.databricks.com/aws/en/machine-learning/manage-model-lifecycle/migrate-modelsOfficial docs
“Models in Unity Catalog require a signature.”
↩︎ Why new work defaults to Unity Catalog