Databricks-GenAI-Assoc Assembling and Deploying Apps Practice Question
A team has developed a GenAI chatbot using the Databricks Mosaic AI Agent Framework and logged it with MLflow. They now want to expose it as a REST API that their customer support portal can call, with autoscaling and built-in monitoring. Which Databricks capability should they use to host the agent?
⚠ Common exam trap
The trap here is assuming any Databricks compute can host the agent, when only Model Serving provides the REST endpoint, autoscaling, and serving-grade monitoring required for interactive traffic.
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
✓
Databricks Model Serving, deploying the MLflow-logged agent to a serving endpoint.
Mosaic AI Agent Framework applications logged with MLflow are served on Databricks Model Serving, which provides a REST endpoint, autoscaling, concurrency management, and built-in monitoring. That makes it the correct host for a customer support portal that needs to call the chatbot over HTTP. The other options are batch, development, or analytics compute surfaces that cannot serve interactive inference.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
A Databricks SQL warehouse that exposes the agent through a SQL function the portal calls.
Why it's wrong here
SQL warehouses are optimized for analytical queries, not for low-latency generative inference, and they do not host MLflow models or agents. There is no supported path to invoke a Mosaic AI agent through a SQL warehouse function for interactive chat. This option confuses the analytics compute layer with the model serving layer.
- ✗
An all-purpose interactive cluster that the portal connects to over JDBC to invoke the agent.
Why it's wrong here
Interactive clusters are designed for notebook development, not for hosting production APIs, and they do not autoscale per request or provide serving-grade monitoring. Exposing JDBC to an external portal also creates security and connection-pooling problems. This is not how Databricks GenAI applications are deployed for customer-facing traffic.
- ✓
Databricks Model Serving, deploying the MLflow-logged agent to a serving endpoint.
Why this is correct
Model Serving is the Databricks capability that turns an MLflow-logged model or agent into a REST endpoint with autoscaling, concurrency controls, and integrated monitoring. Deploying the agent there gives the support portal a stable URL and handles capacity automatically. It is the intended path for serving Mosaic AI Agent Framework applications in production.
- ✗
A Databricks job that runs the agent on a schedule and writes responses to a Delta table the portal polls.
Why it's wrong here
A scheduled job is batch-oriented and cannot answer interactive chatbot requests in real time; the portal would have to poll a table, adding latency and complexity. It also lacks the REST interface, autoscaling, and request-level monitoring the team needs. This pattern suits offline scoring or enrichment, not a live conversational endpoint.
About these practice questions
Courseiva writes every Databricks-GenAI-Assoc question from scratch — 330 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-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.