Databricks-ML-Assoc Model Deployment Practice Question
A team has just registered a new version of a fraud detection model in the workspace Model Registry. Before routing production traffic to it, they want to send a small percentage of live requests to the new version and compare its predictions against the current production model. Which Databricks Model Serving feature should they use?
⚠ Common exam trap
The trap here is conflating logging with routing: inference tables record what happened, but only traffic splitting actually sends a percentage of requests to the new model version.
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
✓
Traffic splitting between served entities
Traffic splitting on a Databricks Model Serving endpoint allows multiple served entities, each pointing to a different model version, to share incoming requests by percentage. This makes it possible to route a small fraction of live traffic to a new version and compare its behavior against the existing production model before promoting it fully. Other listed features address logging, capacity, or naming, not request routing.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Inference tables
Why it's wrong here
Inference tables capture the request payloads and the model's responses for logging and monitoring, but they do not split traffic between two versions. They are a logging and observability feature, not a routing mechanism. Enabling inference tables on an endpoint would let the team analyze predictions after the fact, yet it would not send any portion of live traffic to the new version, so it cannot satisfy the canary deployment requirement.
- ✗
Provisioned throughput
Why it's wrong here
Provisioned throughput is a performance option that reserves capacity so the endpoint can serve requests with predictable latency, avoiding cold starts. It does not influence which model version receives traffic. Enabling provisioned throughput would not direct any requests to the new fraud model, so it fails to address the canary comparison the team wants to perform. It is purely a capacity and latency control.
- ✓
Traffic splitting between served entities
Why this is correct
Databricks Model Serving supports configuring multiple served entities on one endpoint and assigning each a percentage of traffic. By giving the new model version a small percentage and the current production model the remainder, the team can perform a canary-style rollout and compare live behavior before a full switch. This is exactly the built-in mechanism for gradual, controlled deployment of a new model version.
- ✗
Model aliases
Why it's wrong here
Aliases such as `@champion` and `@challenger` are convenient labels for referring to particular model versions, and they can be used in endpoint configurations. However, an alias itself does not divide traffic between two versions; it simply names one. Without traffic splitting configured on the endpoint, assigning an alias does not send any percentage of requests to the new model, so it does not accomplish the gradual rollout.
About these practice questions
One of 319 original Databricks-ML-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-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.