Databricks ML Associate workflows and deployment

ML Workflows (19%) and Model Deployment (12%) are 31% of the Databricks Machine Learning Associate exam between them — around 15 of the 48 scored questions. Workflows is the larger of the two; deployment is the smallest section on the exam at about six questions.

ML workflows (19%)

Turning ad-hoc experimentation into something repeatable.

Structuring the process. The end-to-end sequence: ingest, explore, prepare, engineer features, train, evaluate, register, deploy, monitor. Know which stage a described activity belongs to — questions often hinge on identifying that a step has been skipped or done out of order.

Automation and scheduling. Running training or scoring as scheduled jobs rather than manually. Handling dependencies between tasks, and what happens when one fails.

Reproducibility. The recurring theme, and the reason MLflow matters so much on this exam. To reproduce a model you need to know:

which data version it used
which code version produced it
which parameters were set
which environment it ran in

A workflow that cannot answer those four questions is not reproducible, and that is a finding the exam expects you to recognise.

Retraining. When and why to retrain: new data, changed conditions, or degraded performance. Scheduled retraining versus retraining triggered by a monitored signal.

Model deployment (12%)

Only about six questions, so cover it and move on — but do cover it.

Batch versus real-time. The most tested decision in the section:

Approach	Use when
Batch inference	Large volumes on a schedule; per-record latency irrelevant
Real-time serving	Interactive requests needing an immediate response
Streaming	Records arrive continuously and must be scored as they arrive

The rule: if latency does not matter, do not pay for a persistent endpoint. A nightly scoring job over millions of records is batch. A customer-facing API is real-time.

Serving a registered model. Deployment starts from the registry, not from a notebook. This is why registration matters: the deployed artefact should be a known, versioned model rather than whatever was in someone’s workspace.

Basic monitoring. After deployment: is it running, is it fast enough, and is prediction quality holding up? Drift — where live data diverges from training data — is the reason quality degrades with nothing having changed.

Streaming inference with Delta Live Tables

One deployment objective asks how streaming inference is performed with Delta Live Tables. The product has since been renamed, first to Lakeflow Declarative Pipelines and now Lakeflow Spark Declarative Pipelines, but the exam guide uses the old name and the idea has not changed.

Streaming inference sits between the other two patterns. Like batch, it scores records with the model loaded inside Spark, not through an endpoint. Like real-time, it keeps up with data as it arrives. The shape is:

Load the registered model as a Spark UDF. mlflow.pyfunc.spark_udf(spark, model_uri) wraps a model from the registry, for example models:/main.ml.churn@champion, so it can be applied as a column expression across the cluster.
Read the input as a stream. The source is an append-only table or files landing in storage, read with spark.readStream or, in a pipeline, as a streaming source.
Define a streaming table that adds the prediction column. In a pipeline you declare the table and its query; the pipeline handles checkpoints, retries and the order of steps, and each new record is scored once.

predict = mlflow.pyfunc.spark_udf(spark, "models:/main.ml.churn@champion")

@dp.table(name="churn_scores")   # older code uses @dlt.table
def churn_scores():
    df = spark.readStream.table("main.ml.customer_features")
    return df.withColumn("churn_prob", predict(*feature_cols))

Here feature_cols is the list of input column names the model was trained on. Because the model is referenced by an alias, promoting a new champion version changes what the next pipeline update loads, without editing the pipeline code.

When to choose it: records arrive continuously, results are needed within minutes rather than milliseconds, and the consumer is another table or dashboard, not an application waiting for a reply. If a user-facing app needs an answer per request, that is real-time serving; if a nightly run is enough, plain batch inference is cheaper.

Pitfall: “scores must be available shortly after new data lands” does not mean a Model Serving endpoint. An endpoint answers individual requests; it does not watch a table. The streaming-table pattern is the one that processes new rows as they appear. The pipeline concepts behind it, such as streaming tables versus materialized views, are in the Lakeflow Declarative Pipelines guide.

Sample questions

Question 1. A scoring job processes 5 million records every night. Per-record latency is irrelevant and the team wants the lowest cost. Which deployment approach fits?

A. A real-time serving endpoint sized for peak load
B. Structured streaming inference
C. Scheduled batch inference
D. Manually running a notebook each night

Show answer

Answer: C

Batch inference on a schedule processes large volumes without holding a persistent endpoint, which is the cheapest option when latency does not matter. A real-time endpoint bills for idle capacity most of the day, streaming suits continuously arriving records, and manual notebook runs are not a production deployment.

Want more questions like this? Full ML Associate practice tests →

Question 2. Six months after deployment, a model's predictions have become steadily less accurate. No code, data pipeline or infrastructure change has occurred. What is the most likely explanation?

A. The serving cluster is misconfigured
B. Data drift; live data has diverged from the training distribution
C. An expired access token on the endpoint
D. Someone edited the training notebook

Show answer

Answer: B

Gradual degradation with nothing changed is drift, where live data diverges from the training distribution over time. A cluster misconfiguration would cause failures rather than gradual decline, an expired token would break access entirely, and notebook changes would be a change.

Want more questions like this? Full ML Associate practice tests →

Question 3. An auditor asks the team to reproduce exactly how the currently deployed model was created. Which combination makes this possible?

A. Endpoint invocation logs for the past year
B. A written description of the approach in the team wiki
C. A copy of the model artefact in cloud storage
D. The registered model version linked to its data version, code version, parameters and environment

Show answer

Answer: D

Reproducibility requires the data version, code version, parameters and environment recorded together and linked to the registered model version. Endpoint logs record inference, a written description is not a record of inputs, and the model artefact alone does not explain how it was produced.

Want more questions like this? Full ML Associate practice tests →

What to practise

Take a model you have trained and deploy it twice: once as a scheduled batch job, once to a serving endpoint. Note what each costs when nothing is happening. Then try to answer the four reproducibility questions for a model you built last month — data, code, parameters, environment.

If you cannot answer all four, you have just experienced the gap this section is testing.