Databricks Certified Machine Learning Professional: Complete 2026 Study Guide

Exam facts, status, and scope

The official credential name is Databricks Certified Machine Learning Professional. The site uses Databricks ML Professional as the displayed short label. The official page does not publish an alphanumeric exam code, so databricks-ml-professional is only PrepKloud's internal identifier.

As verified on August 21, 2026, Databricks lists a 120-minute proctored certification exam with 59 scored multiple-choice questions and no test aids. The page lists online or test-center delivery. No prerequisite is required, but related training and at least one year of hands-on experience performing the guide's ML tasks are highly recommended. The credential is valid for two years, with recertification by taking the current exam. Databricks notes that unidentified unscored content may be present and does not affect the score.

The official weights are 44% Model Development, 44% ML Ops, and 12% Model Deployment. PrepKloud translates those proportions into an exact independent 50-question bank of 22, 22, and 6 items. That deliberate practice-bank size does not imply that the official exam has 50 questions.

Build a lifecycle mental model

The exam is easier when every feature maps to a lifecycle stage. Data and feature pipelines create model inputs. Training and tuning produce candidate artifacts. MLflow Tracking records experiments. Unity Catalog governs registered models and immutable versions. Tests establish code and stage compatibility. Databricks Asset Bundles define deployable resources and targets. Workflows orchestrate jobs. Lakehouse Monitoring measures data, model, and inference behavior. Model Serving hosts online endpoints. Aliases express mutable intent such as champion, while exact model versions preserve evidence.

Ask three questions for each scenario. First, is the bottleneck data processing, model computation, workflow coordination, governance, monitoring, or request serving? Second, which identity, artifact, table, and version cross the boundary? Third, what evidence allows promotion or rollback? These questions prevent common category errors such as using endpoint metrics to select a training algorithm or treating model registration as production approval.

Domain 1: Model Development

Spark ML pipelines and evaluation

Spark ML is appropriate when training data and supported preprocessing or algorithms need distributed Spark execution. Its DataFrame-based Pipeline API composes Estimators and Transformers. An Estimator learns parameters and produces a Transformer; a fitted classifier is one example. A Transformer converts one DataFrame to another. For mixed categorical and numeric data, a common order is StringIndexer, OneHotEncoder, VectorAssembler, and then the estimator. Keeping preprocessing in the Pipeline reduces divergence between training and scoring.

Use TrainValidationSplit or CrossValidator with a parameter grid and evaluator according to computation budget. Cross-validation adds robustness but multiplies training work. Do not use the final test data for repeated tuning. For imbalanced classification, choose metrics such as area under the precision-recall curve and inspect precision, recall, thresholds, and slices. For regression, understand RMSE, MAE, and $R^2$ according to error costs. The best evaluator value is not automatically the best business decision.

For batch inference over large Delta tables, loading a PipelineModel and transforming a Spark DataFrame is natural. For compatible streaming use cases, apply deterministic trained transformations in Structured Streaming with explicit checkpoint, schema, state, and latency behavior. For synchronous low-latency requests, Model Serving is generally more suitable than launching Spark work per row.

Scaling and tuning

Vertical scaling gives one process more CPU, memory, or accelerators and can be simplest for a single-node library. Horizontal scaling divides work across machines but adds coordination and data-transfer costs. Data parallelism replicates the model and distributes mini-batches; each replica generally must hold the model. Model parallelism partitions a model or its computation when it cannot fit or run efficiently on one accelerator.

Grouped pandas function APIs are useful when many independent groups each need a small model or inference operation. They distribute group-level Python work but can fail when one group is enormous, artifacts are too large, or dependencies are inconsistent. Ray supports Python-native distributed training and tuning. Spark is strongest around distributed data and Spark ML pipelines. Compare frameworks by data movement, model library, scheduling, fault behavior, observability, and team operations—not popularity.

Optuna can coordinate hyperparameter search, including distributed execution patterns, while MLflow tracks trials. Bound concurrency to available resources. Record failed and pruned trials rather than looking only at winners. A faster search that overloads shared storage, hides failures, or evaluates non-comparable data is not better.

Advanced MLflow and Feature Engineering

Nested MLflow runs represent a tuning study as a parent and individual trials as children. Log parameters, metrics, custom plots, artifacts, signatures, input examples, dependency environment, source revision, and data-window identity. Avoid secrets and raw sensitive rows. Reproducibility requires more than an artifact file: it requires the code, environment, features, and evaluation context that produced it.

Point-in-time correctness is central to historical training. For an event at time $t$, retrieve only feature values known at or before $t$. Using the latest value introduces future leakage and inflates offline performance. Feature tables need stable primary keys and timestamps. Automated pipelines should be idempotent, validate schema and quality, and capture lineage.

Online tables or supported online stores provide low-latency feature access for serving. Synchronization freshness, key availability, permission, and failure behavior must be monitored. On-demand features calculate values at request time from live inputs and stored context. Package and test this computation so online and offline definitions do not diverge. Streaming feature pipelines additionally need event-time, late-data, checkpoint, state, and replay semantics.

Domain 2: ML Ops

Lifecycle and testing

A deploy-code strategy promotes source-controlled code and environment-specific configuration through development, test, and production-like stages. Separate catalogs, schemas, workspaces, identities, or permission boundaries according to risk. Personal notebooks and credentials should not be the production delivery mechanism.

Unit tests isolate feature, metric, threshold, selection, and schema functions with deterministic inputs. Integration tests exercise contracts among feature engineering, training, evaluation, registration, deployment, and inference. A model hyperparameter change may leave feature code untouched, but it still changes the trained artifact, metrics, serialization, resource behavior, and endpoint output; therefore training through inference integration should run.

Place reusable code in importable, versioned modules and keep notebooks thin. This reduces hidden state and duplication. Test nulls, unexpected categories, empty partitions, schema drift, delayed labels, malformed requests, serialization, dependency resolution, permissions, timeouts, and cleanup.

Databricks Asset Bundles and environments

Databricks Asset Bundles describe resources and deployment targets in source control. Depending on current schema support, a project can define jobs and other resources, variables, target overrides, permissions, and references to experiments, models, and endpoints. Validate the bundle, deploy to development, run tests, then promote the same reviewed commit with target-specific configuration.

A secure environment architecture separates developer, CI deployer, trainer, monitoring, endpoint, and approver authority. Use service principals for automation, secret management for credentials, cluster policies, narrow catalog privileges, and protected branches. Reproducible infrastructure does not justify granting every target the same broad permissions.

Automated retraining and model selection

Retraining may start from schedule, new labels, data drift, model-performance degradation, or another governed signal. The trigger should preserve the exact baseline, data window, code revision, and reason. Retraining produces a candidate; it should not automatically make that candidate production champion.

A champion-challenger policy compares candidates and incumbent on fixed, business-relevant metrics and constraints. Include important slices, uncertainty, calibration or threshold behavior, latency, memory, artifact size, explainability requirements, and cost. Require minimum improvement or non-inferiority rules and block promotion when data quality or test evidence is missing.

Lakehouse Monitoring and alerting

Choose a profile from table semantics. Snapshot monitoring fits complete current-state replacements without event-time windows. Time-series monitoring uses a timestamp column to calculate windowed metrics. Inference monitoring connects requests, predictions, model identity, and optional labels to model-performance analysis.

Lakehouse Monitoring produces data-quality and drift metrics. Numerical comparisons may use statistics such as Kolmogorov-Smirnov; categorical comparisons may use metrics such as Jensen-Shannon divergence. Interpret results with sample size, seasonality, multiple comparisons, effect size, and business meaning. Significant drift is a signal for investigation, not proof that retraining will improve outcomes.

Slices reveal degradation hidden by global averages, but too many sparse combinations create unstable estimates, privacy risk, and metric explosion. Custom metrics can represent domain-specific outcomes such as value-weighted loss. Version and test their calculations. For endpoint health, track latency, request rate, error rate, CPU, and memory separately from prediction quality.

Alerts should have a precise condition, persistence, suppression, owner, context, and runbook. Track monitor refresh, ingestion delay, label availability, metric-table freshness, and alert delivery. If the monitor stops updating, the state is unknown or degraded—not healthy.

Domain 3: Model Deployment

Canary and blue-green strategies

A canary routes a small share of eligible traffic to a candidate and compares outcomes with the incumbent. Predefine allocation, minimum sample, duration, metrics, slices, guardrails, and rollback. Avoid interpreting tiny samples or non-comparable traffic as strong evidence. Databricks Model Serving can configure multiple served entities and traffic percentages for supported endpoint patterns.

Blue-green keeps complete current and candidate environments separately available and switches routing after validation. Rollback can be simple because the previous environment remains intact, but parallel capacity increases cost. The choice depends on state, traffic, endpoint configuration, model dependencies, observability, and rollback objectives.

Custom PyFunc and Unity Catalog

An MLflow custom PyFunc packages Python prediction logic that does not fit a built-in flavor. Implement the model contract, log required files as artifacts, define dependencies, add a signature and input example, and test loading in a fresh environment. Never rely on a developer's local path. Validate nulls, unexpected values, batch shape, output schema, thread safety where relevant, and resource use.

Register the model in Unity Catalog to apply centralized governance, permissions, lineage, and version lifecycle. Versions are immutable evidence references. Aliases are useful mutable labels for intent, such as Champion, but a long-running evaluation should resolve and record the exact incumbent version. Otherwise an alias move silently changes the comparison baseline.

Deployment and invocation APIs

Model Serving endpoints can be created or updated through supported user interfaces, REST APIs, Databricks SDKs, or MLflow deployment abstractions. Automation should be idempotent, use a machine identity, poll asynchronous readiness, save a sanitized configuration snapshot, and run smoke tests. Creation success is not readiness.

External applications query endpoints through authenticated REST or a supported SDK. Validate request schema, response schema, timeouts, retries, rate limits, and error handling. Retry only operations that are safe to repeat. Minimize inference logging because requests can contain sensitive features. Correlate predictions to exact served versions and preserve rollback targets.

An eight-week preparation plan

Week 1: Build Spark ML Pipelines and explain every Estimator, Transformer, parameter, evaluator, and schema transition.

Week 2: Practice tuning and inference. Compare CrossValidator, batch transform, streaming transform, and online serving. Use fixed final-test data.

Week 3: Compare vertical, horizontal, data, and model parallelism; Spark, pandas function APIs, Optuna, and Ray. Measure overhead rather than memorizing slogans.

Week 4: Use nested MLflow runs, custom artifacts, Feature Engineering, point-in-time joins, online tables, on-demand features, and streaming features.

Week 5: Package reusable code, write unit and integration tests, design deploy-code environments, and deploy resources through Asset Bundles.

Week 6: Implement governed retraining and candidate selection. Record exact versions, metrics, constraints, approvals, and rollback.

Week 7: Build snapshot, time-series, and inference-monitor examples. Practice statistical drift interpretation, slices, custom metrics, alerting, and endpoint-health diagnosis.

Week 8: Package a custom PyFunc, register it, automate a test endpoint, invoke it, run canary and blue-green scenarios, roll back, complete projects, and review the exact 22/22/6 question set.

Three projects that prove applied skill

The distributed model development and feature platform combines Spark ML, tuning, nested MLflow, point-in-time features, online tables, on-demand features, and batch, streaming, and endpoint inference. It injects skew, stale features, checkpoint, permission, schema, and concurrency failures.

The production MLOps lifecycle uses Databricks Asset Bundles, isolated targets, service principals, tests, Unity Catalog versions and aliases, automated retraining, Lakehouse Monitoring, alerts, incident response, exact-version rollback, cost controls, and verified destroy behavior.

The safe custom rollout platform builds a custom PyFunc with an artifact, registers it, automates endpoints through SDK or REST, authenticates synthetic clients, compares canary and blue-green, records exact versions, injects package and serving failures, restores the incumbent, and removes all endpoint and model resources.

How to answer professional scenarios

Identify the constrained layer first. A model too large for one GPU suggests model parallelism, while a large dataset with a manageable model suggests data parallelism or Spark. Thousands of independent group models suggest grouped pandas APIs. A one-row low-latency request suggests Model Serving; a nightly table suggests distributed batch inference.

For feature questions, draw prediction time and reject any future value. For MLOps questions, distinguish unit tests from end-to-end integration. For retraining, separate trigger, candidate creation, evaluation, approval, rollout, and rollback. For monitoring, identify snapshot, time-series, or inference table semantics and never interpret drift without context. For deployment, resolve aliases to immutable versions and remember that endpoint creation is asynchronous.

Evaluate every option, especially on multi-step lifecycle questions. An answer can be technically valid but incomplete if it omits feature compatibility, evaluation, deployment tests, identity, or rollback. Prefer reproducible evidence over “latest,” “largest,” or “trained successfully.”

Common preparation mistakes

• Collecting large Spark data to the driver. Preserve distributed execution or deliberately bound the handoff.
• Confusing Transformers and Estimators. One applies; the other fits and produces a Transformer.
• Using the final test set during tuning. Repeated selection consumes its independence.
• Using latest feature values for historical rows. This creates future leakage.
• Logging everything to MLflow. Secrets and sensitive records do not belong in experiment metadata.
• Keeping production logic only in notebooks. Package reusable code for tests and review.
• Equating retraining with promotion. A candidate must pass fixed gates.
• Calling drift model failure. Drift and outcome degradation are related but distinct evidence.
• Using global metrics only. Important slices can fail while the average remains stable.
• Treating a moved alias as immutable. Record exact model versions.
• Assuming endpoint creation means readiness. Poll and run authenticated smoke tests.
• Leaving endpoints running after labs. Serving capacity can continue to incur cost.

Readiness checklist

You are approaching readiness when you can build and explain a Spark ML Pipeline; choose evaluation and inference patterns; compare scaling and tuning frameworks; log nested MLflow runs; implement point-in-time and online features; design deploy-code environments; distinguish unit and integration tests; deploy Asset Bundles; build governed retraining; choose monitor profiles; interpret drift and slices; design alerts; diagnose endpoint health; package custom PyFunc models; govern Unity Catalog versions; and run canary, blue-green, REST, SDK, and rollback workflows.

Use the five-phase roadmap, answer the 50 original questions, review the 40 flashcards, and complete all three projects. The independent bank is not the official exam and cannot predict a passing result.

Official references

• Databricks Certified Machine Learning Professional
• Official exam guide
• Spark ML on Databricks
• Distributed training
• MLflow Tracking
• Point-in-time feature joins
• Databricks Asset Bundles
• Lakehouse Monitoring
• Manage model lifecycle in Unity Catalog
• Model Serving
• MLflow custom Python models
• MLflow Deployments SDK

Continue learning

• Five-phase Databricks ML Professional roadmap
• 50 original practice questions
• 40 flashcards
• Three hands-on projects
• Databricks Generative AI Engineer roadmap
• Machine learning and MLOps roles
• PrepKloud editorial policy

Frequently asked questions