Why does a team need a model registry? What information should it store?

What the interviewer wants to hear

• Central source of truth for model versions
• Metadata: metrics, training data version, code commit, owner
• Stages or aliases such as staging and production with approvals
• Enables traceability and quick rollback

Model answer

Without a registry, models end up as files in random buckets and nobody is sure which one is in production or how it was built. A model registry is the single source of truth. For every version it stores the artifact plus metadata: evaluation metrics, the training run, code commit, data version, dependencies, the owner and a description. It also tracks lifecycle state, such as candidate, staging, production or archived, often with approval steps. Deployment pipelines pull a specific registered version rather than a loose file, so every prediction service can be traced back to its training data and code. That makes audits easy and rollback simple: point production back to the previous approved version. Tools like MLflow provide this, and cloud platforms have their own registries.

More easy MLOps Engineer questions

• What is MLOps, and how is it different from traditional DevOps?
• How do you make a model training run reproducible?
• How would you deploy a trained scikit-learn model as a REST API?
• What would you monitor for a model running in production?
• What is training-serving skew, and how do you prevent it?
• How do you decide between batch predictions and a real-time model API?
• Explain the difference between data drift and concept drift, and how you would detect each.
• What makes a good Docker image for a model-serving service?
• Which Kubernetes concepts matter most when you deploy a model service, and why?