Databricks Machine Learning · Topic 1 of 6
MLOps Strategy, ML Runtimes and Promotion
Databricks ML Associate: MLOps best practices, why Databricks Runtime for ML helps, and when to promote training code versus promoting a trained model.
- 5 min
- MLOps rests on separate environments, code in Git, automated tests, tracked runs, governed assets and monitoring.
- Unity Catalog catalogs (dev, staging, prod) are a common way to separate environments.
- Databricks Runtime ML preinstalls common ML libraries with compatible versions and supports GPU instance types.
What it is
MLOps is the set of practices that moves a model from a notebook to a reliable production system and keeps it healthy there. It combines DevOps (code in version control, tests, automation), DataOps (governed data) and ModelOps (tracked runs, a registry, monitoring).
Databricks Runtime for Machine Learning (Databricks Runtime ML) is the cluster image you pick for that work. The exam also asks which asset you move between environments: the training code or the trained model.
How it works
MLOps best practices
| Practice | What it looks like on Databricks |
|---|---|
| Separate environments | Development, staging and production, as separate workspaces or separate catalogs such as dev, staging and prod |
| Everything as code | Notebooks and modules in Git through Databricks Git folders, reviewed by pull request |
| Automated testing and CI/CD | Unit and integration tests run before code reaches production |
| Track every experiment | Each training attempt is an MLflow run with parameters, metrics and the model |
| Govern data and models | Feature tables and registered models in Unity Catalog with access control and lineage |
| Automate jobs | Training, scoring and retraining run as scheduled Lakeflow Jobs, not by hand |
| Monitor | Watch input data drift and prediction quality, then retrain when quality drops |
The theme is reproducibility. Anyone should be able to rebuild a production model from versioned code, versioned data and a logged run.
A common pattern on Databricks keeps one Unity Catalog metastore and uses a catalog per environment. Models are then named like dev.ml.churn and prod.ml.churn, and permissions on each catalog control who can write to production.
Advantages of ML runtimes
Databricks Runtime ML is a Databricks Runtime with machine learning and deep learning tools preinstalled.
| Advantage | Why it matters |
|---|---|
| Preinstalled libraries such as scikit-learn, XGBoost, PyTorch, TensorFlow and MLflow | No time lost installing and matching versions |
| Versions tested together | Fewer dependency conflicts between libraries |
| GPU instance types available | Deep learning training without building your own image |
| AutoML access | A no-code UI and Python API to get a baseline quickly |
| Dedicated access mode set for Unity Catalog | Choosing the Machine learning option configures the cluster to read governed data |
You can still add packages per notebook with %pip install, which keeps the cluster image clean for other users. Pinning the runtime version also pins the library versions, which makes a run reproducible later.
Promoting code versus promoting models
There are two ways to move work from development to production.
| Deploy code | Deploy models | |
|---|---|---|
| What moves | The training code | The trained model artifact |
| Where the model is trained | In each environment, finally on production data | Once, in development |
| Preferred when | Production data cannot be read from development; retraining is automated and frequent | Training is very expensive or hard to reproduce; a single workspace; no CI/CD in place |
| Benefit | Retraining is safer because the code was reviewed and tested | Simpler handoff, train only once |
| Downside | Steeper handoff for data scientists | Retraining is hard to automate; supporting code ships separately |
Databricks recommends deploy code in most situations. With deploy models in Unity Catalog, you can copy a tested version from one catalog to another with MlflowClient().copy_model_version.
from mlflow import MlflowClient
client = MlflowClient(registry_uri="databricks-uc")
client.copy_model_version(
src_model_uri="models:/staging.ml.churn/3",
dst_name="prod.ml.churn")How the exam asks about this
- "Data scientists cannot read production tables, and the model must retrain weekly on fresh production data." Deploy code: promote the reviewed training code and train in production.
- "Training a large model takes four days on GPUs and the team uses one workspace without CI/CD." Deploy models: train once and promote the model.
- "A team wastes time installing PyTorch and matching library versions on each cluster." Use Databricks Runtime ML, which has them preinstalled and tested together.
What to remember for the exam
- MLOps rests on separate environments, code in Git, automated tests, tracked runs, governed assets and monitoring.
- Unity Catalog catalogs (dev, staging, prod) are a common way to separate environments.
- Databricks Runtime ML preinstalls common ML libraries with compatible versions and supports GPU instance types.
- Deploy code is the default recommendation, and is required when development cannot reach production data.
- Deploy models fits expensive or hard to reproduce training and simple single workspace setups.
- Automate retraining and scoring with jobs, and monitor data drift and model quality.
"Deploy models" does not mean "never retrain". It means the artifact is trained once and moved; if a question stresses frequent automated retraining on production data, deploy code is the better answer.
Common mistakes
Treating MLOps as only a deployment step. MLOps covers the whole life cycle, from versioned code and tracked runs to monitoring after release. An answer that stops at "serve the model" misses monitoring and retraining.
Using a standard runtime for ML work. A standard Databricks Runtime lacks the bundled ML libraries. Installing them by hand on every cluster wastes time and risks version conflicts that the ML runtime already solved.
Picking deploy models when data access is restricted. If development cannot read production data, a model trained in development never saw the real data. Promoting the code lets the model train where the data lives.
Check yourself
Why does Databricks usually recommend deploying code rather than models?
Retraining in production then uses training code that was reviewed and tested, and it works even when development cannot access production data.
When is deploying a model the better choice?
When training is very expensive or hard to reproduce, or when the team works in a single workspace without CI/CD, so training once and promoting the artifact is simpler.
What are two advantages of Databricks Runtime ML?
It preinstalls common ML libraries such as scikit-learn, PyTorch and MLflow in tested, compatible versions, and it offers GPU instance types for deep learning.
Topic 1 of 6 in Databricks Machine Learning
Test yourself on Databricks Machine Learning
The full Databricks Machine Learning Associate question bank has 600 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by Databricks. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.