Databricks-ML-Pro Model Development Practice Question
A machine learning team is using Databricks to develop a model and wants to ensure that the model's input schema is validated at inference time to prevent errors from malformed data. Which TWO approaches allow them to enforce schema validation when serving the model with MLflow Model Serving? (Choose two.)
⚠ Common exam trap
The trap here is assuming that tools like Feature Store or Model Registry webhooks can validate inference requests, when they actually operate at training or registry-event time, not at serving time.
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
✓
Log the model with an MLflow signature that specifies the expected input schema, and rely on MLflow Model Serving to reject requests that do not conform to the signature.
Logging a model with an MLflow signature enables Model Serving to automatically validate incoming requests against the expected schema, rejecting mismatches. Alternatively, a custom `pyfunc` model can implement explicit validation logic in its `predict` method. Both approaches enforce schema validation at inference time. The other options do not provide runtime validation for served models.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Enable MLflow Model Registry webhooks to validate the model signature before each inference request.
Why it's wrong here
Model Registry webhooks are triggered by registry events such as model version creation or stage transitions. They are not invoked during inference requests. They cannot validate input data at serving time. This approach is unrelated to runtime schema validation and would not prevent malformed data from reaching the model.
- ✓
Log the model with an MLflow signature that specifies the expected input schema, and rely on MLflow Model Serving to reject requests that do not conform to the signature.
Why this is correct
When an MLflow model is logged with a signature, Model Serving uses it to validate incoming requests. If the payload does not match the schema (e.g., missing columns, wrong data types), the request is rejected with an error. This provides automatic schema enforcement without additional code. It is the recommended way to ensure input validation for served models.
- ✗
Use Databricks Feature Store to define the feature schema and rely on it to validate incoming requests at serving time.
Why it's wrong here
Feature Store ensures consistency between training and serving features, but it does not automatically validate incoming request payloads for Model Serving. When using Feature Store with Model Serving, the model looks up features from the online store, but the request may still contain other features that are not validated. It does not provide a general schema validation mechanism for all inputs.
- ✗
Configure Model Serving to use a Delta table as the input source and enable schema evolution, so that any schema changes are automatically handled.
Why it's wrong here
Model Serving does not directly consume Delta tables as input; it serves REST API requests. Schema evolution on a Delta table is unrelated to request validation. This approach does not enforce schema validation at inference time. It is not a valid method for preventing malformed data from reaching the model.
- ✓
Implement a custom Python function that checks the input schema and raises an exception if it is invalid, then log the model using `mlflow.pyfunc.log_model` with that function as the model's `predict` method.
Why this is correct
A custom `pyfunc` model can include arbitrary validation logic in its `predict` method. If the input schema is incorrect, the function can raise an exception, which Model Serving will return as an error. This approach allows for complex validation beyond the standard signature. It is a valid way to enforce schema validation, though it requires additional coding.
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.