Databricks Expert

Databricks-ML-Professional

Databricks Certified Machine Learning Professional

The Databricks Certified Machine Learning Professional validates advanced expertise in designing and implementing production-grade machine learning systems on the Databricks platform. This expert-level certification is designed for experienced ML engineers and data scientists who architect scalable ML solutions and lead machine learning initiatives in production environments.

The exam covers five advanced domains: implementing advanced feature engineering techniques including feature stores, automated feature discovery, and feature serving architectures, managing the complete model lifecycle from experimentation through production deployment and retirement, building production ML pipelines with orchestration, error handling, and automated retraining, monitoring model performance with drift detection, data quality checks, and automated alerting, and using advanced MLflow capabilities including multi-model serving, A/B testing, and model governance. Candidates must demonstrate expertise with distributed ML frameworks, hyperparameter optimization at scale, and CI/CD for ML.

This certification is ideal for senior ML engineers, ML platform architects, and technical leads who design enterprise ML systems on Databricks. Key skills tested include designing scalable feature engineering pipelines, implementing MLOps best practices, orchestrating complex ML workflows, building model monitoring and observability solutions, and architecting multi-stage model deployment strategies with rollback capabilities. The exam requires hands-on experience with production ML deployments and was last updated in 2024.

Updated 2024 AI & Machine Learning

Questions

Practice Tests

70%

Pass Score

Views

Total Attempts

Avg. Score

Pass Rate

Discussions

Practice Tests Flash Cards Exam Topics Cheat Sheet

€5.00

Databricks ML Professional Practice Exam 1

Comprehensive 50-question practice exam covering all five Databricks ML Professional domains: Advanced Feature Engineering, Model Lifecycle Management, Production ML Pipelines, Model Monitoring and Drift Detection, and Advanced MLflow and Model Serving.

50 Q 120 minutes 70%

Test Drive

€5.00

Databricks ML Professional Practice Exam 2

50 Q 120 minutes 70%

Test Drive

€5.00

Databricks ML Professional Practice Exam 3

Comprehensive 50-question practice exam covering advanced feature engineering, model lifecycle management, production ML pipelines, model monitoring and drift detection, and advanced MLflow and model serving on the Databricks platform.

50 Q 120 minutes 70%

Test Drive

€5.00

Databricks ML Professional Practice Exam 4

50 Q 120 minutes 70%

Test Drive

€5.00

Databricks ML Professional Practice Exam 5

50 Q 120 minutes 70%

Test Drive

€5.00

Databricks ML Professional Practice Exam 6

50 Q 120 minutes 70%

Test Drive

Unlock All Content for Databricks-ML-Professional

6 Practice Test(s) + Flash Cards — 3 months access

€39.99 €26.99 Save 30%

or included with Monthly subscription / Content Bundle

Databricks-ML-Professional Cheat Sheet

Quick reference guide - 6 sections

Free Access

Databricks Certified Machine Learning Professional

The Databricks Certified Machine Learning Professional exam is the advanced-level ML certification from Databricks, targeting senior ML engineers and MLOps practitioners who design, build, deploy, and operate production machine learning systems on the Databricks Lakehouse Platform. Unlike the Associate exam, which focuses on building and evaluating models, the Professional exam emphasizes the end-to-end ML lifecycle in production: advanced MLflow experiment tracking, the Model Registry and Unity Catalog governance, real-time and batch deployment patterns, Model Serving endpoints, Lakehouse Monitoring, data and concept drift detection, webhook-driven automation, CI/CD for ML, and production-grade retraining workflows. Candidates should have at least one to two years of hands-on experience shipping ML models to production on Databricks, working comfortably with MLflow APIs, Unity Catalog, Delta Lake, Spark Structured Streaming, Delta Live Tables, Feature Store, Hyperopt/Optuna for distributed hyperparameter tuning, and REST-based serving endpoints. The exam tests scenario-based decision making across experimentation, lifecycle management, deployment, and monitoring rather than simple API recall.

Exam Details

Exam Code	Databricks Certified Machine Learning Professional
Duration	120 minutes (2 hours)
Number of Questions	60 multiple-choice questions
Passing Score	70% (approximately 42 correct answers)
Cost	$200 USD
Validity	2 years from date of certification
Question Types	Multiple choice (single and multiple select)
Testing Options	Online proctored via Kryterion Webassessor
Recommended Experience	1-2+ years hands-on building and operating ML systems on Databricks in production, with deep MLflow and MLOps experience
Certification Level	Professional (advanced)

Domain Weights

Domain	Weight
Domain 1: Experimentation	35%
Domain 2: Model Lifecycle Management	25%
Domain 3: Model Deployment	25%
Domain 4: Solution and Data Monitoring	15%

Study Tips

Domain 1 (Experimentation, 35%) is the heaviest; master advanced MLflow usage including nested runs, parent-child run structures, experiment permissions, and autologging customization for scikit-learn, XGBoost, LightGBM, PyTorch, and Keras
Domain 2 (Lifecycle, 25%) requires deep knowledge of MLflow Model Registry stages (None, Staging, Production, Archived), stage transition requests/approvals, webhooks, tags, aliases, and Unity Catalog model governance
Domain 3 (Deployment, 25%) covers Model Serving endpoints, Spark pyfunc UDFs for batch inference, streaming inference patterns, A/B traffic splitting, canary deployments, and containerized custom serving
Domain 4 (Monitoring, 15%) tests Lakehouse Monitoring (InferenceLog profile type), data drift, concept drift, feature drift detection, DLT expectations, retraining triggers, and alerting workflows
Hyperopt with SparkTrials is heavily tested: understand TPE (Tree Parzen Estimator) vs random vs adaptive TPE, when nested MLflow runs are created, and early stopping via fmin loss_threshold
Know webhooks end to end: event types (MODEL_VERSION_CREATED, TRANSITION_REQUEST_CREATED, etc.), HTTP endpoint targets, job webhooks, and HMAC-based signature verification
Be comfortable reading code snippets that create Model Serving endpoints via the REST API or MLflow Deployments client, including traffic config for A/B testing

Exam Day Checklist

Ensure you have a stable internet connection and a clean desktop for online proctoring
Have a government-issued photo ID ready for identity verification
You have 120 minutes for 60 questions, giving you exactly 2 minutes per question
You can flag questions and return to them before submitting the exam
Results are provided immediately upon completion with a pass/fail determination
If you do not pass, there is a 14-day waiting period before you can retake the exam
No reference materials, notes, or external resources are allowed during the exam

Advanced MLflow Tracking

The Professional exam goes far beyond basic log_param/log_metric. You must know how runs are organized hierarchically, how experiments are scoped (workspace vs notebook experiments), how to programmatically search runs, and how to use the MlflowClient API for automation. Advanced tracking is the foundation for every MLOps workflow tested on the exam.

Concept	API / Pattern	Purpose
Nested Runs	`with mlflow.start_run(nested=True):`	Parent run holds summary metrics; child runs hold individual trial results (e.g., per-fold CV or per-Hyperopt trial); enables grouped comparison in UI
Autologging	`mlflow.autolog(log_models=True, log_input_examples=True, log_model_signatures=True)`	Automatic capture of params, metrics, artifacts, model, input example, signature, and tags without manual calls; flavor-specific variants available
Tags vs Params vs Metrics	`set_tag()` / `log_param()` / `log_metric()`	Tags: mutable metadata (git commit, owner); Params: immutable hyperparameters (one value per key); Metrics: numeric values that can be logged multiple times with steps
Artifacts	`mlflow.log_artifact(path, artifact_path=)`	Files associated with a run: plots, confusion matrices, data samples, feature importance CSVs, environment YAML, and the serialized model itself
Run Search	`mlflow.search_runs(experiment_ids=[eid], filter_string="metrics.f1 > 0.9")`	Programmatically query runs by metric, param, tag filters; returns pandas DataFrame; core API for automation jobs that select the best run for registration
MlflowClient	`from mlflow.tracking import MlflowClient; client = MlflowClient()`	Low-level API for experiments, runs, registered models, versions, stages, webhooks; required for lifecycle automation and webhook management

Exam Tip: When Hyperopt runs with SparkTrials inside with mlflow.start_run():, each trial becomes a nested child run automatically. The parent run represents the overall tuning job; child runs capture each hyperparameter configuration and its loss. This is a common multiple-choice pattern.

Hyperparameter Tuning at Scale

Tool	Search Strategy	Distribution Pattern
Hyperopt + SparkTrials	Tree-structured Parzen Estimator (TPE) Bayesian optimization	Each trial ships to a Spark worker; use for single-node models (scikit-learn, XGBoost on pandas); parallelism=N controls concurrent workers; not for Spark MLlib algorithms
Hyperopt + Trials (non-Spark)	TPE, random, atpe, adaptive	Single-node sequential tuning; use when the model itself is distributed (Spark MLlib); parallelism happens inside the trial, not across trials
Optuna	TPE, CmaEs, random, grid	Alternative Bayesian optimizer; supports pruning (early stopping of unpromising trials); integrates with MLflow via callbacks; stores trials in a relational DB for resume
Spark ML CrossValidator	Grid search	Exhaustive over ParamGridBuilder; use `parallelism` param to fit multiple combos simultaneously; best for Spark MLlib models
AutoML (extended)	Mixed: TPE + exhaustive algorithm search	Glass-box AutoML with editable notebooks; professional-level use: baseline generation, feature engineering inspiration, leaderboard-driven experimentation

Exam Tip: Decision rule - if the model fits on one node, use SparkTrials; if the model is itself distributed (SparkML), use regular Trials. Mixing them wastes resources or fails outright.

Data Drift Detection During Experimentation

Test	Use Case	Signal
Kolmogorov-Smirnov (KS)	Continuous numeric features	Compares two empirical CDFs; p-value below threshold (e.g., 0.05) indicates significant distribution shift
Chi-Squared	Categorical features	Tests whether observed category frequencies differ from expected; p-value measures divergence
Population Stability Index (PSI)	Binned numeric or categorical	PSI < 0.1 stable, 0.1-0.25 moderate shift, > 0.25 significant drift; industry standard in finance
Jensen-Shannon Divergence	General distributions	Symmetric information-theoretic distance; bounded [0,1] when using log base 2; used by Lakehouse Monitoring
Wasserstein Distance	Continuous features, ordered categoricals	Also called earth mover's distance; captures shape and location shifts; used in drift monitoring dashboards

Feature Engineering at Scale

Feature Engineering Client: Use FeatureEngineeringClient (UC) or legacy FeatureStoreClient (workspace) to create and query feature tables; both write to Delta + register metadata
Point-in-Time Lookups: For time-series features use timestamp_keys; create_training_set joins features as-of the label event timestamp to prevent target leakage
Feature Functions (UC): On-demand features computed at training and inference (e.g., distance between two input coordinates); registered as SQL functions in Unity Catalog
Online Tables: Sync UC feature tables to a low-latency online store (Databricks Online Tables) for real-time serving; replaces external DynamoDB/CosmosDB pattern
Materialization: Use jobs or DLT pipelines to refresh feature tables on schedule; MERGE INTO for incremental updates; Z-ORDER by primary key for fast lookups

Model Signatures & Input Examples

Infer Signature: signature = infer_signature(X_train, model.predict(X_train)) captures input/output schema (column names, dtypes)
Log With Signature: mlflow.sklearn.log_model(model, "model", signature=signature, input_example=X_train.head(3))
Why It Matters: Model Serving validates incoming requests against the signature; mismatches return 400 errors; signature is also required for UC registration
Tensor Signatures: For deep learning, signatures capture tensor shapes and dtypes; required for Keras/PyTorch models served via Model Serving

MLflow Model Registry Overview

The Model Registry is the control plane for model lifecycle management. It provides centralized versioning, stage transitions, annotations, lineage, and governance over trained models. The Professional exam tests both the legacy workspace registry (stages: None, Staging, Production, Archived) and the Unity Catalog registry (aliases + environment-based catalogs). You must be fluent in both because real organizations migrate between them.

Concept	Workspace Registry	Unity Catalog Registry
Model Name	Flat: `my_model`	Three-level: `catalog.schema.model`
Lifecycle Handle	Stages: None, Staging, Production, Archived	Aliases (mutable labels): Champion, Challenger, or any string
Access Control	ACLs per registered model (workspace-scoped)	UC privileges: USE CATALOG, USE SCHEMA, EXECUTE, MANAGE, OWNERSHIP
Cross-Workspace Sharing	Requires model copy or custom sync	Native across workspaces bound to the same metastore; delta sharing for external orgs
Load Pattern	`models:/my_model/Production`	`models:/catalog.schema.my_model@Champion` or `/version`
Recommended By Databricks	Legacy; being deprecated	Current standard for new deployments

Stage Transitions (Workspace Registry)

Stage	Purpose	Typical Gate
None	Default stage assigned when a new version is registered; unreviewed	No review required
Staging	Pre-production validation; integration tests, shadow traffic, smoke tests	Transition request + reviewer approval (optional)
Production	Serving live traffic; Model Serving loads the @Production version	Usually requires approval; commonly automated by CI/CD on passing tests
Archived	Retired but preserved for lineage and rollback	Moved here when superseded; not deleted

Exam Tip: client.transition_model_version_stage(name, version, stage, archive_existing_versions=True) atomically promotes a new version to Production and archives any previously-Production version. This is the safe default for production promotions.

Transition Requests & Approvals

Create Request: client.create_transition_request(name, version, stage) - users without direct transition rights submit a request for review
Approve/Reject: client.approve_transition_request() or client.reject_transition_request() by reviewers with MANAGE permission
Comments: client.create_registered_model_comment() and client.create_model_version_comment() record reviewer feedback for audit
Webhooks on Request: TRANSITION_REQUEST_CREATED fires when a request is opened; can trigger automated tests or Slack notifications

MLflow Webhooks (Workspace Registry)

Event	Fires When	Common Use
MODEL_VERSION_CREATED	New version registered	Kick off automated validation job
TRANSITION_REQUEST_CREATED	User requests stage change	Notify approvers via Slack/Teams
MODEL_VERSION_TRANSITIONED_STAGE	Stage changes (e.g., to Production)	Trigger deployment to Model Serving; redeploy downstream batch jobs
MODEL_VERSION_TAG_SET	Tag added or updated on a version	Track custom metadata changes
COMMENT_CREATED	Reviewer posts a comment	Forward to audit log or ticketing system

Exam Tip: Webhooks have two target types: HTTP (http_url_spec) and Databricks Jobs (job_spec). HTTP webhooks support HMAC-SHA256 signature validation via a shared secret. Job webhooks trigger an existing Databricks Job run, passing event metadata as job parameters. Questions often ask which target is best for which use case.

Unity Catalog Model Registry Patterns

Environment Catalogs: Common pattern - dev.mlops.fraud_model, stg.mlops.fraud_model, prd.mlops.fraud_model; promotion copies the model across catalogs using mlflow.register_model with the UC URI
Aliases Replace Stages: client.set_registered_model_alias(name, alias="Champion", version=3); aliases point to exactly one version; any string alias is allowed
Load by Alias: mlflow.pyfunc.load_model("models:/prd.mlops.fraud_model@Champion"); production code references aliases, not version numbers, so rollbacks are a simple alias reassignment
Copy Across Catalogs: client.copy_model_version(src_model_uri, dst_name) creates a new version in another UC model; preserves artifacts but assigns a new version number
Governance: UC privileges (USE CATALOG, USE SCHEMA, EXECUTE, MANAGE) control who can read, load, or modify models; OWNERSHIP can be transferred for lifecycle handoff

Model Versioning Best Practices

Immutable Versions: Never overwrite a version; always register a new one; keeps lineage and audit trail intact
Tag Metadata: Use tags for git_commit, training_job_id, dataset_version, evaluator_run_id; enables full reproducibility
Lineage: Each registered version stores a link to the source MLflow run; click through to see training metrics and parameters
Archive Policy: Use scheduled jobs to archive versions older than N or below a metric threshold; keeps registry navigable

Deployment Pattern Selection

The Professional exam repeatedly asks you to choose the right deployment pattern for a given scenario: latency budget, throughput, cost, and where the consuming application lives. There is no single best pattern; each has trade-offs. Know the decision triggers cold.

Pattern	Latency	Throughput	Best For
Model Serving (Real-Time)	10-100 ms p50	Thousands of RPS per endpoint	User-facing apps, fraud scoring at transaction time, personalization, chatbots
Batch Inference (Spark UDF)	Minutes to hours end-to-end	Billions of rows per job	Nightly scoring, periodic enrichment, feature backfills, historical reprocessing
Streaming Inference	Seconds (micro-batch trigger interval)	Tens of thousands events/sec	IoT, telemetry, near-real-time dashboards, anomaly alerts
Edge / Export	< 10 ms on-device	Device-local, offline capable	Mobile apps, in-browser inference, embedded systems (export to ONNX)

Databricks Model Serving

Feature	Details
Serverless Compute	No cluster to manage; Databricks provisions and scales the underlying compute; you pay for DBUs consumed during requests plus a small baseline for always-on provisioned concurrency
Scale-to-Zero	Endpoints can scale to zero when idle; first request after scale-down suffers a cold start (typically 30-60 seconds); enable provisioned concurrency for latency-sensitive workloads
Concurrency Size	Small / Medium / Large specify max concurrent requests per replica; autoscaling adds replicas as load grows; max_provisioned_concurrency caps total cost
Inference Tables	Optional auto-logging of every request and response to a Delta table for monitoring, drift analysis, and offline evaluation; configurable sampling rate
Feature Store Lookup	Models trained with FeatureEngineeringClient auto-join features at inference time; only primary keys need to be in the request; uses Online Tables for low latency
GPU Serving	GPU-backed endpoints for deep learning models (LLMs, CV); select GPU_SMALL, GPU_MEDIUM, GPU_LARGE workload_type
Authentication	Personal access tokens, service principal OAuth, or Databricks-managed tokens; UC privileges control which models can be served

Exam Tip: A Model Serving endpoint is created via the MLflow Deployments client or the Serving REST API. The key config keys are name, config.served_entities (list of model refs with workload size and scale-to-zero flag), and config.traffic_config.routes (traffic percentages for A/B).

A/B Testing & Canary Deployments

Strategy	Mechanic	When to Use
A/B Test	Two served_entities (Champion + Challenger) with traffic split (e.g., 90/10); compare business metrics on inference log table	Evaluating a new model against the current production model on live traffic
Canary	Small percentage (e.g., 5%) sent to a new version; gradually ramp up if metrics stay healthy; automated rollback on error spike	Safe rollout of a new version when risk of regression is high
Shadow	Challenger receives a copy of live requests but responses are discarded; compare predictions offline without user impact	Performance testing a new model without affecting users
Blue-Green	Deploy Challenger to a separate endpoint; swap client traffic via DNS/config once validated	Zero-downtime cutover with instant rollback

Batch Inference with Spark UDFs

pyfunc spark_udf: predict_udf = mlflow.pyfunc.spark_udf(spark, model_uri="models:/catalog.schema.model@Champion"); wraps any MLflow model as a Spark UDF
Apply to DataFrame: df.withColumn("prediction", predict_udf(struct(*feature_cols))); distributes inference across all workers; writes results to a Delta table
Pandas UDF (manual): Use @pandas_udf for custom pre/post-processing; broadcast the model once and apply to Arrow pandas batches for vectorized execution
mapInPandas: For per-partition processing with per-partition model loading when models are huge; load the model once per partition, iterate over batches
Spark ML Models: Call pipeline_model.transform(df) directly; no UDF needed; Spark ML models are distributed natively
Optimized Writes: Output to Delta with write.format("delta").mode("overwrite").save(path); use Z-ORDER on prediction score for downstream filtering

Streaming Inference with Structured Streaming

Streaming Source: spark.readStream.format("delta").table("events") or Kafka source for incoming events
Apply Model: Use mlflow.pyfunc.spark_udf() the same way as batch; works identically in Structured Streaming
Streaming Sink: .writeStream.format("delta").option("checkpointLocation", ck).trigger(availableNow=True).start(path)
Trigger Modes: processingTime="30 seconds" for continuous, availableNow=True for batch-style incremental, once=True for single-run
Exactly-Once: Checkpoint + Delta output provide exactly-once guarantees; duplicates avoided on retries

Custom Serving & Containerization

Custom PyFunc: Subclass mlflow.pyfunc.PythonModel and override predict(self, context, model_input); bundle custom preprocessing, post-processing, or multi-model ensembles
Artifacts & Code: Include supporting files via artifacts={"lookup": path} and code_paths=["helpers.py"] when logging the custom model
Dependencies: Specify conda_env or pip_requirements to lock Python package versions; Model Serving reproduces the environment in the container
Docker Export: mlflow models build-docker produces an image that can run anywhere (ECS, GKE, AKS); useful for hybrid deployments outside Databricks
External Models: Model Serving supports external LLMs (OpenAI, Anthropic, Cohere) via the same endpoint interface, with credentials stored as Databricks secrets

Lakehouse Monitoring Profiles

Lakehouse Monitoring automatically creates profile and drift metrics tables for any Delta table. It is the Databricks-native way to operationalize data quality and drift detection without stitching together external tools. Profile type determines which metrics are computed and how baselines are compared.

Profile Type	Target Table	What It Measures
Snapshot	Any Delta table; no timestamp	Summary stats (count, null%, mean, stddev, quantiles) per column over the full table; drift compared to an optional baseline table
TimeSeries	Time-stamped Delta table	Per-window metrics (daily, hourly); drift compares consecutive windows or vs. baseline; ideal for feature tables
InferenceLog	Model Serving inference table or batch scoring output	Request/response metrics including prediction distribution, model quality when labels are joined in, per-feature drift, and model performance over time

Exam Tip: The InferenceLog profile is the correct choice for monitoring a deployed model. It requires timestamp_col, prediction_col, model_id_col, optional label_col for quality metrics, and problem_type (classification or regression). Choose it over TimeSeries when you need model-specific metrics like accuracy, precision, or RMSE alongside feature drift.

Drift Detection Types

Drift Type	Definition	Detection Approach
Data Drift (Covariate Shift)	Input feature distribution P(X) changes; P(Y\|X) unchanged	Compare feature distributions between production and training (KS, PSI, JS divergence); Lakehouse Monitoring drift metrics table
Concept Drift	Relationship between features and target P(Y\|X) changes; input distribution may be unchanged	Requires labeled data; monitor model quality metrics (accuracy, F1, RMSE) over time on ground-truth labels
Label Drift (Prior Shift)	Marginal label distribution P(Y) changes; class balance shifts	Monitor target class proportions; sudden shifts may indicate seasonal effects or pipeline bugs
Prediction Drift	Model output distribution changes	Monitor prediction score histogram; useful proxy when labels arrive with delay; available in InferenceLog profile

Data Quality with DLT Expectations

expect: @dlt.expect("valid_amount", "amount > 0") - records violation count in event log but keeps bad rows
expect_or_drop: @dlt.expect_or_drop("valid_user", "user_id IS NOT NULL") - drops violating records and records the drop count
expect_or_fail: @dlt.expect_or_fail("not_empty", "count > 0") - fails the pipeline run immediately on violation; use for hard invariants
expect_all: Pass a dict of {"rule_name": "condition"} to apply multiple expectations efficiently; variants: expect_all_or_drop, expect_all_or_fail
Quarantine Pattern: Combine expect with CASE WHEN to route violations to a quarantine table while passing good rows downstream

Alerting & Thresholds

Channel	Mechanism
Databricks SQL Alerts	Schedule a SQL query against the monitor drift metrics table; trigger when a column (e.g., js_distance) exceeds threshold; send to email, Slack, webhook, PagerDuty
Lakehouse Monitor Dashboard	Auto-generated dashboard with drift and quality panels; shared via Databricks SQL; can be embedded in external tools
Job Notifications	Retraining jobs send email/webhook on success, failure, or duration exceeded; useful for long-running pipelines
Model Serving Alerts	Monitor endpoint HTTP error rate, p99 latency, and request volume; integrates with cloud monitoring stacks

Retraining Trigger Strategies

Strategy	Trigger	Pros / Cons
Scheduled	Weekly / monthly cron job	Simple and predictable; may retrain unnecessarily or miss fast drift
Performance-Based	Model quality metric drops below threshold	Efficient - retrains only when needed; requires timely labels
Drift-Based	Feature or prediction drift metric crosses threshold	Works without labels; may retrain on benign shifts that do not hurt performance
Volume-Based	N new labeled examples collected	Good for active learning setups; combines with other triggers
Hybrid	OR combination: schedule + drift + performance	Most robust in practice; guards against all failure modes

Exam Tip: A retraining workflow typically looks like: Lakehouse Monitor writes drift metrics table, a SQL alert fires when drift exceeds a threshold, the alert triggers a Databricks Job, the job retrains the model, registers a new version, runs validation, and either auto-promotes or creates a transition request. Memorize this end-to-end chain.

Model Quality Monitoring

Join Labels: Production predictions live in the InferenceLog table; true labels arrive later via user feedback, downstream events, or human annotation; join on request_id or key + timestamp
Compute Quality: Lakehouse Monitor automatically computes classification metrics (accuracy, precision, recall, F1, AUC) and regression metrics (RMSE, MAE, R2) when a label column is configured
Sliced Metrics: Configure slicing columns (geography, user_segment) to surface fairness or performance issues in specific subgroups
Delayed Labels: For long-horizon labels (e.g., 30-day conversion), use proxy metrics (prediction drift, calibration) until true labels arrive

CI/CD for ML

Stage	Artifacts	Databricks Tool
Source Control	Notebooks, Python modules, job configs, monitor specs	Databricks Repos (Git integration), Databricks Asset Bundles (DABs)
Unit / Integration Tests	Pytest for feature logic, smoke tests for pipelines	GitHub Actions / Azure DevOps runs tests against a dev workspace
Deployment	Jobs, DLT pipelines, monitors, model endpoints	Databricks Asset Bundles (bundle validate / deploy), Terraform provider
Environment Promotion	dev -> stg -> prd; model copies across catalogs	`client.copy_model_version`, DAB target switching, UC catalog bindings

Production Reference Architecture

Bronze -> Silver -> Gold: Raw events in bronze Delta tables; cleaned and conformed data in silver; aggregated features in gold; DLT or Jobs orchestrate the flow
Feature Tables: Materialized from gold via UC Feature Engineering client; online tables sync to low-latency store for serving
Training Job: Scheduled notebook or Python wheel job; logs to MLflow; registers to UC on success; runs offline evaluation
Registry & Promotion: UC catalogs segregate dev/stg/prd; aliases (Champion/Challenger) replace stages; webhooks or CI jobs drive promotion
Serving: Model Serving endpoint loads models:/prd.mlops.model@Champion; inference tables capture requests; feature lookups from online tables
Monitoring: Lakehouse Monitor on inference table; SQL alerts on drift; scheduled retraining job when thresholds breached

Batch vs Real-Time vs Streaming Quick Comparison

Dimension	Batch	Streaming	Real-Time
Latency	Hours	Seconds	Milliseconds
Throughput	Very high (TB)	High (GB/sec)	Moderate (RPS)
Compute	Spark cluster (job)	Spark Structured Streaming / DLT	Model Serving (serverless)
Cost Model	Pay per job run	Always-on cluster	Per request + baseline
Failure Semantics	Retry whole job	Exactly-once via checkpoint	Client retries with idempotency

Workspace vs Unity Catalog Registry Cheat Sheet

Task	Workspace	Unity Catalog
Register	`mlflow.register_model(run_uri, "model_name")`	`mlflow.register_model(run_uri, "catalog.schema.model")` after `mlflow.set_registry_uri("databricks-uc")`
Promote	`transition_model_version_stage(..., "Production", archive_existing_versions=True)`	`set_registered_model_alias(..., "Champion", version=N)`
Load	`models:/name/Production`	`models:/catalog.schema.name@Champion`
Governance	Per-model ACLs	UC privileges on catalog / schema / model
Webhooks	Supported (HTTP + Job)	Not supported; use Jobs + event-driven patterns

Exam Tip: A common question asks what replaces stages in Unity Catalog. The answer is aliases. Another common question asks how webhooks work in UC. The answer is that webhooks are a workspace-registry feature; in UC you replicate event-driven behavior via Databricks Jobs triggered by file arrival, DLT events, or scheduled monitors.

Common Pitfalls for the Professional Exam

SparkTrials with Spark MLlib: Do not use SparkTrials with a Spark MLlib algorithm; the trial would itself try to start Spark jobs on a worker, leading to deadlock. Use regular Trials instead
Training-Serving Skew: Preprocessing done in ad-hoc notebooks at training time must match serving; solve by logging a pipeline (scikit-learn Pipeline or Spark PipelineModel) or custom pyfunc, not just the final estimator
Missing Signature: Logging a model without a signature breaks Model Serving input validation and makes UC registration warn; always call infer_signature
Leaking Future Data: Joining feature tables without point-in-time semantics leaks future values into training; always use timestamp_keys for time-series features
Overwriting Versions: Never delete or overwrite a deployed version - loses lineage; archive instead
Latency Blind Spots: Scale-to-zero endpoints cold-start in 30-60 seconds; for latency-sensitive apps configure provisioned concurrency or keep traffic warm
Choosing Accuracy on Imbalanced Problems: Use F1 or PR-AUC for classification when classes are imbalanced; Lakehouse Monitor supports multiple metrics - configure the right one
Forgetting Inference Tables: Without enabling inference logging on a Serving endpoint you cannot monitor drift; turn it on at endpoint creation

Key API Commands Quick Reference

Task	Code
Set UC as registry	`mlflow.set_registry_uri("databricks-uc")`
Start nested run	`with mlflow.start_run(nested=True) as child:`
Log model with signature	`mlflow.sklearn.log_model(m, "model", signature=sig, input_example=X.head(3))`
Register model (UC)	`mlflow.register_model("runs:/<rid>/model", "cat.sch.name")`
Set alias	`MlflowClient().set_registered_model_alias("cat.sch.name", "Champion", 7)`
Transition stage	`client.transition_model_version_stage("n", v, "Production", archive_existing_versions=True)`
Load by alias	`mlflow.pyfunc.load_model("models:/cat.sch.name@Champion")`
Spark UDF inference	`udf = mlflow.pyfunc.spark_udf(spark, "models:/cat.sch.name@Champion"); df.withColumn("p", udf(struct(*cols)))`
Search runs	`mlflow.search_runs(experiment_ids=[eid], filter_string="metrics.f1 > 0.9", order_by=["metrics.f1 DESC"])`
Create webhook	`client.create_registry_webhook(model_name="m", events=["MODEL_VERSION_CREATED"], http_url_spec=HttpUrlSpec(url=u, secret=s))`

Final Exam Readiness Checklist

Can draw the full train -> register -> validate -> promote -> deploy -> monitor -> retrain loop from memory
Can choose between real-time, batch, and streaming given latency and throughput requirements
Can explain when to use SparkTrials vs Trials, and when each causes issues
Know the differences between workspace-registry stages and UC aliases, and how to migrate
Understand which Lakehouse Monitoring profile (Snapshot, TimeSeries, InferenceLog) fits each scenario
Can distinguish data drift, concept drift, label drift, and prediction drift and propose the right detection method
Know the five MLflow webhook event types and the difference between HTTP and Job targets
Can write or read a Model Serving endpoint config (served_entities, traffic_config, workload_size, scale_to_zero)
Comfortable with DLT expectations (expect, expect_or_drop, expect_or_fail) and the quarantine pattern
Know how to enable and query inference tables, and how to join them with labels for model-quality monitoring

Databricks-ML-Professional

Databricks Certified Machine Learning Professional

Databricks ML Professional Practice Exam 1

Databricks ML Professional Practice Exam 2

Databricks ML Professional Practice Exam 3

Databricks ML Professional Practice Exam 4

Databricks ML Professional Practice Exam 5

Databricks ML Professional Practice Exam 6

Unlock All Content for Databricks-ML-Professional

Preview (10 / 120)

Flash Cards

Available Languages

Exam Topics

Databricks-ML-Professional Cheat Sheet

Databricks Certified Machine Learning Professional

Exam Details

Domain Weights

Study Tips

Exam Day Checklist

Advanced MLflow Tracking

Hyperparameter Tuning at Scale

Data Drift Detection During Experimentation

Feature Engineering at Scale

Model Signatures & Input Examples

MLflow Model Registry Overview

Stage Transitions (Workspace Registry)

Transition Requests & Approvals

MLflow Webhooks (Workspace Registry)

Unity Catalog Model Registry Patterns

Model Versioning Best Practices

Deployment Pattern Selection

Databricks Model Serving

A/B Testing & Canary Deployments

Batch Inference with Spark UDFs

Streaming Inference with Structured Streaming

Custom Serving & Containerization

Lakehouse Monitoring Profiles

Drift Detection Types

Data Quality with DLT Expectations

Alerting & Thresholds

Retraining Trigger Strategies

Model Quality Monitoring

CI/CD for ML

Production Reference Architecture

Batch vs Real-Time vs Streaming Quick Comparison

Workspace vs Unity Catalog Registry Cheat Sheet

Common Pitfalls for the Professional Exam

Key API Commands Quick Reference

Final Exam Readiness Checklist