Databricks-ML-Pro Model Deployment Practice Question
A data science team is using Databricks Model Serving to deploy a model that must process sensitive data. They need to ensure that all inference requests are logged for auditing purposes, including the input data and predictions. Which approach should they take?
⚠ Common exam trap
The trap here is assuming that any logging mechanism (like MLflow or custom code) can serve the purpose, without recognizing that Model Serving has a dedicated inference logging feature that simplifies compliance.
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 Model Serving endpoint and configure a Delta table to store the logs.
Inference logging in Databricks Model Serving is the built-in feature for capturing request and response data to a Delta table. It is designed for auditing, monitoring, and compliance, providing a scalable and managed solution. Other methods like custom logging or MLflow Tracking are not suited for production-scale inference logging and may introduce reliability or performance issues.
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 MLflow Tracking to log each inference request as a run in an experiment.
Why it's wrong here
MLflow Tracking is designed for logging training runs, parameters, and metrics, not for high-volume inference requests. Using it for each request would create excessive overhead and is not intended for production serving. It would also not capture the input data in a structured, queryable way suitable for auditing.
- ✗
Set up a Databricks Job that periodically queries the endpoint and logs the responses.
Why it's wrong here
This approach would only log synthetic requests generated by the job, not actual inference requests from users. It does not provide a complete audit trail of all incoming data and predictions. A job-based polling mechanism is inefficient and cannot capture real-time traffic.
- ✓
Enable inference logging on the Model Serving endpoint and configure a Delta table to store the logs.
Why this is correct
Databricks Model Serving supports inference logging, which captures request and response payloads to a Delta table. This feature is designed for auditing and monitoring, allowing you to store input data and predictions. By enabling it and specifying a Delta table, the team can meet compliance requirements and analyze model performance over time.
- ✗
Configure the model to write logs to a file in DBFS using a custom Python logger.
Why it's wrong here
While custom logging is possible, writing to DBFS from a serving endpoint may not be reliable or scalable, and it does not integrate with Databricks' built-in auditing features. Model Serving containers are ephemeral, and file writes may not persist. Additionally, this approach lacks centralized management and may not capture all requests if the endpoint scales.
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.