What is a model registry's purpose in CI/CD4ML and its CI/CD interaction?

WHAT THIS TESTS: The interviewer wants to know if you understand the model registry as the control plane for model artifacts in a machine learning continuous delivery pipeline, not merely as a backup location. They are checking whether you can articulate how trained models move from the experimentation phase into automated deployment and how the registry creates a clean contract between data science and engineering.

A GOOD ANSWER COVERS: First, the registry acts as a versioned artifact store where CI pipelines publish models that have passed training, validation, and testing gates. Second, it holds metadata such as training parameters, data lineage, and performance metrics that let teams audit and compare candidates. Third, it supports promotion workflows so that only artifacts meeting production criteria advance from staging to release. Fourth, the CD stage consumes approved model versions from the registry to deploy to serving infrastructure, enabling rollback by switching version pointers rather than retraining.

COMMON WRONG ANSWERS: Calling the registry just a database or cloud storage bucket without mentioning versioning or lifecycle states. Describing CI as training and CD as deployment but leaving a gap where the model artifact is passed manually. Claiming the registry replaces experiment tracking tools instead of complementing them. Ignoring governance, such as who can approve a model for production release.

LIKELY FOLLOW-UPS: How do you handle model schema changes between versions? What is your strategy for canary deployments or A/B testing using the registry? How do you reproduce a model from six months ago given only the registry entry? How do you secure the registry so that production serving cannot accidentally pull an unapproved candidate?

ONE CONCRETE EXAMPLE: Imagine a pipeline that retrains a fraud detection model weekly. During CI, the training job completes and the new model achieves a validation AUC above the threshold. The CI pipeline pushes the serialized model, its hyperparameters, and the training dataset identifier to the registry as version 2.3.1-rc1. A human reviewer or automated policy checks fairness metrics and promotes it to 2.3.1-prod. The CD pipeline detects the new production tag, pulls the artifact, and updates the inference service. If latency spikes after deployment, the CD system rolls back to version 2.3.0 by repointing to the previous registry entry without running a new training job.