Databricks Machine Learning Associate · 12% practice allocation

Databricks Machine Learning Associate: Model Deployment Practice Questions

5 free sample questions from the Model Deployment domain, with answers and explanations. The full Machine Learning Associate bank has 461 questions across 4 domains. Questions are scenario-based and written from the official Databricks exam guide.

1.

A machine learning engineer wants to apply a registered MLflow model to a large Spark DataFrame for batch scoring, distributing the computation across the cluster rather than running inference row-by-row on the driver. Which approach correctly achieves this?

  • A. Register the model as a REST endpoint and issue one HTTP request per row from the driver in a sequential loop
  • B. Load the model as a Spark UDF using mlflow.pyfunc.spark_udf() and apply it to the DataFrame with withColumn(), so predictions run in parallel across executors✓ Correct
  • C. Batch scoring against a Spark DataFrame is not supported by MLflow; the DataFrame must first be exported to CSV and scored by an external service
  • D. Load the model with mlflow.pyfunc.load_model() on the driver, collect the entire Spark DataFrame to a Python list, and loop over rows calling .predict() one at a time
Explanation

mlflow.pyfunc.spark_udf() wraps a registered model as a Spark UDF, which Spark then distributes across executors, letting batch inference run in parallel at scale — the standard pattern for batch-scoring a Spark DataFrame. Option 2 collects everything to the driver and loops sequentially, discarding Spark's parallelism and risking driver memory exhaustion at scale, which is exactly the anti-pattern this question is testing against. Option 3 is false — MLflow explicitly supports Spark DataFrame batch scoring via spark_udf. Option 4 turns a bulk, parallelizable batch job into a slow sequential loop of network calls, which is a poor fit for large-scale batch inference.

2.

A company wants to serve a trained scikit-learn model for low-volume, latency-tolerant predictions that run once per night against a large Delta table. Which inference pattern is MOST appropriate?

  • A. Serve the model using a dedicated GPU cluster with TorchDistributor
  • B. Register the model in Unity Catalog and use it with a streaming job
  • C. Use Spark UDF-based batch inference with mlflow.pyfunc.spark_udf()✓ Correct
  • D. Deploy the model to a Databricks Model Serving endpoint and call it via REST API
Explanation

For low-volume, latency-tolerant nightly predictions over a large Delta table, batch inference using mlflow.pyfunc.spark_udf() is ideal—it leverages Spark parallelism for scalable distributed scoring without the overhead of a persistent endpoint. A Databricks Model Serving REST endpoint is optimized for real-time, low-latency, on-demand inference and is unnecessarily costly for a nightly batch job. A streaming job is suited for continuous, near-real-time pipelines, not once-per-night batch runs. TorchDistributor and GPU clusters are for distributed model training, not batch inference of scikit-learn models.

3.

A data scientist has trained a model that performs well offline but is unsure whether batch or real-time serving is the right deployment choice. Which single question is LEAST useful for making that determination?

  • A. "How many predictions need to be produced, and how are they consumed downstream (e.g. by a scheduled job vs. an interactive application)?"
  • B. "How quickly after a new input arrives does a consumer need the corresponding prediction?"
  • C. "Is the cost of continuously running serving infrastructure justified given the request pattern and volume?"
  • D. "Which programming language was used to write the original training notebook?"✓ Correct
Explanation

The training notebook's programming language has no bearing on the batch-vs-real-time deployment decision, which should be driven by latency requirements, prediction volume/consumption pattern, and cost tradeoffs — exactly the considerations in the other three options. Options 2 through 4 are all genuinely relevant, standard questions used to decide between batch, streaming, and real-time serving, which is why the language question stands out as the irrelevant one being tested here.

4.

A team's real-time Model Serving endpoint needs to handle sudden spikes in traffic (e.g., during a flash sale) without manual intervention, while keeping costs lower during quiet periods. Which capability of managed model serving addresses this?

  • A. The endpoint should be taken offline entirely during a flash sale to avoid overload, then brought back online once the sale ends
  • B. Autoscaling of the serving endpoint's compute based on incoming request load, scaling up during traffic spikes and back down during quiet periods✓ Correct
  • C. Traffic spikes must always be rejected outright with an error response, since serving endpoints cannot scale dynamically under any circumstances
  • D. Manually provisioning a fixed, maximally large cluster permanently sized for peak flash-sale traffic, which is the only way to handle traffic spikes
Explanation

Autoscaling — dynamically adjusting serving compute based on request load — directly addresses the need to absorb sudden spikes while controlling cost during quiet periods, and is a core capability of a managed serving platform. Option 2 describes a valid but far more costly alternative (permanently over-provisioning for peak load) that autoscaling is meant to avoid. Option 3 is false — dynamic scaling is exactly what managed serving is designed to support, not a hard rejection of spikes. Option 4 is a counterproductive choice — taking the endpoint offline during the highest-value traffic period (a flash sale) defeats the purpose of serving predictions at all.

5.

A team building a churn-prediction pipeline needs to decide whether the same registered model should be applied via Structured Streaming or via a nightly batch job, given that the source data arrives as a continuous stream of customer events throughout the day and the business wants churn scores updated within a few minutes of new activity, not once a day. Which choice is appropriate and why?

  • A. A nightly batch job, because Structured Streaming cannot apply a registered MLflow model to incoming data under any circumstances
  • B. Structured Streaming, because it processes the continuously arriving events incrementally and can deliver updated scores within minutes, which a once-daily batch schedule cannot achieve regardless of how the batch job itself is optimized✓ Correct
  • C. A nightly batch job run twice a day fully satisfies a 'within a few minutes' latency requirement
  • D. Either approach delivers identical latency, so the choice should be made solely based on which one is easier to write
Explanation

A 'within minutes of new activity' requirement against continuously arriving events is a direct match for Structured Streaming's incremental micro-batch processing model; a once- or twice-daily batch schedule structurally cannot deliver minutes-level freshness no matter how the batch job itself is tuned, since it only runs at its scheduled cadence. Option 2 is false — Structured Streaming is fully capable of applying a registered MLflow model to streaming data, typically via the same pyfunc/UDF-style loading pattern used in batch. Option 3 ignores the fundamental latency difference between the two architectures. Option 4 is false — twice a day (roughly every 12 hours) falls far short of a 'few minutes' requirement.

Test yourself across every Machine Learning Associate domain

The free Machine Learning Associate practice test mixes about 20 questions weighted like the exam. The full 461-question bank adds instant grading, flashcards and a timed mock exam.

Take the free Machine Learning Associate practice testPractice the full bank

Study this domain

Model Deployment study guide (Machine Learning Associate) →

Other Machine Learning Associate domains

← All Databricks Machine Learning Associate study resources