Databricks ML Professional: model deployment
Model Deployment is worth 12% of the Databricks Machine Learning Professional exam — around 7 of the 59 scored questions and by far the smallest section.
This surprises people. “Professional” and “production” suggest serving infrastructure should dominate. It does not: ML Ops at 44% is where production actually lives on this exam, and deployment is the narrower question of how a model is made available.
Cover it properly in a few focused hours. Do not give it a week.
Choosing an inference pattern
The most tested decision, and the same logic as on every platform:
| Pattern | Use when | Cost shape |
|---|---|---|
| Batch | Large volumes on a schedule; per-record latency irrelevant | Cheapest per record |
| Real-time | Interactive requests needing an immediate answer | Pay while capacity is provisioned |
| Streaming | Records arrive continuously and must be scored as they arrive | Continuous processing |
The rule: if latency does not matter, do not pay for persistent serving capacity. A weekly scoring run over 20 million records is batch. A fraud check during checkout is real-time.
Serving a registered model
Deployment begins at the model registry, not in a notebook. The artefact you serve should be a known, versioned, registered model — which is what makes rollback and auditability possible.
- Promoting a registered version to serving.
- Knowing which version is live at any moment.
- Reverting to the previous version quickly.
- Packaging custom logic as a custom PyFunc model with its artifacts, registered in Unity Catalog and queried by REST or the MLflow Deployments SDK; see nested runs and custom PyFunc models.
This is where deployment meets ML Ops, and questions sometimes sit across both.
Scaling, latency and cost
- Right-sizing serving capacity for the actual request pattern.
- Scaling down or to zero when traffic is intermittent.
- Latency budgets: a model call is one component of a larger response time.
- Recognising that a cheaper pattern often beats more capacity.
Deployment patterns that limit risk
Professional-level deployment is about not breaking production:
- Staged rollout or canary — send a small share of traffic to the new version first.
- Shadow traffic — run the new version alongside the old without serving its results, and compare.
- Rollback — the ability to revert quickly, which matters more than deploying quickly.
Shadow deployment is the strongest answer whenever a scenario wants confidence in a new model under real traffic without risking real outcomes.
Training/serving consistency
The failure mode worth knowing: features computed one way in training and another at inference produce training/serving skew, and the model receives inputs unlike anything it learned from. It presents as a model that validated well and performs poorly from the first day — which distinguishes it from drift, which is gradual.
Sample questions
Question 1. A team wants to evaluate a new model version under real production traffic without its predictions affecting any customer outcome. Which approach fits?
- A. A canary release sending 5% of traffic to the new version
- B. Replace the current version and monitor closely
- C. Shadow deployment running both versions, serving only the current one
- D. Offline evaluation against a historical dataset
Show answer
Answer: C
Shadow deployment runs the new version alongside the current one on real traffic while discarding its outputs, allowing comparison with no customer impact. A canary exposes some customers to the new version, replacing it outright exposes all, and offline testing does not use production traffic.
Want more questions like this? Full ML Professional practice tests →
Question 2. A model is called during online checkout and must respond within 200 milliseconds. Which serving approach is appropriate?
- A. A real-time serving endpoint with appropriate provisioned capacity
- B. Nightly batch inference
- C. Streaming inference over a message queue
- D. A scheduled job running every fifteen minutes
Show answer
Answer: A
An interactive request with a strict latency budget requires a real-time serving endpoint with provisioned capacity. Batch and scheduled scoring cannot answer a live request, and streaming processes continuous arrivals rather than responding synchronously to a single call.
Want more questions like this? Full ML Professional practice tests →
Question 3. A newly deployed model performs far worse in production than in validation, from the very first day. Drift is ruled out. What should be investigated first?
- A. Whether the serving endpoint has sufficient capacity
- B. Whether a larger model would perform better
- C. Whether the model should be retrained on more data
- D. Whether features are computed identically in training and at inference
Show answer
Answer: D
Immediate underperformance from day one points to training/serving skew or leakage rather than drift, so the first check is whether features are computed identically in training and serving. Endpoint capacity affects latency not accuracy, a larger model is not indicated, and more retraining repeats the same mismatch.
Want more questions like this? Full ML Professional practice tests →
What to practise
Deploy one registered model two ways — batch and real-time — and compare the cost when idle. Then promote a second version and roll back to the first, timing how long it takes.
That is the section. An afternoon is proportionate for 12%, and the time you save belongs in ML Ops.