In an MLOps context, what does model versioning refer to?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Let me show you how this works in the real world. Model versioning is your changelog for ML: model-v3 beats model-v2, and you can prove what data, code, and hyperparameters built each one. Think git tags, but for models and their baggage—artifacts, metrics, approval status. You're not forced to invent a brand-new architecture every time. You're not "versioning" by just making it faster. And spraying one file across twenty servers is scaling, not history. Exam trap: confusing deploy replicas with versions. When the boss asks "which model is in prod and can we roll back?" versioning is the answer. Nice and clean: track it, label it, promote it. You've done the right thing learning this.
Full explanation below image
Full Explanation
Model versioning in MLOps is the disciplined practice of identifying, storing, and governing successive iterations of machine learning models along with the assets required to understand and reproduce them. Each version typically links a trained artifact (weights, graph, or serialized pipeline) to metadata such as training code revision, dataset snapshot or feature store view, hyperparameters, evaluation metrics, creator, timestamp, and deployment stage. Registries and experiment trackers implement this so teams can compare candidates, promote a champion model, roll back a regression, and audit decisions for compliance.
Versioning is not synonymous with always redesigning architectures from scratch; incremental fine-tunes, retrains on new data, and configuration changes still receive new version identifiers. It is also not a synonym for performance scaling: improving accuracy or serving throughput may motivate a new version, but the act of versioning is about lineage and control, not the optimization technique itself. Likewise, deploying identical model binaries to many servers is horizontal scaling for capacity and availability; those replicas usually share one model version rather than creating new versions by mere replication.
Effective versioning enables reproducibility ("what exactly produced this prediction?"), collaboration across data science and platform teams, and safer continuous delivery through staged promotion (dev → staging → prod). Best practices include immutable version IDs, signed artifacts, retention policies, and clear linkage between model version and feature schema to avoid train/serve skew after upgrades. For certification-style questions, map "model versioning" to tracking and managing model iterations and associated assets—not greenfield rebuilds, raw performance tuning, or multi-server copies alone. Without versioning, teams cannot answer audit questions, cannot compare A/B candidates fairly, and cannot restore a known-good model after a bad release.