Databricks-ML-Pro ML Ops Practice Question
A fraud detection model is served via a Databricks Model Serving endpoint. The team wants to capture the incoming request payloads and the model's predictions to a Delta table for monitoring and future retraining. Which approach is most appropriate?
⚠ Common exam trap
The trap here is assuming you must instrument the model code or build a custom pipeline, when Model Serving already offers inference tables for request and response logging.
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 tables on the model serving endpoint to automatically log requests and responses to a Delta table.
Databricks Model Serving provides inference tables as a built-in mechanism to log request and response payloads to a Delta table. This satisfies monitoring and retraining data capture without custom code. The other options either add latency, require unsupported dependencies in the serving environment, or confuse training-time autologging with serving-time logging.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Enable inference tables on the model serving endpoint to automatically log requests and responses to a Delta table.
Why this is correct
Inference tables are a Databricks Model Serving feature that captures request and response payloads to a Delta table automatically. This provides the exact logging needed for monitoring and retraining without modifying the model code or building custom logging infrastructure.
- ✗
Modify the model's predict method to write each request and response to a Delta table using the Spark connector.
Why it's wrong here
Writing to Delta from within the predict method introduces heavy dependencies and latency into the serving path. Model Serving environments may not include a Spark session, and synchronous writes would degrade endpoint performance. This approach is fragile and unnecessary given native inference tables.
- ✗
Configure the endpoint to send logs to a cloud storage bucket and schedule a job to load them into Delta.
Why it's wrong here
Sending logs to cloud storage and later loading them is a batch workaround that adds latency and complexity. It requires custom parsing and scheduling, and does not provide the near-real-time capture that inference tables offer. This is an overengineered solution for a native capability.
- ✗
Use MLflow autologging on the serving endpoint to capture inference requests as MLflow runs.
Why it's wrong here
MLflow autologging applies during training and evaluation, not to deployed serving endpoints. It does not capture production inference traffic. Conflating training-time logging with serving-time monitoring leads to a solution that cannot record request payloads at the endpoint.
About these practice questions
One of 300 original Databricks-ML-Pro practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. 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.