Databricks-ML-Assoc Model Deployment Practice Question
A machine learning engineer is deploying an MLflow model to a Databricks Model Serving endpoint. The model was trained on a Spark DataFrame and logged with MLflow using the default signature detection. During testing, the endpoint returns predictions, but the engineer notices the input schema shown in the Serving UI does not match the actual DataFrame column types used during training. Which MLflow logging step should the engineer verify first to resolve this schema mismatch?
⚠ Common exam trap
The trap here is assuming that any logged MLflow model automatically carries a complete and correct signature, when in fact inference can be incomplete.
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
✓
The model was logged with `mlflow.pyfunc.log_model` without explicitly passing the `signature` argument, so MLflow inferred it from a sample that may not represent the full schema.
The logged MLflow model signature is the authoritative contract for the Serving endpoint's expected input columns and types. When a signature is missing or inferred from an unrepresentative sample, the endpoint may expose an incorrect schema. Explicitly passing a `ModelSignature` during `log_model` ensures column names and data types align with training data, resolving the mismatch before redeployment.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The model's conda environment file lists incompatible library versions, so the Serving endpoint silently coerces input types to match the environment.
Why it's wrong here
The conda environment affects the runtime dependencies available to the model, not the input schema exposed by the endpoint. A dependency mismatch typically causes load failures or runtime exceptions, not a schema that appears different from training. While the environment file is important for reproducibility, it does not control how MLflow records or enforces the model signature. The symptom points to signature logging, not environment resolution.
- ✓
The model was logged with `mlflow.pyfunc.log_model` without explicitly passing the `signature` argument, so MLflow inferred it from a sample that may not represent the full schema.
Why this is correct
When a model is logged without an explicit signature, MLflow attempts to infer it from the input example or from the model's internal schema, which can be incomplete or incorrect. The Serving endpoint relies on that logged signature to validate and parse incoming requests, so the engineer should check whether the signature was explicitly provided and correct. Supplying a proper `ModelSignature` during logging ensures the endpoint enforces the expected column names and types.
- ✗
The Serving endpoint was configured with `min_instances` greater than zero, which forces the endpoint to rewrite the schema for autoscaling compatibility.
Why it's wrong here
`min_instances` controls how many warm instances are kept available to reduce cold-start latency. It has no effect on the model's input schema or how MLflow records types. Setting it to a positive value simply keeps capacity ready; it does not alter schema metadata. This distractor confuses a scaling configuration with schema enforcement, which are unrelated concerns in Databricks Model Serving.
- ✗
The model was registered in the Model Registry under a different name than the one used in the Serving endpoint configuration, causing the endpoint to load a stale schema.
Why it's wrong here
The model name in the Model Registry does not determine the input schema shown in the Serving UI. The schema comes from the MLflow model artifact's signature, not from the registry name. If the wrong model version were loaded, the engineer would see entirely different predictions or errors, not just a type mismatch. This is a plausible but incorrect root cause for the described symptom.
Visual reference
About these practice questions
Courseiva writes every Databricks-ML-Assoc question from scratch — 319 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-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.