Databricks ML Assoc · Domain 4 of 4

Databricks ML Assoc Domain 4: Model Deployment

The smallest section at 12%. It covers choosing batch, streaming or real-time serving, deploying a custom MLflow model to a serving endpoint, batch inference with pandas, streaming inference in Delta Live Tables pipelines, querying endpoints and splitting traffic.

Exam weight
12%
Official objectives
6
Estimated questions estimate
~6
Suggested study time estimate
5–8 hrs

About 12 min read Reviewed October 2026

Overview

Model Deployment is the shortest section, 12% of the exam with six objectives, and it covers what happens after a model is registered. The first objective compares the three serving patterns. Batch inference scores large tables on a schedule, streaming inference scores records continuously as they arrive, and real-time inference answers individual requests in milliseconds through an endpoint. The remaining objectives are practical.

You deploy a custom model, typically an mlflow.pyfunc.PythonModel with its own preprocessing, to a Mosaic AI Model Serving endpoint. You run batch inference with pandas, either on a driver for small data or distributed through mlflow.pyfunc.spark_udf, which wraps the model as a pandas UDF. Streaming inference applies the same UDF inside a Delta Live Tables pipeline, a product Databricks now calls Lakeflow pipelines. Finally you query an endpoint over REST and split traffic between served models for canary or A/B testing.

How it's tested

Section 4 questions describe a consumer of predictions, with its latency, volume and freshness needs, and ask which serving approach or tool fits. Others show endpoint configuration or a query payload and ask what it does. Note how quickly predictions are needed and where the input data lives before choosing.

  • Choose the serving mode

    Latency and volume needs are described, and you choose batch, streaming or real-time serving.

  • Endpoint mechanics

    You identify how to deploy, query or configure a Model Serving endpoint, including payload format and served models.

  • Scale the scoring

    A large table must be scored, and you pick spark_udf, a pandas UDF or single-node pandas based on data size.

Reasoning it through

A retailer recomputes product demand forecasts once a night for 40 million rows, and analysts read them the next morning. No caller needs an answer in milliseconds, so a real-time endpoint would add cost with no benefit. Wrapping the registered model with mlflow.pyfunc.spark_udf and scoring the Delta table in a scheduled job distributes the work and writes results back for analysts, which is batch inference.

Objectives 6

Official objectives from the Databricks outline, in outline order.

4.1 Identify the differences and advantages of model serving approaches: batch, realtime, and streamingMatching serving mode to latency and volume.
What it means
This objective compares the three ways to deliver predictions: scheduled batch scoring, continuous streaming scoring and on-demand real-time serving.
What to understand
Batch is cheapest and simplest, scores large volumes on a schedule, and suits cases where results are read later; most use cases fall here. Streaming scores records continuously with Structured Streaming, giving fresher results within seconds to minutes. Real-time serves individual requests in milliseconds through an endpoint, suiting interactive applications, at higher cost and with tighter latency constraints.
How it shows up
The required freshness or response time in the scenario decides which serving mode is expected.
Common confusion
Choosing a real-time endpoint for work that only needs nightly results.
4.2 Deploy a custom model to a model endpointServing a pyfunc model with custom logic.
What it means
A custom model wraps logic that a standard flavor cannot express, such as preprocessing or postprocessing, in an mlflow.pyfunc.PythonModel so it can be served like any other model.
What to understand
Subclass PythonModel, load artifacts in load_context, and implement predict(context, model_input). Log with mlflow.pyfunc.log_model including artifacts, pip requirements and a signature, register it in Unity Catalog, then create a serving endpoint through the Serving UI, the REST API or the MLflow Deployments SDK. Model Serving runs serverless, autoscales, and can scale to zero.
How it shows up
A preprocessing step must run on each request; the answer is a custom pyfunc model with that logic in predict.
Common confusion
Deploying only the underlying estimator and expecting callers to preprocess inputs consistently.
4.3 Use pandas to perform batch inferenceBatch scoring with pandas and pandas UDFs.
What it means
Batch inference with pandas means running a model's predict on pandas DataFrames, either directly on the driver for small data or distributed across Spark executors.
What to understand
For small data, load with mlflow.pyfunc.load_model and call predict on a pandas DataFrame. For large data, mlflow.pyfunc.spark_udf(spark, model_uri) wraps the model as a pandas UDF so each executor scores batches of rows in parallel; apply it with withColumn over the feature columns. mapInPandas and applyInPandas give more control, for example scoring per group.
How it shows up
A table too large for one machine indicates spark_udf rather than collecting data into pandas.
Common confusion
Calling toPandas on a huge table to score it on the driver.
4.4 Identify how streaming inference is performed with Delta Live TablesScoring streams inside a declarative pipeline.
What it means
Streaming inference applies a model to records continuously as they arrive. On Databricks this is often done inside a Delta Live Tables pipeline, now named Lakeflow pipelines.
What to understand
Create the scoring function with mlflow.pyfunc.spark_udf, then define a pipeline table that reads the source as a stream, for example with spark.readStream or dlt.read_stream, and adds a prediction column using the UDF. The pipeline manages checkpoints, retries and incremental processing. Batch scoring code converts to streaming largely by changing the read, because the same UDF works on both.
How it shows up
A scenario needs continuous scoring of arriving records with managed pipelines; the answer applies spark_udf in a streaming table.
Common confusion
Assuming streaming needs a real-time endpoint called once per record.
4.5 Deploy and query a model for realtime inferenceCreating and calling a serving endpoint.
What it means
Real-time inference deploys a registered model to a Mosaic AI Model Serving endpoint that exposes a REST API returning predictions in milliseconds.
What to understand
Create the endpoint with a served entity naming the Unity Catalog model and version, workload size and scale-to-zero setting. Query by POSTing JSON to /serving-endpoints/<name>/invocations with a token, using dataframe_split, dataframe_records, instances or inputs. The MLflow Deployments client and the ai_query SQL function also query endpoints. Models logged with feature metadata look up online features automatically.
How it shows up
Expect a question on the endpoint URL path or a valid JSON payload shape.
Common confusion
Sending raw CSV text, or a payload without a recognized top-level key such as dataframe_records.
4.6 Split data between endpoints for realtime inferenceRouting traffic among served models.
What it means
This objective covers dividing incoming requests among models, mainly by serving several models behind one endpoint with traffic percentages. Databricks' guide words it as interference, an evident typo for inference.
What to understand
An endpoint's config lists served entities and a traffic_config with routes whose traffic_percentage values must sum to 100, such as 90 for the champion and 10 for a challenger. This supports canary releases and A/B tests without changing client code. Inference tables can log requests and responses per served model for comparison. Shifting percentages gradually promotes the new model.
How it shows up
A canary or A/B requirement points to traffic percentages across served models.
Common confusion
Creating separate endpoints and expecting clients to split requests themselves.

High-yield concepts

The terms, rules and formulas this domain turns into questions most often.

  • Batch inference

    Scheduled scoring of large tables.

    Remember
    Cheapest; results read later.
    Tested as
    Serving mode questions.
    Trap
    Overbuilding with endpoints.

  • Streaming inference

    Continuous scoring of arriving records.

    Remember
    Same UDF, streaming read.
    Tested as
    Serving mode questions.
    Trap
    Calling an endpoint per record.

  • Real-time inference

    Millisecond responses via REST.

    Remember
    Endpoint per model or set of models.
    Tested as
    Serving mode questions.
    Trap
    Using it for nightly jobs.

  • mlflow.pyfunc.PythonModel

    Base class for custom models.

    Remember
    Implement load_context and predict.
    Tested as
    Custom deployment questions.
    Trap
    Putting preprocessing in client code.

  • mlflow.pyfunc.spark_udf

    Wraps a model as a pandas UDF.

    Remember
    Distributes scoring across executors.
    Tested as
    Batch and streaming questions.
    Trap
    Using toPandas on big data.

  • Lakeflow pipelines

    Current name for Delta Live Tables.

    Remember
    Manages streaming tables and checkpoints.
    Tested as
    Streaming inference questions.
    Trap
    Thinking it is a serving endpoint.

  • Mosaic AI Model Serving

    Serverless endpoints for models.

    Remember
    Autoscaling and scale to zero.
    Tested as
    Real-time questions.
    Trap
    Assuming you manage the cluster.

  • invocations path

    /serving-endpoints/<name>/invocations.

    Remember
    POST JSON with a token.
    Tested as
    Query questions.
    Trap
    Using a GET request.

  • dataframe_split / dataframe_records

    Accepted JSON input formats.

    Remember
    Columns and data, or row objects.
    Tested as
    Payload questions.
    Trap
    Sending raw CSV.

  • traffic_config

    Routes percentages to served models.

    Remember
    Percentages sum to 100.
    Tested as
    Traffic split questions.
    Trap
    Splitting in client code.

  • Inference tables

    Log endpoint requests and responses to Delta.

    Remember
    Supports monitoring and comparison.
    Tested as
    Endpoint monitoring questions.
    Trap
    Expecting logging by default without enabling it.

Side by side

Concepts candidates mix up, compared on the point that decides the answer.

Batch vs. streaming vs. real-time serving

ConceptMeaningKey differenceCommon trap
Batch Scheduled scoring of tables Lowest cost, highest latency Using it for interactive apps
Streaming Continuous scoring as data arrives Seconds-to-minutes freshness Confusing it with per-request serving
Real-time REST endpoint per request Millisecond latency, higher cost Using it for bulk nightly scoring

Single-node pandas vs. spark_udf scoring

ConceptMeaningKey differenceCommon trap
pyfunc.load_model + pandas Predict on the driver Fine for small data Collecting huge tables
pyfunc.spark_udf Pandas UDF across executors Scales to large tables and streams Forgetting to pass feature columns

Exam traps

Each trap is an answer that looks right. Learn the clue that should change your mind.

  1. Endpoint for nightly scoring

    What candidates pick
    Deploy a real-time endpoint to score a full table each night.
    Why it looks right
    Endpoints feel like the production option.
    Why it's wrong
    Batch scoring with spark_udf in a scheduled job is cheaper and simpler when nobody needs an immediate answer.

    Clue to watch for Results are consumed later, such as next morning.

  2. toPandas on big data

    What candidates pick
    Convert a 100-million-row DataFrame to pandas and call predict.
    Why it looks right
    pandas code is familiar.
    Why it's wrong
    Collecting to the driver can exhaust memory; spark_udf scores partitions in parallel on executors.

    Clue to watch for A very large table and a Spark cluster.

  3. Per-record endpoint calls in streams

    What candidates pick
    Call a serving endpoint for each streaming record.
    Why it looks right
    It reuses the real-time model.
    Why it's wrong
    Applying spark_udf in a streaming pipeline table scores micro-batches efficiently with managed checkpoints.

    Clue to watch for Continuous data arrival and a declarative pipeline.

  4. Two endpoints for A/B

    What candidates pick
    Create a second endpoint and have the app route 10% of calls to it.
    Why it looks right
    Separate endpoints look cleaner.
    Why it's wrong
    One endpoint can serve both models with traffic percentages, so clients keep a single URL.

    Clue to watch for Canary or A/B testing without client changes.

  5. Preprocess in the client

    What candidates pick
    Serve the raw estimator and document the preprocessing for callers.
    Why it looks right
    It keeps the model small.
    Why it's wrong
    Each caller may implement it differently; a custom pyfunc model runs preprocessing in predict for every request.

    Clue to watch for Inputs need transformation before prediction.

Answer framework

Use these steps to answer Section 4 deployment scenarios.

  1. Read the latency and freshness requirement: later is batch, continuous within minutes is streaming, and an immediate per-request answer is real-time.
  2. For batch, load the registered model with spark_udf for large tables or pyfunc.load_model for small pandas data, and run it in a scheduled job.
  3. For streaming, apply the same spark_udf in a streaming table of a Delta Live Tables pipeline, now Lakeflow pipelines, reading the source as a stream.
  4. For real-time, wrap any custom logic in a pyfunc PythonModel, register it in Unity Catalog, create a Model Serving endpoint, and query the invocations path with JSON.
  5. When comparing models live, serve both behind one endpoint and set traffic percentages that sum to 100, shifting them as the challenger proves itself.

Practice question

A team has a new challenger model and wants 10% of live requests to reach it while 90% still reach the current model. Client applications must keep calling the same URL. What should the team configure on Mosaic AI Model Serving?

Want more like this? The Databricks ML Assoc practice test has questions for every domain.

Checklist

0 of 10

Tick each one you can do without notes. Your ticks stay in this browser.

Study strategy

This section is small, so aim for clear rules and one round of hands-on practice rather than long reading. Start by writing the latency rule down: later means batch, continuous means streaming, and immediate means real-time. Most scenario questions are settled by that rule alone.

Then take a model you registered while studying Section 1 and score a table two ways: with pyfunc.load_model on a small pandas sample, and with spark_udf across the full Spark DataFrame. Change the read to a stream inside a simple pipeline to see that the same UDF performs streaming inference.

Next, write a small custom PythonModel that adds a preprocessing step, log and register it, and create a serving endpoint. Query it with dataframe_records and dataframe_split payloads, then add a second served model and set a 90/10 traffic split. If your workspace cannot create endpoints, study the configuration JSON instead. Finish with a full mock exam to check all four sections together.

FAQ

How much of the Databricks ML Associate exam is Model Deployment?

Model Deployment is 12% of the exam, the smallest section, or about six of the 48 scored questions.

When should I choose batch inference over real-time serving?

Choose batch when predictions are consumed later, such as daily reports or nightly scoring. It is cheaper and simpler; real-time serving is for requests that need an answer in milliseconds.

What does mlflow.pyfunc.spark_udf do?

It wraps a logged MLflow model as a Spark pandas UDF, so each executor scores batches of rows in parallel. It works for both batch and streaming DataFrames.

Is Delta Live Tables still the product name?

Databricks documentation now calls it Lakeflow pipelines. The exam guide still says Delta Live Tables, so expect that name on the exam.

Why would I deploy a custom pyfunc model?

To package preprocessing, postprocessing or several artifacts with the model so every request is handled the same way on the endpoint.

How do I send a request to a serving endpoint?

POST JSON to /serving-endpoints/<name>/invocations with an access token, using a format such as dataframe_records or dataframe_split. The MLflow Deployments client and ai_query also work.

How do I run an A/B test between two models?

Serve both models on one endpoint and set traffic percentages that sum to 100, then compare results, for example using inference tables.

Other Artificial Intelligence & Machine Learning certifications

Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.

Test your Domain 4 knowledge

Practise choosing serving modes, endpoint payloads and traffic splits in short timed question sets, then review any answer you missed.

Take the Databricks ML Assoc practice test Check your Databricks ML Assoc readiness

Keep going