Databricks ML Professional Domains Explained

The short version

The exam has three domains: Model Development (44%), MLOps (44%), and Model Deployment (12%). Each domain is split into topics by Databricks. This page follows the topic names and skills in the exam guide marked as live on September 30, 2025, and adds practical notes. The notes about traps are our general experience, not vendor statements.

Domain 1: Model Development (44%)

This domain is the engineering of training. It has four topics.

Using Spark ML

You need to know when SparkML is the right tool and when a single-node library is better. The guide lists building pipelines, choosing the right estimator or transformer for a use case, tuning with MLlib, evaluating, and scoring in batch or streaming. It also asks you to choose between a SparkML model and a single-node model for batch, real-time, and streaming inference.

In practice: encoding categorical columns with indexers and encoders, assembling feature vectors, running a cross-validated search, and applying a fitted pipeline to a table.
Typical traps: choosing a classifier for a numeric target; forgetting that an indexer can fail on a category it never saw during fitting; assuming more parallelism in a tuning job is free, when it costs memory.
Practice: build one pipeline with a mix of column types, tune it, and score it as a batch job.

Scaling and tuning

Topics here include scaling training with SparkML and pandas Function APIs or UDFs, distributed tuning with Optuna (logged to MLflow) and with Ray, and the trade-offs between vertical and horizontal scaling. The guide also asks you to compare data and model parallelism, compare Ray with Spark, and use the pandas Function API for group-specific training.

In practice: train one model per store or per customer segment, tune on many workers, and decide when a bigger machine beats more machines.
Typical traps: mixing up the pandas function API variants; forgetting that a group must fit into the memory of one worker; picking a distributed tool for a dataset that fits comfortably in memory.
Practice: run the same tuning job on a single node and on a cluster, and note what changed.

Advanced MLflow usage

Nested runs for complex experiments, custom metrics, parameters, and artifacts logged from code, and custom model objects that include real-time feature engineering.

In practice: a parent run for a search, child runs per configuration, and a final model that points back to the search.
Typical traps: flat runs that cannot be compared; logging one metric value when you need a metric per step; leaving out files that the custom model needs at inference time.
Practice: log a model with a custom Python class and an artifact, load it, and score with it.

Advanced Feature Store concepts

Point-in-time correctness to prevent leakage, building automated feature pipelines with the Feature Engineering client, online tables created through the Databricks SDK for low-latency use, streaming feature ingestion, and on-demand features computed at request time.

In practice: training sets that join features as they were at the event time, and features used the same way in training and serving.
Typical traps: joining the latest feature value to old events, which leaks the future; using offline tables where the latency budget needs online tables.
Practice: build a training set with a timestamp lookup and compare it with a plain join.

Domain 2: MLOps (44%)

The domain is as big as Model Development, and many candidates under-prepare it.

Model lifecycle management

Describe and implement the pipeline components that move a model between environments in the deploy-code strategy, and map Databricks features to lifecycle activities. Think Unity Catalog models, aliases, and versioning.

Typical traps: thinking in legacy stages when Unity Catalog uses aliases; copying models between environments when the strategy says to deploy the code.

Validation testing

Unit tests for notebook functions, knowing which tests belong in which environment, designing an integration test across feature engineering, training, evaluation, deployment, and inference, and comparing ways to organize functions and tests.

Typical traps: running a slow end-to-end test on every change; forgetting which pipeline stages a change touches.

Environment architectures

Designing scalable environments and defining ML assets with Databricks Asset Bundles: serving endpoints, MLflow experiments, and registered models.

Practice: write a small bundle, validate it, deploy it to two targets, and run a job from it. Remember the order of validate, deploy, run.

Automated retraining

Retraining workflows triggered by drift or by degraded performance alerts, and a strategy for choosing the best model during retraining.

Typical traps: picking a metric that ignores the cost of mistakes; promoting a model that wins overall but loses on one customer segment.

Drift detection and Lakehouse Monitoring

The largest topic. You apply statistical tests from the drift metrics table to numerical and categorical data, choose the right table type and feature, build monitors for snapshot, time series, or inference tables, define custom metrics, slice by granularity, set alerts, compare against a baseline or consecutive windows, track performance in an inference table, and watch endpoint health such as latency, request rate, errors, CPU, and memory.

Typical traps: confusing the profile types; confusing a baseline comparison with a consecutive-window comparison; expecting metric tables to update before the monitor refreshes.
Practice: create one monitor of each type and read the metric tables it produces.

Domain 3: Model Deployment (12%)

Deployment strategies

Compare blue-green and canary, judge their fit for high-traffic applications, and implement a rollout with Databricks Model Serving.

Typical traps: sending all traffic to a new model at once on a business-critical path; confusing a canary traffic split with a full cutover.

Custom model serving

Register a custom PyFunc model with its artifacts in Unity Catalog, query it through REST or the MLflow Deployments SDK, and deploy it through the SDK, REST, or the UI.

Typical traps: a file read at prediction time that was never logged with the model; hand-building HTTP calls when an SDK call is simpler.

Where to focus

Because Model Development and MLOps carry 88% of the exam, put most of your hours there. Model Deployment is small, but its ideas, such as canary rollouts and PyFunc packaging, also appear in MLOps questions.

More guides for DATABRICKS-MLP

Next step

Turn the topics into a schedule with the study plan, and try the sample questions. For full-length practice, see the Databricks ML Professional practice tests. The topic names come from the Databricks exam guide.

Frequently asked questions

Which domain should I study first?

Start with Model Development, because the MLOps topics assume you already know how models are trained, logged, and registered.

Are the topics listed in the exam in the same order?

The guide lists them in this order, but it does not say how questions are ordered on the exam, so practice them mixed as well as one by one.

Try these practice exams