What you will be able to do
- Describe the train, validate and deploy pipeline chain and where each model version is registered
- Explain how validation results lead to the Challenger alias and how a Challenger becomes the Champion
- Trace a code change from pull request through staging tests to a production release, as implemented by MLOps Stacks
1.From experiments to a train, validate, deploy chain
The development stage is for experimentation, but what it delivers is code, not a model. Data scientists build features and models and run experiments. The result is ML pipeline code covering feature computation, model training, inference and monitoring. Exploratory analysis is usually an ad hoc notebook process. AutoML can speed it up by generating baseline models, recording a set of trials, and giving you a Python notebook with the source code for each trial so you can review, reproduce and modify it. Data scientists should keep their work in a Git repository from the start, using a development branch.
The model training pipeline has two tasks. Training and tuning logs parameters, metrics and artifacts to MLflow Tracking, then logs the final model artifact. That links the model to the data it was trained on and the code that produced it. Evaluation tests the model on held-out data to see whether it beats the current production model, which can be loaded from the prod catalog with sufficient permissions. If governance requires extra documentation, such as SHAP plots or plain-text descriptions, it can also be saved through MLflow Tracking.
After training, the model is registered to Unity Catalog. The pipeline should register it to the catalog of whichever environment it ran in. A run in development registers to the dev catalog, and a run in production saves a registered model version in the production catalog.
In the recommended architecture, training, validation and deployment run as one multitask Databricks workflow. The training task produces a model URI, and task values pass that URI to the validation task. Validation and deployment pipelines are written in the development environment alongside the training pipeline. When they are ready, the dev branch changes are committed to source control.
Checkpoint 1 of 5· Put it in order
Put the tasks of the recommended multitask Databricks workflow in order.
- 1.Model training pipeline (yields a model URI)
- 2.Model deployment (alias update or Champion vs Challenger comparison)
- 3.Model validation (loads the model by URI and runs checks)
Training runs first and produces the URI. Validation decides whether the model may continue, and deployment runs last.
“a multitask Databricks workflow in which the first task is the model training pipeline, followed by model validation and model deployment tasks”Source: docs.databricks.com
Checkpoint 2 of 5· Check yourself
The same training pipeline runs in the development, staging and production workspaces. Where should each run register its model?
Each environment has its own catalog, so a run in development registers to dev, a run in staging to staging, and a run in production to prod.
“Set up your pipeline code to register the model to the catalog corresponding to the environment that the model pipeline was executed in”Source: docs.databricks.com
Sources1
2.Validation, Challenger and Champion
The validation pipeline loads the model from Unity Catalog using the URI from training and decides whether the model may go on to deployment. Checks depend on context. They range from confirming format and required metadata to compliance checks and performance on selected data slices for regulated industries. If the checks fail, the process ends, and the job can notify users. In production, tags can record the outcome. For example, a model_validation_status tag can be set to PENDING while tests run and changed to PASSED or FAILED at the end.
The deployment pipeline then does one of two things. It can promote the Challenger directly to Champion with an alias update, or it can compare the existing Champion with the new Challenger first. It can also set up inference infrastructure such as Model Serving endpoints. Aliases mark lifecycle state without renaming artifacts. The general ML lifecycle guidance gives Staging and Production as example alias names, while the MLOps workflow uses Challenger and Champion. Because every registered version is kept, you can test a new version before promoting it and roll back to an earlier version if quality degrades.
Checkpoint 3 of 5· Check yourself
In the recommended deployment pipeline, how does a validated Challenger model typically become the production model?
Promotion is an alias change, optionally after a Champion vs Challenger comparison. Artifacts and model names stay the same.
“directly promotes the newly trained “Challenger” model to “Champion” status using an alias update”Source: docs.databricks.com
Checkpoint 4 of 5· Exam question
A company runs several Databricks workspaces per business unit and wants a single source of truth for which models are approved for production, along with a full audit trail of who accessed each model version. Which registry setup best supports this MLOps requirement?
Correct answer: A — Register models in Unity Catalog, since it centralizes governance, access auditing, and lineage across every attached workspace.
- A. Unity Catalog's model registry centralizes access control, auditing, and lineage tracking, and because catalogs can be shared across workspaces attached to the same metastore, it gives one governed source of truth for approved models.
- B. The legacy workspace registry is scoped to a single workspace and has no built-in cross-workspace governance, so manually exporting stage information does not provide real auditing or a unified source of truth.
- C. Shared object storage access grants file-level read permissions but carries none of the model versioning, alias, or audit metadata that a registry provides, so it cannot answer which version is approved for production.
- D. Querying another workspace's tracking experiment over the API exposes run metadata but not registry-level governance features like access control or approved-version tracking across business units.
3.Staging, CI/CD and MLOps Stacks
The staging stage tests whether the ML pipeline code is ready for production. That means all of it, including feature engineering and inference code, not only model training. ML engineers build a CI pipeline for the unit and integration tests. The process starts when someone opens a pull request against the main branch. The PR triggers unit tests automatically, and a failure rejects the PR. Staging produces a release branch, which triggers the CI/CD system to start the production stage.
MLOps Stacks packages this workflow as code. The whole model development process is implemented, saved and tracked as code in a source-controlled repository. That is what makes deploying code instead of models practical. A default stack has three parts: ML code templates (notebooks for training, batch inference and so on), ML resources defined as code in Declarative Automation Bundles, and CI/CD through GitHub Actions or Azure DevOps. CI/CD ensures that every production change goes through automation and that only tested code reaches prod. You create a project with the Databricks CLI:
databricks bundle init mlops-stacks| Component | Tool in Databricks |
|---|---|
| ML model development code | Databricks notebooks, MLflow |
| ML model repository | Models in Unity Catalog |
| Infrastructure-as-code | Declarative Automation Bundles |
| Orchestrator | Lakeflow Jobs |
| CI/CD | GitHub Actions, Azure DevOps |
Checkpoint 5 of 5· Put it in order
Put the default MLOps Stacks flow for a code change in order.
- 1.The PR is merged to main, and staging jobs update to run the latest code
- 2.A release branch is cut and the code changes are deployed to production
- 3.Data scientists iterate on ML code in the development workspace and file a pull request
- 4.The PR triggers unit and integration tests in an isolated staging workspace
Code is tested in staging before it is merged, and production only receives code from a release branch cut after the merge.
“you can cut a new release branch as part of your scheduled release process and deploy the code changes to production.”Source: docs.databricks.com
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.A model that fails validation still gets the Challenger alias so a human can decide later.Why is that wrong?
Only a model that passes the pre-deployment checks is assigned the Challenger alias. If validation fails, the process exits and users can be notified.
Covered in Validation, Challenger and Champion
2.The staging stage only needs to test the model training code.Why is that wrong?
Staging tests all ML pipeline code, including feature engineering pipelines and inference code.
Covered in Staging, CI/CD and MLOps Stacks
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“The output of the development process is ML pipeline code that can include feature computation, model training, inference, and monitoring.”
↩︎ From experiments to a train, validate, deploy chain“AutoML performs and records a set of trials and provides a Python notebook with the source code for each trial run”
↩︎ From experiments to a train, validate, deploy chain“The purpose of evaluation is to determine if the newly developed model performs better than the current production model.”
↩︎ From experiments to a train, validate, deploy chain“the model artifact is saved as a registered model version at the specified model path in the production catalog in Unity Catalog”
↩︎ From experiments to a train, validate, deploy chain“You can use task values to pass this URI to the model.”
↩︎ From experiments to a train, validate, deploy chain“The primary function of the model validation pipeline is to determine whether a model should proceed to the deployment step.”
↩︎ Validation, Challenger and Champion“You can use tags to add key-value attributes depending on the outcome of these validation checks.”
↩︎ Validation, Challenger and Champion“The output of the staging process is a release branch that triggers the CI/CD system to start the production stage.”
↩︎ Staging, CI/CD and MLOps Stacks“If unit tests fail, the pull request is rejected.”
↩︎ Staging, CI/CD and MLOps Stacks“If the model does not pass all validation checks, the process exits and users can be automatically notified.”
↩︎ Exam trap 1“All of the ML pipeline code is tested in this stage”
↩︎ Exam trap 2“a multitask Databricks workflow in which the first task is the model training pipeline, followed by model validation and model deployment tasks”
↩︎ Checkpoint“Set up your pipeline code to register the model to the catalog corresponding to the environment that the model pipeline was executed in”
↩︎ Checkpoint“If the model passes pre-deployment checks, it can be assigned the “Challenger” alias in Unity Catalog.”
↩︎ Prediction“directly promotes the newly trained “Challenger” model to “Champion” status using an alias update”
↩︎ Checkpoint - 2.
“Label the candidate model version with aliases (Staging, Production) to signal lifecycle state without renaming artifacts.”
↩︎ Validation, Challenger and Champion“roll back to a previous version if quality degrades”
↩︎ Validation, Challenger and Champion - 3.
“PRs trigger unit tests and integration tests in an isolated staging Databricks workspace.”
↩︎ Staging, CI/CD and MLOps Stacks“ensuring that all production changes are performed through automation and that only tested code is deployed to prod”
↩︎ Staging, CI/CD and MLOps Stacks“you can cut a new release branch as part of your scheduled release process and deploy the code changes to production.”
↩︎ Checkpoint