How would you build CI/CD for an ML model?

WHAT THIS TESTS This probes whether you understand MLOps as a superset of software CI/CD. A senior answer treats the model, the data, and the code as three artifacts that all need versioning, testing, and deployment, and explains the continuous-training feedback loop.

A GOOD ANSWER COVERS Start with continuous integration: lint and unit-test the code, then validate the data schema and statistics. Continuous training is the new stage. A pipeline pulls fresh data, retrains, and evaluates the candidate model against the current production baseline on a holdout set. Only if it passes quality and fairness gates does it get registered in a model registry with its metrics and lineage. Continuous delivery then promotes the registered model through canary or shadow deployment. Finally, continuous monitoring watches prediction distributions and drift, and can trigger the whole loop again.

COMMON WRONG ANSWERS Describing a plain build-test-deploy code pipeline. Forgetting data versioning, so retraining is not reproducible. Skipping the evaluation gate that compares candidate against baseline, which lets a worse model ship. Treating monitoring as ordinary uptime checks rather than statistical drift detection.

LIKELY FOLLOW-UPS How do you version terabyte-scale datasets? How do you guarantee training and serving features match to avoid skew? What triggers retraining, and how do you avoid retraining on bad data? How do you roll back a model?

ONE CONCRETE EXAMPLE On Vertex AI or SageMaker Pipelines you define a DAG: ingest, validate data with TensorFlow Data Validation, train, evaluate against the deployed model, and a conditional step that registers the model only when AUC improves by a threshold. A trigger fires the DAG on new data arrival or when a CloudWatch drift metric breaches a bound, and an endpoint serves the latest approved version with traffic splitting for canary rollout.