Databricks-ML-Assoc Model Deployment Practice Question
A fraud detection team wants their Databricks Model Serving endpoint to log every request and response payload to a Unity Catalog Delta table so analysts can later join predictions with ground-truth labels. Which endpoint capability should they enable?
⚠ Common exam trap
A common mix-up: candidates confuse monitoring tools that summarize metrics with the payload capture mechanism that records raw requests and responses.
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
✓
Inference tables, configured with the endpoint's request and response logging.
Inference tables are the supported way to persist per-request payloads and responses from a Model Serving endpoint into a governed Delta table. Because the table lives in Unity Catalog, downstream jobs can join captured predictions with delayed fraud labels to measure real-world performance. This closes the loop between online scoring and offline evaluation without custom logging code in the model.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Delta Live Tables pipelines attached to the endpoint's event stream.
Why it's wrong here
Delta Live Tables is a declarative pipeline framework for transforming data, not a serving endpoint feature. There is no native attachment of a DLT pipeline to a Model Serving endpoint for payload capture. The team would still lack raw request and response records unless an inference table were enabled first, making this option a misapplication of the wrong product.
- ✗
Model monitoring with a Lakehouse Monitor created on the endpoint's metrics.
Why it's wrong here
Lakehouse Monitors operate on Delta tables to compute data and model quality statistics over time. They do not themselves capture raw per-request payloads from a serving endpoint. Without an inference table feeding them, the monitor has no request-level data to profile, so this choice cannot satisfy the requirement to log every request and response for later label joins.
- ✗
Verbose cluster logs enabled on the underlying serving compute.
Why it's wrong here
Serving compute logs capture infrastructure and application events such as startup errors or scaling actions, not structured request and response bodies. They are transient and not exposed as a queryable Delta table, so analysts could not join them with labels. This option addresses troubleshooting rather than the payload-level audit trail the team needs.
- ✓
Inference tables, configured with the endpoint's request and response logging.
Why this is correct
Inference tables capture the request payload, the response, and associated metadata into a Delta table in Unity Catalog. Enabling this on the endpoint gives the fraud team an auditable record of each scored transaction that can be joined later with confirmed fraud labels. This is the native, governed mechanism for payload-level observability on Model Serving endpoints.
About these practice questions
Courseiva writes every Databricks-ML-Assoc question from scratch — 319 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-Assoc 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-Assoc exam.