Courseiva
ML Ops →hardMultiple Choice

Databricks-ML-Pro ML Ops Practice Question

A fraud detection model is served on a Databricks Model Serving endpoint. You notice that predictions for the same input vector differ between two consecutive requests within seconds, and there is no feature store or external cache involved. The model was logged with a fixed random seed and deterministic inference code. Which action should you take first to diagnose the inconsistency?

⚠ Common exam trap

The trap here is jumping to model-level explanations like seeds or flavors, when serving-layer causes such as version routing or payload differences are far more likely.

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

✓

Inspect the endpoint's request logs to confirm the payloads are identical and check whether the model version serving traffic changed between requests.

When a deterministic model returns different outputs for the same input, the fastest path to the cause is to verify the two requests were truly identical and to confirm which model version handled each. A version transition during a rollout, or a payload difference such as field ordering or missing values, explains the symptom without any model retraining. Retraining, scaling, or changing flavors are premature and do not produce diagnostic evidence.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

  • ✗

    Convert the model to a different flavor such as ONNX and re-register it, because the original flavor cannot guarantee deterministic inference.

    Why it's wrong here

    Changing the model flavor is a large, speculative change that discards the existing validated artifact. MLflow model flavors for common frameworks do produce deterministic inference given identical inputs and environment, so the premise that the flavor is at fault is unsupported. This action also does not gather any evidence about the actual cause, such as a version swap or differing payloads, and risks introducing new incompatibilities at the endpoint.

  • ✗

    Increase the endpoint's concurrency and enable autoscaling, since differing predictions indicate the replicas are running different code.

    Why it's wrong here

    Autoscaling changes capacity, not correctness. While it is true that replicas could run different code if a deployment is mid-rollout, simply adding concurrency does not diagnose or fix that condition and may even increase the number of replicas serving inconsistent versions. The scenario asks for a diagnostic first step, and scaling does not produce evidence about payload identity or version routing, so it is the wrong action here.

  • ✓

    Inspect the endpoint's request logs to confirm the payloads are identical and check whether the model version serving traffic changed between requests.

    Why this is correct

    Non-determinism in a supposedly deterministic model most often comes from the serving layer, not the model math. Verifying that the request payloads are byte-identical rules out client-side variation, and checking whether the endpoint switched model versions or routed to a different version reveals the most common cause of divergent outputs. This is the cheapest, highest-signal first step before deeper debugging of the model artifact or environment.

  • ✗

    Retrain the model with a different random seed and redeploy, because seed instability is the likely cause of varying predictions.

    Why it's wrong here

    Retraining is expensive and does not address the observed symptom. If the model were truly non-deterministic due to seed handling, the variation would typically appear at training time, not between two rapid inference calls on an already-deployed artifact. Redeploying also introduces a new variable and can mask the real cause, such as version routing or payload differences, making future diagnosis harder rather than easier.

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 →

How Courseiva writes practice questions · Editorial policy

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.