Databricks-ML-Pro Model Deployment Practice Question
An ML engineer is deploying a scikit-learn model to a Databricks Model Serving endpoint. The model's inference function requires access to an external feature store table for real-time feature lookup. Which approach allows the model to retrieve these features during serving while maintaining low latency and avoiding per-request authentication complexity?
⚠ Common exam trap
The trap here is assuming that any external data source can be queried directly from the model without considering the serving environment's limitations and the need for optimized, authenticated access.
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
✓
Use the Databricks Feature Store's online table and call the feature lookup client within the model's predict method.
The Databricks Feature Store online table is purpose-built for low-latency feature serving. By embedding the feature lookup client in the model's predict method, the endpoint can retrieve features in real time without managing authentication. This integration is a core pattern for deploying models that rely on feature store data, ensuring consistency between training and serving.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Package the feature store data as a static file within the model artifact and load it during initialization.
Why it's wrong here
Packaging feature data as a static file would not reflect real-time updates and would quickly become stale. It also increases artifact size and load time. This method is unsuitable for dynamic features that change frequently, and it does not leverage the online table's low-latency serving capabilities.
- ✓
Use the Databricks Feature Store's online table and call the feature lookup client within the model's predict method.
Why this is correct
Databricks Feature Store provides an online table that is optimized for low-latency lookups. The feature lookup client can be embedded in the model's predict method, and the serving endpoint automatically authenticates to the online store. This approach avoids managing credentials per request and ensures the model uses consistent feature values.
- ✗
Enable the model to query the Delta table directly using Spark during each inference request.
Why it's wrong here
Querying a Delta table with Spark during each inference request is not feasible for real-time serving because Spark sessions are not available in the serving environment and would introduce high latency. Model Serving endpoints are designed for lightweight, low-latency inference, not for spinning up Spark jobs per request.
- ✗
Configure the serving endpoint to call an external REST API that returns feature values, using a personal access token stored in the environment.
Why it's wrong here
Using an external REST API introduces additional network latency and requires managing authentication tokens, which adds complexity and security risks. Storing a personal access token in the environment is not a recommended practice because tokens can expire or be exposed, and the endpoint would need to handle token rotation.
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.