Databricks-GenAI-Assoc Evaluation and Monitoring Practice Question
A retail company runs a customer-facing RAG assistant on a Mosaic AI Model Serving endpoint. The team wants every production request, response, and retrieved context to be captured automatically into a Unity Catalog Delta table so they can monitor quality and latency trends over time. Which action should they take?
⚠ Common exam trap
The trap here is assuming that MLflow autologging or Unity Catalog lineage will capture live endpoint traffic, when only inference tables persist request and response payloads into a Delta table.
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.
Inference tables are the native Databricks mechanism for capturing production traffic from a Model Serving endpoint into a governed Unity Catalog Delta table. They log payloads, responses, and metadata automatically, which is exactly what the team needs to analyze quality and latency over time. Other options either log only development activity or record lineage instead of runtime traffic, so they cannot satisfy the monitoring requirement.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Configure MLflow autologging on the notebook that calls the serving endpoint.
Why it's wrong here
MLflow autologging records training runs and, for some model flavors, evaluation metrics, but it does not capture live inference traffic from a deployed Model Serving endpoint into a Unity Catalog Delta table. It would only log trace data when the calling notebook executes, missing all production requests that originate from the application, so it fails the monitoring requirement here.
- ✗
Register the model in Unity Catalog and enable lineage tracking on the catalog.
Why it's wrong here
Unity Catalog lineage tracks how tables, models, and notebooks are related, not the runtime traffic of an endpoint. Registering the model and turning on lineage would document dependencies but never record individual prompts, responses, or retrieved contexts, so the team would still lack the request-level data needed for quality and latency trend analysis.
- ✓
Enable inference tables on the Model Serving endpoint.
Why this is correct
Inference tables are the Databricks feature that automatically logs the request payload, response, and metadata from a Model Serving endpoint into a Unity Catalog Delta table. Enabling them on the endpoint requires no application code changes and captures retrieved context when the agent passes it through the payload, giving the team the monitoring substrate they want for trend analysis.
- ✗
Enable Model Serving request logging to a cloud storage bucket.
Why it's wrong here
Databricks Model Serving does not expose a feature that streams request payloads directly to a raw cloud object store as the monitoring mechanism. Even if logs were shipped externally, they would not land in a governed Unity Catalog Delta table, so the team could not query them with SQL or attach Lakehouse Monitoring, making this option unsuitable for the stated goal.
About these practice questions
One of 330 original Databricks-GenAI-Assoc 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-GenAI-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-GenAI-Assoc exam.