How does a model registry differ from cloud storage like S3?

What's really being asked

The interviewer wants to know if you see the difference between a filesystem and a lifecycle governance layer. Object storage is a dumb, immutable substrate; a model registry is an active control plane. They are probing whether you understand reproducibility, compliance, and safe promotion in production ML.

The full answer

First, define the registry as a system of record for trained models that decouples artifact storage from model semantics. Second, contrast it with S3 or GCS by noting that cloud storage provides versioning and durability but lacks stage semantics, meaning there is no native concept of Staging versus Production versus Archived. Third, explain that a registry tracks lineage, linking a model version back to its training run, dataset version, and code commit. Fourth, list the key metadata it should track: performance metrics such as accuracy or AUC, hyperparameters, dependency signatures including Python and CUDA versions, model input and output schemas, artifact URI pointers, the author or service that trained it, approval timestamps, and deployment event history. Fifth, mention access control and auditability, since a registry enforces who can move a model to Production.

The mistakes people make

A major red flag is saying a registry is just S3 with a good folder structure like s3://models/2024-01/model-v1.pt. Another mistake is conflating the experiment tracking database with the registry; experiments are noisy and iterative, while the registry is a curated, production-facing catalog. Candidates also err by listing only technical metadata and ignoring governance metadata like approvers and deployment logs.

What usually comes next

The interviewer may ask how you automate stage transitions with CI/CD gates, or how you handle model rollback when a deployed version degrades. They might probe schema evolution, asking how you prevent breaking changes between a model signature and its serving contract. Another follow-up is multi-region replication: whether the registry stores artifacts or only metadata and pointers.

A concrete example

Imagine a computer vision team training a ResNet classifier. The training job writes a checkpoint to GCS. The registry ingests a pointer to that GCS path but also records the training dataset hash, the Docker image digest, the mAP score, and the ONNX input schema. When the model passes shadow testing, an MLOps engineer moves it to the Staging stage in the registry, which triggers a GitOps deployment to a Kubernetes canary. After 24 hours of acceptable latency and error rates, an automated policy promotes it to Production. If latency spikes, the registry lets the team roll back to the previous Production version in minutes because the prior artifact pointer and metadata were never overwritten.