What you will be able to do
- Define MLOps and name the three kinds of ML assets it manages
- Explain why Databricks recommends separate development, staging and production environments, each mapped to its own Unity Catalog catalog
- Match the core MLOps recommendations (Git, Delta tables, MLflow, Models in Unity Catalog) to the problem each solves
- Choose between the deploy-code and deploy-models patterns for a given scenario
Key concept
Promote code, not models — In the recommended Databricks MLOps strategy, the training code moves from development to staging to production, and each environment retrains the model itself. You do not copy a trained model artifact forward. Production code and production models therefore go through the same review and testing.
1.What an MLOps strategy manages
Databricks defines MLOps as a set of processes and automated steps for managing code, data, and models. The goal is better performance, stability and long-term efficiency of ML systems. It combines three older disciplines: DevOps for code, DataOps for data, and ModelOps for models. Exam questions on MLOps strategy keep coming back to those three asset types, so keep them in mind as you read the rest of this lesson.
Assets don't go straight from a notebook to production. They pass through stages. Early development has loose access rules and little testing. An intermediate stage tests the work. The final production stage is tightly controlled. Databricks' main argument is that you can manage every stage on one platform with unified access control. Because data applications and ML applications live in the same place, you avoid the risks and delays of moving data between systems.
CI/CD for ML is broader than CI/CD for ordinary software. Databricks says an automated CI/CD workflow for ML should track the training data (its quality, schema changes and distribution changes), the input data pipelines, the code for training, validating and serving the model, and the model's predictions and performance. Code is only one of these four.
Checkpoint 1 of 6· Check yourself
A team wants to add CI/CD to its ML project. Which of these does Databricks NOT list among the things to track in an automated CI/CD workflow for ML?
The documented list is training data (quality, schema, distribution), input data pipelines, the training/validation/serving code, and model predictions and performance. Notebook counts are not on it.
“Training data, including data quality, schema changes, and distribution changes.”Source: docs.databricks.com
2.Separate environments, one catalog each
An execution environment is the place where code creates or consumes models and data. Each one has its own compute instances, runtimes and libraries, and automated jobs. Databricks recommends separate environments for the different stages of ML code and model development, with clearly defined transitions between them. The usual names are development, staging and production, though organizations can configure them differently. On Databricks, each environment typically corresponds to a catalog in Unity Catalog.
In the reference architecture, data scientists have read-write access to the dev catalog. They create temporary data and feature tables there and register development models to it. With read-only access to the prod catalog they can also analyze production data, inference tables and metric tables, and load production models for experiments. The staging environment has its own catalog for testing pipelines and registering test models. Anything written there is usually temporary.
| Environment | Catalog | What happens there |
|---|---|---|
| Development | dev catalog (read-write for data scientists) | Experimentation; temporary data and feature tables; dev models registered here |
| Staging | staging catalog | Testing ML pipelines; assets retained only until testing is complete |
| Production | prod catalog (ideally read-only from dev) | Production data, inference tables, metric tables and production models |
Checkpoint 2 of 6· Check yourself
Security policy blocks read-only access from the development workspace to the prod catalog. What does Databricks suggest so data scientists can still develop and evaluate their code?
The documented fallback is a snapshot of production data written into the dev catalog. Production stays protected, and developers still get realistic data.
“a snapshot of production data can be written to the dev catalog to enable data scientists to develop and evaluate project code”Source: docs.databricks.com
Checkpoint 3 of 6· Exam question
A model registered in Unity Catalog as `prod.ml_team.churn_model` is currently serving traffic under the `Champion` alias. The ML team retrains a challenger version and wants to evaluate it before it takes over serving. What is the recommended way to manage this transition using Unity Catalog's model registry?
Correct answer: A — Assign the `Challenger` alias to the new model version, evaluate it, then reassign the `Champion` alias to that version once it outperforms the current one.
- A. Aliases like `Champion` and `Challenger` are mutable pointers to specific model versions within one registered model, so evaluating a challenger under its own alias and reassigning `Champion` afterward is the standard champion/challenger workflow without redeploying serving code.
- B. Splitting versions across separate registered model names loses the shared version history and lineage that Unity Catalog tracks for one model, and forces endpoint config changes that aliasing was designed to avoid.
- C. Deleting the current champion version before validating the challenger removes the ability to roll back and discards the audit trail Unity Catalog maintains across versions of the same model.
- D. Moving a model version between catalogs to free up a location is not how alias-based promotion works and adds an unnecessary data-movement step instead of simply repointing an alias.
3.Four foundations: Git, Delta, MLflow, Models in Unity Catalog
Databricks calls access control and versioning key parts of any software operations process, and it makes four concrete recommendations. First, keep pipelines and code in Git. Moving ML logic between stages then becomes moving code from the development branch to the staging branch to the release branch. Databricks Git folders sync notebooks and source code with your Git provider. Second, store both raw data and feature tables as Delta tables in a lakehouse, with access controls on who can read and modify them. Third, use MLflow to track model development, saving code snapshots, model parameters, metrics and other metadata. Fourth, use Models in Unity Catalog to manage model versioning, governance and deployment status.
| ModelOps task | Tool in Databricks |
|---|---|
| Track model development | MLflow model tracking |
| Manage model lifecycle | Models in Unity Catalog |
| Model code version control and sharing | Databricks Git folders |
| No-code model development | AutoML |
| Model monitoring | Data profiling |
Checkpoint 4 of 6· Check yourself
Which recommendation covers managing model versioning, governance and deployment status?
Git versions code, Delta stores data and feature tables, and MLflow tracks development. The model lifecycle (versions, governance, deployment status) belongs to Models in Unity Catalog.
“Use Models in Unity Catalog to manage model versioning, governance, and deployment status.”Source: docs.databricks.com
Sources1
4.Deploy code or deploy models?
Code creates models, but the two can change on different schedules. A fraud-detection pipeline might be retrained every week on new data while its code rarely changes. A large document-classification network might be retrained only occasionally because training is expensive, while the code that serves and monitors it changes often. Databricks describes two patterns for this, and they differ in what gets promoted toward production: the model artifact or the training code that produces it.
In the deploy-code pattern, which Databricks recommends in most situations, training code is written in development and the same code moves to staging and then production. The model is trained in every environment: in development during model development, in staging on a limited subset of data for integration tests, and in production on the full data. This works even when production data access is restricted. Automated retraining is safer because the training code has been reviewed and tested, and supporting code follows the same path. The cost is a steeper hand-off for data scientists, who must also be able to review training results from production. If the model has to be trained on the full dataset in staging, a hybrid works too: deploy code to staging, train there, then deploy the model to production.
In the deploy-models pattern, the model artifact is trained once in development, tested in staging and then deployed to production. Consider it when training is very expensive or hard to reproduce, when all work happens in a single workspace, or when there are no external repos or CI/CD process.
| Aspect | Deploy code (recommended default) | Deploy models |
|---|---|---|
| What moves to production | Training code; model retrained in each environment | The model artifact trained in development |
| Restricted production data | Works: model trains on production data in production | May not be viable if dev cannot reach production data |
| Automated retraining | Safer, because the training code is reviewed and tested | Tricky; production team may not accept a dev-trained model |
| Supporting code (features, inference, monitoring) | Follows the same path through staging | Must be deployed to production separately |
| Main drawback | Steeper hand-off learning curve for data scientists | Retraining and data-access constraints |
Checkpoint 5 of 6· Check yourself
A team works entirely in one Databricks workspace, has no CI/CD process, and its model takes days of GPU time to train. Which pattern fits best?
Expensive training, a single workspace and no CI/CD are exactly the conditions Databricks gives for deploy-models.
“Model training is very expensive or hard to reproduce.”Source: docs.databricks.com
Checkpoint 6 of 6· Exam question
A team runs identical training pipeline code in dev, staging, and production Databricks workspaces, and retraining is cheap because the dataset is small. Following Databricks' recommended MLOps strategy, how should a validated model move into production?
Correct answer: A — Promote the pipeline code into the production workspace so the production job retrains on production data and registers its own fresh model version.
- A. This matches Databricks' code-first promotion guidance: promoting the pipeline through environments and retraining in production keeps the deployed model consistent with production data and infrastructure rather than a possibly stale artifact.
- B. Copying a serialized artifact between environments bypasses retraining on production data and skips the governance and reproducibility benefits of running the pipeline where it will serve, so it is not the recommended approach when retraining is cheap.
- C. Re-uploading an artifact as a new run without rerunning the training code in production leaves the production environment without a reproducible pipeline, undermining lineage and future retraining.
- D. Having production depend on staging's tracking server couples environments together and removes the isolation MLOps practices rely on, since a change in staging would silently affect production.
Sources3
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.Best practice is to train the model once in development and promote that artifact through staging to production.Why is that wrong?
That is the deploy-models pattern, which is for special cases such as very expensive training. In most situations Databricks recommends deploying code and retraining the model in each environment.
Covered in Deploy code or deploy models?
2.With deploy-models, the feature engineering, inference and monitoring pipelines reach production automatically along with the model.Why is that wrong?
In the deploy-models pattern, supporting code has to be deployed to production separately. Only in deploy-code does it travel the same path as the training code.
Covered in Deploy code or deploy models?
3.Good MLOps isolation means data scientists in development should have no access to production data at all.Why is that wrong?
Ideally they have read-only access to the prod catalog so they can analyze production predictions and load production models. A snapshot in the dev catalog is the fallback when that access is impossible.
Covered in Separate environments, one catalog each
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“a set of processes and automated steps for managing code, data, and models”
↩︎ What an MLOps strategy manages“It combines DevOps, DataOps, and ModelOps.”
↩︎ What an MLOps strategy manages“Databricks recommends creating separate environments for the different stages of ML code and model development with clearly defined transitions between stages.”
↩︎ Separate environments, one catalog each“Assets written to this catalog are generally temporary and only retained until testing is complete.”
↩︎ Separate environments, one catalog each“Pipelines and code should be stored in Git for version control.”
↩︎ Four foundations: Git, Delta, MLflow, Models in Unity Catalog“Both raw data and feature tables should be stored as Delta tables with access controls to determine who can read and modify them.”
↩︎ Four foundations: Git, Delta, MLflow, Models in Unity Catalog“In most situations, Databricks recommends that during the ML development process, you promote code, rather than models, from one environment to the next.”
↩︎ Key concept“Data scientists should also be able to load production models for experimentation and analysis.”
↩︎ Exam trap 3“Ideally, data scientists working in the development workspace also have read-only access to production data in the prod catalog.”
↩︎ Prediction“a snapshot of production data can be written to the dev catalog to enable data scientists to develop and evaluate project code”
↩︎ Checkpoint“Use Models in Unity Catalog to manage model versioning, governance, and deployment status.”
↩︎ Checkpoint - 2.
“Code for training, validating, and serving the model.”
↩︎ What an MLOps strategy manages“Training data, including data quality, schema changes, and distribution changes.”
↩︎ Checkpoint - 3.
“Typically an environment (development, staging, or production) corresponds to a catalog in Unity Catalog.”
↩︎ Separate environments, one catalog each“The two patterns differ in whether the model artifact or the training code that produces the model artifact is promoted towards production.”
↩︎ Deploy code or deploy models?“Automated model retraining is safer, since the training code is reviewed, tested, and approved for production.”
↩︎ Deploy code or deploy models?“In most situations, Databricks recommends the “deploy code” approach.”
↩︎ Exam trap 1“Supporting code, such as pipelines used for feature engineering, inference, and monitoring, needs to be deployed to production separately.”
↩︎ Exam trap 2“Model training is very expensive or hard to reproduce.”
↩︎ Checkpoint