I85PREP
⌘ K
DE MLO study materials
DE MLO study resources

DE MLO: Model Deployment and Serving

DE MLO · Work through your exam, one topic at a time.

All guide sections

Model Deployment and Serving

What the exam tests

This domain covers moving a model from the registry into batch, streaming, or real-time serving. It tests endpoint configuration, traffic management, inference logging, permissions, and the failure modes that appear when a model is served without a complete schema or stable version pointer.

Core rules

  • Batch inference typically uses a Spark UDF loaded from an MLflow model, such as mlflow.pyfunc.spark_udf, and writes predictions to Delta. Streaming inference applies the same pattern in foreachBatch or a structured streaming query.
  • Databricks Model Serving exposes an endpoint with one or more served entities. Each entity references a model version or alias and receives a traffic percentage. This supports canary and A/B splits.
  • Endpoint configuration can enable scale-to-zero for cost control or provisioned concurrency for latency-sensitive workloads. Cold starts matter when scale-to-zero is enabled.
  • Enable inference tables to capture request and response payloads in Delta for debugging and monitoring. Without them, production monitoring lacks raw serving data.
  • Permissions are explicit: CAN_QUERY allows invocation, while CAN_MANAGE allows endpoint administration. Do not give broad manage rights to consumers.

Worked example

A team registers main.default.fraud_model and sets alias champion. They create a serving endpoint with two served entities: 90% traffic to champion and 10% to alias challenger. They enable an inference table, grant analysts CAN_QUERY, and grant the ML platform team CAN_MANAGE. After a week, they compare challenger and champion predictions and latency from the inference table. If challenger wins, they shift traffic gradually and then move the champion alias. Reasoning: aliases decouple deployment from version numbers, traffic splitting enables safe rollout, and inference tables provide evidence for promotion.

Traps that cost marks

  • Pointing an endpoint at a fixed version when the lifecycle expects alias-based promotion.
  • Serving a model without a signature, causing request schema mismatches.
  • Forgetting inference tables and then having no production request data to monitor.
  • Using an all-purpose interactive cluster for production batch jobs instead of a job cluster or scheduled workflow.
  • Ignoring cold-start latency when scale-to-zero is enabled.
  • Granting CAN_MANAGE to users who only need to call the endpoint.

Key points

  • Batch and streaming inference commonly use MLflow pyfunc Spark UDFs writing to Delta.
  • Model Serving endpoints support multiple served entities and traffic splits.
  • Scale-to-zero saves cost but introduces cold-start latency.
  • Inference tables capture serving requests and responses for monitoring.
  • Separate CAN_QUERY from CAN_MANAGE permissions.