What you will be able to do
- Describe the train, validate and deploy tasks of the lifecycle workflow and how they pass a model URI
- Explain how validation gates the “Challenger” alias and how promotion to “Champion” works
- Separate environment (catalog) from deployment status (alias) for Models in Unity Catalog
- Map Databricks features to each model lifecycle management activity
1.The lifecycle workflow: train, validate, deploy
In the deploy-code approach, each environment runs the same pipeline code. That code is one multitask Databricks workflow, also called a Lakeflow Job, with three tasks in a fixed order: model training, then model validation, then model deployment. All three pipelines are written in development and then promoted as code. The training task logs parameters, metrics and artifacts to MLflow Tracking, then registers the model to the Unity Catalog catalog of the environment it ran in. Training produces a model URI, and task values pass that URI to the validation task.
Checkpoint 1 of 5· Fill the gap
Which MLflow call registers the logged model in Unity Catalog under its three-level name?
# Note that the UC model name follows the pattern
# <catalog_name>.<schema_name>.<model_name>, corresponding to
# the catalog, schema, and registered model name
# in Unity Catalog under which to create the version
# The registered model will be created if it doesn't already exist,
# and the model version will contain all parameters and metrics
# logged with the corresponding MLflow Logged Model.
logged_model = mlflow.last_logged_model()
mlflow. ? (logged_model.model_uri, "prod.ml_team.iris_model")mlflow.register_model takes a model URI and the <catalog>.<schema>.<model> name, and creates the registered model if it does not already exist.
Source: docs.databricks.comValidation is the gate. The validation pipeline loads the model from Unity Catalog using the URI and runs checks that fit the context. Basic checks confirm format and required metadata. Stricter checks, common in regulated industries, include predefined compliance checks such as required tags or documentation, and performance on selected data slices. You can record the outcome with tags; for example, a model_validation_status tag set to PENDING while tests run and then to PASSED or FAILED.
A model that passes validation becomes the “Challenger”. A model that fails does not move on: the process ends, and the workflow can notify users of the failure.
Sources1
2.Promotion: from “Challenger” to “Champion”
The deployment pipeline does one of two things. It promotes the “Challenger” to “Champion” directly by updating the alias, or it runs a comparison between them first. An offline comparison evaluates both models on a held-out dataset and tracks the results in MLflow Tracking. For real-time serving you might run longer online comparisons, such as A/B tests or a gradual rollout. The rule is: "If the “Challenger” model version performs better in the comparison, it replaces the current “Champion” alias." If there is no Champion yet, you can compare the Challenger against a business heuristic or another threshold.
Once a version holds the “Champion” alias, batch and streaming inference pipelines can use it by that alias. For real-time use, the pipeline can create or update a Model Serving endpoint. Model Serving makes a zero-downtime update by keeping the existing configuration running until the new one is ready. The process is fully automated. Where manual approval is required, you can add it through workflow notifications or CI/CD callbacks from the deployment pipeline.
Checkpoint 2 of 5· Check yourself
In an offline comparison on held-out data, the “Challenger” version scores worse than the current “Champion”. What happens to the “Champion” alias?
Replacing the Champion depends on the Challenger performing better in the comparison. If it does not, the current Champion keeps the alias.
“If the “Challenger” model version performs better in the comparison, it replaces the current “Champion” alias.”Source: docs.databricks.com
Checkpoint 3 of 5· Exam question
A platform team wants development, staging, and production ML assets to be governed under separate access policies while still using one Unity Catalog metastore. Which structural approach achieves this isolation for feature tables and registered models?
Correct answer: D — Create separate catalogs, for example dev, staging, and prod, scoping permissions via the catalog.schema.object namespace.
- A. Relying on admin rights for everyone and manual review does not create structural isolation, and it works against least-privilege access rather than scoping permissions per environment.
- B. Workspace-level controls alone do not isolate the catalog objects themselves; two workspaces can still point at the same catalog, so assets are not separated by environment.
- C. A naming prefix inside one shared catalog is only a convention, not an access boundary, so permissions cannot be scoped independently per environment this way.
- D. Separate catalogs per environment let permissions be granted at the catalog level, and the catalog.schema.object namespace makes it explicit which environment a given table or model belongs to.
MLflow 3 deployment jobs are a packaged form of the same gate. They are in Public Preview. A deployment job is a Lakeflow Job that starts automatically whenever a new model version is created in a Unity Catalog model. A simple one has three tasks: evaluation, which calls mlflow.evaluate; approval by a privileged user; and deployment to a Model Serving endpoint. The job must have the parameters model_name and model_version. It runs with the model owner's credentials, so Databricks recommends setting it up with a service principal that has minimal permissions.
3.Catalog means environment; alias means deployment status
Two pieces of Unity Catalog metadata are easy to confuse. The three-level name, <catalog>.<schema>.<model>, says which environment and which governance rules a model version belongs to. For example, privileges can be set so that only admins can delete from the prod catalog. The name does not say whether the version is serving traffic. Aliases such as “Challenger” and “Champion” carry the deployment status.
mlflow.sklearn.log_model(
sk_model=clf,
name="model",
# The signature is automatically inferred from the input example and its predicted output.
input_example=input_example,
# Use three-level name to register model in Unity Catalog.
registered_model_name="prod.ml_team.iris_model",
)Checkpoint 4 of 5· Check yourself
A new version has just been registered as prod.ml_team.iris_model. What can you conclude?
The catalog shows environment and governance, not serving status. Use aliases to manage deployment status.
“Using the prod catalog doesn't necessarily mean that the model version serves production traffic.”Source: docs.databricks.com
Sources3
4.Mapping Databricks features to lifecycle activities
Every activity covered so far runs on a specific Databricks feature. Exam questions often describe an activity and ask which feature supports it, so learn the pairs. For example, "every code change goes through a reviewed pull request" is version control, which Databricks Git folders provide together with your Git provider. MLflow tracking records the development process. Models in Unity Catalog handles versioning, governance and deployment status.
| Lifecycle activity | Databricks feature |
|---|---|
| Model code version control and sharing (branches, PR review) | Databricks Git folders |
| Track model development (params, metrics, artifacts) | MLflow model tracking |
| Manage model lifecycle (versions, governance, aliases) | Models in Unity Catalog |
| Schedule and automate training, validation, deployment workflows | Lakeflow Jobs |
| Define jobs, registered models, serving endpoints as code | Declarative Automation Bundles |
| Automated test and deploy pipelines | GitHub Actions, Azure DevOps pipelines, or Jenkins jobs |
| Serve the Champion model in real time | Model Serving |
| Model monitoring | Data profiling |
Checkpoint 5 of 5· Match them up
Match each Databricks feature to the lifecycle activity it supports.
Tap a term, then the definition that fits it.
Unity Catalog governs models. Git folders version code. Bundles define resources as code. Lakeflow Jobs orchestrate the work.
“Use Models in Unity Catalog to manage model versioning, governance, and deployment status.”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 is, by definition, the one serving production traffic.Why is that wrong?
The catalog shows environment and governance rules. Deployment status comes from aliases such as “Champion”.
Covered in Catalog means environment; alias means deployment status
2.Passing validation makes a model the “Champion”.Why is that wrong?
Validation can only assign the “Challenger” alias. The deployment pipeline decides, by direct promotion or by comparison, whether it becomes “Champion”.
Practise it for real
Generate a default MLOps Stacks project and identify where each lifecycle component lives.
1.Run
databricks bundle init mlops-stackswith the Databricks CLI.Why: This is the documented way to start an MLOps Stacks project.
You should see: The CLI walks you through entering configuration details for the project.
2.When asked, choose to set up both the ML code components and the CI/CD components.
Why: ML code is typically used by data scientists and CI/CD by ML engineers; choosing both shows you the whole stack.
You should see: A directory of project files is created that implements the recommended production MLOps workflow.
3.Find the training and batch inference templates, the Declarative Automation Bundles resource definitions, and the GitHub Actions or Azure DevOps workflows.
Why: These are the three default components: ML code, ML resources as code, and CI/CD.
You should see: You can point to where code changes, resource changes and the automated test-and-deploy logic are each kept.
Stuck? Get a nudge
You only edit the generated files to add your own code; the stack itself is already wired for deploy code.
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“you deploy a multitask Databricks workflow in which the first task is the model training pipeline, followed by model validation and model deployment tasks.”
↩︎ The lifecycle workflow: train, validate, deploy“You can use task values to pass this URI to the model.”
↩︎ The lifecycle workflow: train, validate, deploy“fundamental checks such as confirming format and required metadata”
↩︎ The lifecycle workflow: train, validate, deploy“You can use tags to add key-value attributes depending on the outcome of these validation checks.”
↩︎ The lifecycle workflow: train, validate, deploy“If the checks fail, the process ends.”
↩︎ The lifecycle workflow: train, validate, deploy“An offline comparison evaluates both models against a held-out data set and tracks results using the MLflow Tracking server.”
↩︎ Promotion: from “Challenger” to “Champion”“If there is no existing “Champion” model, you might compare the “Challenger” model to a business heuristic or other threshold as a baseline.”
↩︎ Promotion: from “Challenger” to “Champion”“Batch or streaming inference pipelines can be set up to use the model with the “Champion” alias.”
↩︎ Promotion: from “Challenger” to “Champion”“Model Serving executes a zero-downtime update by keeping the existing configuration running until the new one is ready.”
↩︎ Promotion: from “Challenger” to “Champion”“You can use MLflow to track the model development process and save code snapshots, model parameters, metrics, and other metadata.”
↩︎ Mapping Databricks features to lifecycle activities“The primary function of the model validation pipeline is to determine whether a model should proceed to the deployment step.”
↩︎ Exam trap 2“If the model passes pre-deployment checks, it can be assigned the “Challenger” alias in Unity Catalog.”
↩︎ Prediction“If the “Challenger” model version performs better in the comparison, it replaces the current “Champion” alias.”
↩︎ Checkpoint“Use Models in Unity Catalog to manage model versioning, governance, and deployment status.”
↩︎ Checkpoint - 2.
“Deployment jobs allow you to automate tasks like evaluation, approval, and deployment whenever a new model version is created”
↩︎ Promotion: from “Challenger” to “Champion”“A deployment job must have two job parameters: model_name and model_version.”
↩︎ Promotion: from “Challenger” to “Champion”“Databricks recommends that you set up the deployment job using a service principal with minimal permissions to prevent privilege escalation.”
↩︎ Promotion: from “Challenger” to “Champion” - 3.
“Then, pass the three-level name of the model to MLflow APIs, in the form <catalog>.<schema>.<model>.”
↩︎ Catalog means environment; alias means deployment status“To manage the deployment status, use model aliases.”
↩︎ Catalog means environment; alias means deployment status“To manage the deployment status, use model aliases.”
↩︎ Exam trap 1“Using the prod catalog doesn't necessarily mean that the model version serves production traffic.”
↩︎ Checkpoint - 4.
“Declarative Automation Bundles: Automates the creation and deployment of Databricks resources, such as jobs, registered models, and serving endpoints.”
↩︎ Mapping Databricks features to lifecycle activities“Git folders: Code versioning and sharing from the workspace, also helps teams follow software engineering best practices.”
↩︎ Mapping Databricks features to lifecycle activities“Jobs: Automates jobs and create scheduled machine learning workflows.”
↩︎ Mapping Databricks features to lifecycle activities