Databricks-ML-Pro ML Ops Practice Question
You are monitoring a model served on Databricks Model Serving. You need to detect data drift in the incoming requests without delaying predictions. Which approach should you use?
⚠ Common exam trap
The trap here is assuming that drift detection must happen inline with predictions, but it should be decoupled to avoid latency and allow windowed analysis.
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 endpoint and analyze the logged requests asynchronously using a Databricks job that computes drift metrics.
Inference logging on Model Serving captures request and response data to a Delta table without adding latency to the prediction path. An asynchronous job can then analyze this logged data to compute drift metrics, enabling detection without impacting performance. Synchronous or in-model computations are impractical due to latency and single-request limitations.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Add a pre-processing step in the model's predict function that computes drift metrics on each request.
Why it's wrong here
Computing drift metrics within the predict function adds computation to every request, increasing latency and potentially violating service level objectives. Drift detection typically requires comparing distributions over a window of data, which is not feasible on a single request. This approach would degrade performance and is not scalable for real-time serving.
- ✗
Configure the endpoint to call an external monitoring service synchronously before returning predictions.
Why it's wrong here
A synchronous call to an external service introduces network latency and a dependency that can fail, directly impacting prediction latency and availability. Drift detection is usually a background analysis, not a synchronous gate. This approach risks slowing down or breaking the serving path, which is unacceptable for real-time applications.
- ✗
Use Databricks SQL dashboards to query the model's training data and compare it to live predictions in real time.
Why it's wrong here
Databricks SQL dashboards can visualize data, but they query stored data and cannot directly access live predictions without logging. Without inference logging, there is no live prediction data to compare. This approach does not provide a mechanism to capture incoming requests, so it cannot detect drift in real time or near real time.
- ✓
Enable inference logging on the endpoint and analyze the logged requests asynchronously using a Databricks job that computes drift metrics.
Why this is correct
Inference logging captures the request payloads and predictions to a Delta table. You can then run an asynchronous job to compute drift metrics, such as population stability index or KL divergence, comparing recent data to a baseline. This does not add latency to predictions because logging is decoupled from the serving path, making it the recommended approach.
About these practice questions
This Databricks-ML-Pro question is part of Courseiva's 300-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam 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.