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.
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.
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.
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.
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.