Study for the Databricks Certified Machine Learning Professional by practicing tool-selection decisions, not definitions. For every topic, learn which two or three platform options could plausibly fit a described pipeline, what distinguishes them, and what consequences follow from picking the wrong one. Work through the scenario contrasts here, log runs and promote models in a sandbox workspace, and finish with the readiness checks at the end. The exam also assesses ANSI-standard SQL, so read and write standard SQL against lakehouse tables during your review.
Reading each question as a tool-selection decision
Treat every scenario question as a choice among two or three named Databricks tools or lifecycle actions. Name the lifecycle stage in the stem first, then eliminate options that solve a different stage's problem.
Model Development and ML Ops carry roughly equal, dominant weight on the published domain list, while Model Deployment forms a smaller slice, so your preparation time should mirror that distribution. A tuning stem may also test whether trials are tracked and comparable, so read past the search itself and check the stem for logging, evaluation, and registry requirements. When you hesitate between two options, ask which lifecycle stage each one serves; the option answering a different stage than the stem's stated need is the weaker pick.
Build the habit of naming the stage before naming the tool. When a stem describes training a model, ask whether the actual ask concerns logging experiments, tuning, feature lineage, or packaging. When it describes a model already in production, the ask is likely registry promotion, monitoring, retraining automation, or serving. This two-step reading keeps you from selecting answers that are technically true but address a requirement the question never raised.
MLflow layers: tracking runs versus managing models in the registry
Distinguish MLflow Tracking, which records parameters, metrics, and artifacts per run, from the Model Registry, which governs versioned, promotable model artifacts. A logged run is reproducible evidence; the registry entry is the governed object downstream systems consume.
Tracking answers: what did we try, with which parameters, and how did it perform? The Registry answers: which exact artifact is approved for a given environment, and how did it get there? A common confusion is treating a logged run as the deliverable. If a scenario asks who can approve a model for production or how a version reaches an environment, the answer lives in registry governance, not in tracking.
Practice the linkage explicitly: log a run with parameters, metrics, and a model artifact, then register that artifact as a new model version with its source run attached. Notice what each layer enables afterwards—comparing runs to justify the choice, and using the registry to control deployment. If you can explain why a notebook run with better metrics should still pass through registry review before reaching production, you have internalized the distinction.
Registry lifecycle: promoting versions with aliases and governance gates
Model lifecycle questions hinge on controlled promotion: a candidate version earns a production alias only after passing evaluation. Compare that gate against ad hoc version swaps, where a training-metric improvement replaces the served model without validation.
Aliases point to a specific model version by a human-readable name, such as champion, so downstream consumers reference the alias rather than a hard-coded version number. Promotion then becomes an auditable act: evaluate the candidate against the current champion and update the alias only if the candidate wins. Scenario stems that mention approval workflows, staging and production separation, or traceable rollbacks are pointing you at registry governance.
Scenario 1: A team retrains nightly, registers each new version, and points its serving endpoint at the latest version because training accuracy rose. Weeks later, a serving-path feature computed with different defaults than in training degrades quality silently. The better decision gates promotion: attach a signature and feature lookups to the logged model, evaluate the candidate against the champion, and update the production alias only through that gate. Unevaluated version swapping converts every training fluctuation into a production change, and skew goes undetected until consumers notice.
Feature engineering: when the Feature Store is the right answer
Reach for Databricks Feature Store concepts when a scenario mentions reuse across teams, automatic feature lookup at inference, or lineage between training and serving. Notebook-scoped feature code is the weaker choice whenever those requirements appear.
The core problem the Feature Store solves is training/serving consistency: features computed once as governed tables, with models logging which feature lookups they depend on, so inference retrieves the same definitions without duplicated logic. When a stem describes data scientists independently reimplementing the same aggregation, or a served model drifting from training behavior because feature code was copied into a serving script, the intended direction is publishing those features as feature tables referenced in both training and inference.
Contrast this with cases where the Feature Store is not the point. If the question is about packaging a one-off transformation so it applies identically at inference, a SparkML pipeline stage within the logged model may suffice, because the transformation travels with the model. The distinction to train: pipeline stages solve packaging of transformations; feature tables solve reuse, discovery, and consistent online lookup. In your sandbox, train against a small feature table with a lookup and observe that the serving path needs no feature code of its own.
Model development: SparkML pipelines and distributed hyperparameter tuning
Development questions combine two decisions: packaging transformations and estimators into a SparkML Pipeline so preprocessing travels with the model, and selecting a distributed tuning approach whose search strategy matches the scenario's budget and parallelism.
A SparkML Pipeline chains transformers and estimators into one object that can be fit, logged, and reloaded, which prevents preprocessing being applied differently at inference. Tuning layers on top: compare a broad randomized search against a structured strategy that adapts based on earlier trials. Match the strategy to the facts stated in the stem—how large the search space is, whether trials run in parallel across a cluster, and whether each fit is expensive enough that an adaptive search saves real compute.
When you read a tuning stem, extract three facts before answering: the size of the search space, the cost of a single fit, and whether trials are logged to MLflow for comparison. A plausible mistake is a notebook loop over a parameter grid with results copied into a spreadsheet; the better decision runs trials as parallel, tracked runs so every configuration, metric, and artifact is comparable in one place. Model selection for registry promotion depends on that traceable comparison, not on whichever run a teammate remembers favorably.
MLOps: drift monitoring and gated retraining with Declarative Automation Bundles
Production questions connect Lakehouse Monitoring's drift signals to a governed response: an automated retraining workflow with evaluation gates, packaged and deployed through Declarative Automation Bundles in CI/CD rather than manual notebook runs.
Monitoring and retraining are two decisions a scenario can join. Lakehouse Monitoring watches input data and prediction distributions for drift; detecting drift does not by itself justify replacing the model. The governed response is a retraining workflow that assembles fresh data, retrains, evaluates the candidate against the champion, and promotes only on a passing comparison. When a stem describes an alert that triggers unconditional nightly retraining, treat that as the flawed option.
Scenario 2: Monitoring shows input distributions shifting after an upstream schema change; the team's automation retrains daily on all incoming data and updates the production alias directly. A quick check passes, but the change altered a column's units, so the retrained model learned a subtly different mapping, and regressions surface in a segment the check misses. The better decision validates data quality, evaluates the candidate against the champion, and promotes through a bundle-driven CI/CD process with the alias change recorded. Monitoring is a trigger for gated retraining, not a substitute for evaluation, and Declarative Automation Bundles keep that workflow versioned and testable like any other code.
Deployment modes and rollout management: matching serving to the workload
Deployment questions contrast batch scoring, streaming, and real-time serving endpoints. Match the mode to the latency, volume, and trigger described in the stem, and manage rollouts through registry aliases so switching versions is controlled and reversible.
Batch scoring suits scheduled, high-volume scoring where results are consumed later; real-time serving endpoints suit interactive requests needing low-latency responses; streaming sits between them for near-real-time continuous data. A stem mentioning a nightly report points to batch; one describing an application calling the model per user request points to a serving endpoint. Overbuilding—standing up an endpoint for a nightly batch job, or batch-scoring a use case that needs per-request responses—are the two mismatch directions to check every option against.
Rollout management ties deployment back to the registry. Because consumers reference an alias, you can shift between model versions by repointing the alias, test a candidate behind the same interface, and roll back by restoring the previous alias target. Isolate the two decisions in any deployment stem—which serving mode matches the workload's latency and volume, and which promotion mechanism satisfies the governance requirement—rather than treating the stem as one undifferentiated choice. Note: registration, delivery format, and validity details live on Databricks' certification page, linked below.
Practical exercise with a self-check rubric: in a sandbox workspace, take one small dataset through the full lifecycle—publish a feature table, train a SparkML pipeline with tracked hyperparameter tuning, register the winner, add an evaluation-gated promotion step, deploy to a serving endpoint using feature lookups, and set up monitoring on inputs and predictions. Score yourself against this rubric, aiming for all five before your exam: (1) every tuning trial is a logged run with parameters and metrics comparable in one view; (2) the registered model has a signature and a traceable source run; (3) promotion requires a candidate-versus-champion evaluation, with the alias change recorded; (4) the serving path contains no feature logic of its own; (5) you can name the signal that would trigger retraining and the gate standing between that trigger and the alias update. Gaps map back to the matching section above—reread it and repeat the sandbox step before moving on.
- Batch scoring: choose when output timing is measured in hours and volume is high.
- Real-time serving endpoint: choose when per-request latency is the binding requirement.
- Alias-based rollout: choose when you need controlled, reversible promotion between versions.
- Readiness check: you can name the promotion gate, the monitoring signal, and the serving mode for a described workload without hesitation.
- Readiness check: you can explain, out loud, why each wrong option in a practice scenario fails.
| Decision factor | Batch scoring | Real-time serving endpoint |
|---|---|---|
| Latency requirement | Minutes to hours are acceptable | Per-request response needed |
| Typical trigger | Scheduled job | Application or API call |
| Feature supply | Features joined in the scoring job | Feature lookups resolved at request time |
| Rollout control | Job points at a registry version or alias | Endpoint references the model; alias governs swaps |
| Common mismatch to avoid | Using batch where users wait on results | Standing up an endpoint for a nightly report |
References and further reading
Use these references to explore the concepts and check the latest information from the relevant organizations.