Databricks-ML-Pro Model Deployment Practice Question

Answer analysis

Option-by-option breakdown

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

• ✗

  Use MLflow's pyfunc flavor to log both models and select the active one at request time.

  Why it's wrong here

  Logging both models with pyfunc and selecting at request time would require custom logic in the model's predict method, which is not a built-in shadow deployment mechanism. It would also mean the endpoint serves only one model's predictions, and implementing shadow logging would require additional code that might not be reliable. This approach does not provide the native traffic mirroring and logging that shadow mode offers, and it adds unnecessary complexity.

• ✓

  Enable the endpoint's shadow mode by specifying the new model version as a shadow.

  Why this is correct

  Databricks Model Serving supports shadow mode, where a copy of the request is sent to a shadow model version while the primary version's response is returned to the client. The shadow model's predictions can be logged for analysis. This exactly matches the requirement to test a new version without affecting existing predictions. The shadow model receives the same input but its output is not served, making it ideal for safe validation.

• ✗

  Deploy the new model version to a separate endpoint and use a load balancer to mirror requests.

  Why it's wrong here

  Deploying to a separate endpoint and using an external load balancer to mirror requests is an infrastructure-level workaround that is not native to Databricks Model Serving. It requires additional components and configuration, increasing complexity and potential failure points. More importantly, it does not integrate with the endpoint's built-in logging and metrics. The native shadow mode feature is designed for this purpose and avoids the overhead of managing a separate endpoint and load balancer.

• ✗

  Configure the endpoint with a traffic split of 50/50 between the current and new model versions.

  Why it's wrong here

  A traffic split sends a portion of live requests to the new version and returns its predictions to clients. This changes the responses that some users receive, which is not acceptable when the requirement is to keep the current version serving all responses. The team wants to observe the new model's behavior without impacting users, so splitting traffic would violate that constraint. Traffic splitting is for A/B testing or gradual rollouts, not for shadow deployment.