Explain a model registry's purpose and what to store per version

WHAT THIS TESTS: This question evaluates whether you understand the model registry as a control plane rather than a storage layer. At the senior level, interviewers want to see that you view MLOps as a software engineering discipline with governance, reproducibility, and lifecycle management. The registry sits at the intersection of CI/CD and ML workflows, so they are checking if you can articulate how training pipelines hand off artifacts to serving infrastructure safely and traceably. They also want to know if you distinguish between ephemeral experiment tracking and durable model governance.

A GOOD ANSWER COVERS: A strong response starts by defining the registry as a versioned system of record that decouples model artifacts from both training jobs and serving endpoints. It should mention that the registry enables promotion workflows, rollback, and audit trails. For stored metadata, hit these categories in order: first, lineage and provenance, including training dataset versions, code commit hashes, and pipeline run IDs; second, performance metrics from validation and test sets, plus fairness or business KPIs where relevant; third, the serialized artifact itself, along with its serialization format and signature; fourth, dependency manifests such as Python packages, CUDA versions, and base container images; fifth, inference contract details like input and output schemas and feature expectations; and sixth, lifecycle state, including staging labels, approval signatures, and deployment targets. Mentioning immutability and access control strengthens the answer.

COMMON WRONG ANSWERS: Red flags include describing the registry as just a place to dump pickle files or S3 buckets without versioning. Another weak pattern is conflating the registry with an experiment tracker like MLflow Tracking or Weights and Biases; experiments are for search and comparison, while the registry is for production decisions. Saying you only store the model weights and accuracy score misses the operational context. Similarly, omitting lineage or dependency information signals that you have not debugged a model that failed in production due to environment drift.

LIKELY FOLLOW-UPS: Expect the interviewer to ask how you handle model updates without downtime, how you enforce immutability of registered versions, or how you automate promotion from staging to production. They may probe your experience with specific tools like MLflow Model Registry, AWS SageMaker Model Registry, or a custom Git-based solution. Another common thread is how you integrate the registry with a feature store and monitoring stack to close the feedback loop.

ONE CONCRETE EXAMPLE: Imagine a fraud detection pipeline that retrains nightly. When a new Random Forest model passes validation, the pipeline registers version 3.2.1 with the following metadata: the training dataset snapshot ID from the feature store, the Git commit of the training code, AUC and false-positive rate on the holdout set, the serialized ONNX artifact, a requirements.txt hash, the expected input schema of 47 normalized features, and a pending approval tag. A separate deployment service polls the registry, sees the approved state change, and triggers a canary rollout. When an incident occurs, engineers query the registry to reproduce the exact training environment within minutes.