Databricks Machine Learning Professional · 12% practice allocation

Databricks Machine Learning Professional: Model Deployment Practice Questions

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

1.

Which statement about serving a model registered in the MLflow Model Registry is TRUE?

  • A. Serving reads the model directly from DBFS and bypasses the registry, so version numbers and aliases have no effect on what the endpoint loads
  • B. The serving endpoint can load a specific registered model version (or alias), so deployments are governed and traceable to a registry entry✓ Correct
  • C. Only models logged to an experiment run but never registered can be served, because registration locks the artifact for governance review
  • D. The model artifact must be manually copied from the run's artifact store into the endpoint container every time a new version is deployed
Explanation

Model Serving deploys a registered model version (or alias), which keeps deployments governed and traceable to the registry. You don't have to copy the artifact into the endpoint container by hand, because the endpoint pulls the model from the registry. The claim that only unregistered models can be served is false: registered models are exactly what you serve. The claim that serving reads from DBFS and ignores version numbers and aliases is also wrong, since governed serving depends on the registry's versioning.

2.

An application needs sub-second predictions per request from a web front end. Which Databricks deployment should be used?

  • A. A notebook run triggered by the web app via the Jobs API per request
  • B. Databricks Model Serving (a real-time serving endpoint)✓ Correct
  • C. A Delta Live Tables pipeline that scores records as they are ingested
  • D. A nightly batch job that writes predictions to a Delta lookup table
Explanation

Databricks Model Serving exposes a registered model as a low-latency REST endpoint for real-time, per-request predictions. A nightly batch job produces stale, precomputed results and can't score new requests on demand. Triggering a notebook run per request has job startup overhead far beyond sub-second latency. A Delta Live Tables pipeline is for ETL/reporting, not per-request serving to a web front end.

3.

A model must score a large batch of records nightly with no latency requirement, writing results to a Delta table. Which deployment paradigm is MOST appropriate?

  • A. An analyst manually running the scoring notebook interactively each night
  • B. Batch scoring (a scheduled job applying the model to the dataset)✓ Correct
  • C. Real-time Model Serving endpoint called once per record from a nightly loop
  • D. Structured Streaming inference reading the source table as a continuous stream
Explanation

Nightly, high-volume, latency-insensitive scoring is classic batch deployment: a scheduled job applies the model and writes to Delta. A real-time serving endpoint is for low-latency per-request scoring, and calling it record by record is wasteful for bulk work. Structured Streaming inference suits continuous event sources, not a nightly batch. Manually running a notebook each night doesn't scale or automate.

4.

A model with custom preprocessing and non-standard dependencies must be served in real time. How is this typically deployed on Databricks Model Serving?

  • A. Run the preprocessing and model in a scheduled batch job and write predictions to a Delta table for the app to look up
  • B. Log only the raw estimator with the built-in flavor and serve it, relying on default dependencies and skipping custom preprocessing
  • C. Keep the preprocessing code in the client application and deploy only the trained estimator to the serving endpoint as-is
  • D. Log it as a custom MLflow pyfunc model with its dependencies, register it, and deploy that model to a serving endpoint✓ Correct
Explanation

Packaging the preprocessing and model as a custom pyfunc MLflow model with its environment lets Model Serving run the full logic behind the endpoint. Keeping preprocessing in the client causes training/serving skew and duplicated logic. Serving the raw estimator with default dependencies drops the preprocessing and the non-standard dependencies. A scheduled batch job fails the real-time requirement.

5.

A real-time serving endpoint should always serve the current production model without redeploying code when a new version is promoted. How is this best achieved?

  • A. Hard-code the specific version number in the endpoint config and update the client code whenever a new version is promoted
  • B. Delete and recreate the serving endpoint from scratch with the new version number each time a model is promoted
  • C. Load the model into a notebook variable and expose it through a driver proxy that the application calls directly
  • D. Serve the model by its registry alias (e.g., @champion) so promoting a new version repoints the endpoint automatically✓ Correct
Explanation

Referencing the model by alias means promoting a new version (repointing the alias) updates what the endpoint serves without code changes. Hard-coding a version number requires manual config and code updates on every promotion. Deleting and recreating the endpoint each time is disruptive and causes downtime. A notebook variable behind a driver proxy isn't a durable, production serving source.

Test yourself across every Machine Learning Professional domain

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

Take the free Machine Learning Professional practice testPractice the full bank

Study this domain

Model Deployment study guide (Machine Learning Professional) →

Other Machine Learning Professional domains

← All Databricks Machine Learning Professional study resources