Deploy a saved model as a REST prediction service

WHAT THIS TESTS This checks whether you grasp the operational steps that turn a static model file into a reliable, network-accessible service. It rewards a clear, ordered pipeline and awareness of production concerns beyond just calling predict.

A GOOD ANSWER COVERS Load the serialized model once at service startup, not per request, so you avoid repeated disk I/O. Wrap it in a web framework such as FastAPI or Flask and expose a predict endpoint that accepts JSON input, validates and parses it, applies the exact same preprocessing and feature transformations used during training, calls the model, and returns the prediction as JSON. Package the service and its dependencies into a Docker container so the environment is reproducible. Deploy the container to a host or orchestrator like Kubernetes or a managed service, place it behind a load balancer, and configure autoscaling for traffic. Finally, add health-check endpoints, structured logging of inputs and outputs, and monitoring for latency, error rate, and throughput.

COMMON WRONG ANSWERS Spending the answer on training or hyperparameter tuning, which the question already assumes is done. Forgetting that preprocessing at serving time must match training exactly, causing training-serving skew. Loading the model inside the request handler. Omitting input validation and any monitoring.

LIKELY FOLLOW-UPS How do you keep preprocessing consistent between training and serving? How would you handle versioning when you deploy a new model? How do you scale to handle traffic spikes?

ONE CONCRETE EXAMPLE You write a FastAPI app that loads model.pkl at startup. A POST to /predict receives a JSON body, runs it through the saved scikit-learn pipeline, and returns a label and probability. You build a Dockerfile, push the image, deploy it to a Kubernetes cluster with two replicas behind a service, and wire up a /health endpoint plus Prometheus metrics for request latency.