Databricks-ML-Pro Model Deployment Practice Question
A company has deployed a model to a Databricks Model Serving endpoint. The model's predictions must be logged to a Delta table for monitoring and auditing. The ML engineer wants to enable inference logging without modifying the model's code. Which approach achieves this with minimal effort?
⚠ Common exam trap
The trap here is assuming that MLflow tracking can be used for inference logging, or that manual code changes are necessary, when Databricks provides a native inference logging feature.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Enable inference logging on the serving endpoint by specifying a Delta table path in the endpoint configuration.
Inference logging is a built-in feature of Databricks Model Serving that automatically logs request and response data to a Delta table. It can be enabled via the endpoint configuration without altering the model code. Other options require code changes, custom jobs, or misuse of MLflow tracking, and do not provide the same seamless auditing capability.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Use a Databricks job to periodically query the endpoint's logs via the REST API and insert them into a Delta table.
Why it's wrong here
The serving endpoint does not expose request/response logs via a REST API for external polling. While metrics are available, detailed inference payloads are not. This approach would require building and maintaining a custom job, and it would not capture all requests in real time, failing the auditing requirement.
- ✗
Wrap the model's predict method to write inputs and outputs to a Delta table using Spark, then redeploy the model.
Why it's wrong here
Modifying the model's predict method to write to Delta requires code changes and redeployment, which contradicts the requirement of minimal effort and no code modification. Additionally, the serving environment may not have Spark session access, making this approach unreliable and complex.
- ✗
Configure the model to log its predictions to MLflow, then enable MLflow tracking for the serving endpoint.
Why it's wrong here
MLflow tracking is used during model training and experimentation, not for logging live inference requests in a serving endpoint. The serving endpoint does not integrate with MLflow tracking for per-request logging. Enabling MLflow tracking would not capture inference payloads, and would not provide an audit trail.
- ✓
Enable inference logging on the serving endpoint by specifying a Delta table path in the endpoint configuration.
Why this is correct
Databricks Model Serving supports inference logging, which automatically captures request and response payloads and writes them to a specified Delta table. This can be enabled in the endpoint configuration without changing the model code. It is the intended feature for auditing and monitoring, and requires only setting the logging destination.
About these practice questions
Courseiva writes every Databricks-ML-Pro question from scratch — 300 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Databricks exam blueprint
This Databricks-ML-Pro practice question is part of Courseiva's free Databricks certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the Databricks-ML-Pro exam.