An ML platform team must keep many trained artifacts reproducible: which weights go with which code, data snapshot, and metrics when someone asks to roll back last week's recommender. What is the established best practice for managing those trained model versions?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Let me show you how this works in the real world. You've got a dozen "final_model_v2_really_final.pkl" files and nobody knows which one is live—classic mess. Best practice is a model registry: a system that versions the artifact, hooks it to training run IDs, metrics, data refs, and stages like Staging vs Production. Think of it like a package manager for models instead of a junk drawer. Boss walks in: "Roll back Friday's recommender." With a registry you promote the prior version in minutes. Without it you're grepping S3 and praying. Exam trap: "just save everything in one folder" or "delete old ones to save space" or "random names." Those fail audits and 3 a.m. incidents. Registry + lineage + keep history for rollback. That's the habit. Got it? Sweet—build that into your pipeline early.
Full explanation below image
Full Explanation
In modern MLOps, a model registry is the system of record for trained model artifacts. It assigns immutable or clearly ordered versions to models, stores or references the binary (or graph) artifacts, and attaches metadata such as training run identifiers, hyperparameters, evaluation metrics, dataset versions, code commits, authorship, and approval status. Registries typically support lifecycle stages—for example None, Staging, Production, and Archived—so promotion and rollback are deliberate operations rather than ad hoc file copies. Tools in this category include services such as MLflow Model Registry, cloud provider model catalogs, and similar platforms; the design pattern matters more than any single product name.
This practice enables reproducibility (recreate or re-serve a known good version), comparison across experiments, governance and audit trails, and safe continuous delivery of models. When production metrics degrade, teams can pin traffic back to a previous registry version with known lineage instead of hunting through unstructured storage.
Saving all models in one ungoverned folder fails because there is no enforced version identity, no consistent metadata, and no stage gates—collisions and "which file is live?" incidents are common. Deleting old versions as soon as a new train succeeds destroys rollback capability and historical comparison needed for audits and postmortems. Random filenames maximize ambiguity and break automated deployment pipelines that expect deterministic version references.
Best practices include registering models only from tracked training runs, requiring evaluation thresholds before Production stage, recording signatures and input/output schemas, integrating the registry with CI/CD and feature stores where applicable, and retaining prior production versions for a policy-defined retention window. Storage cost is managed with lifecycle policies, not by erasing the only rollback path. On certification and interview questions, the best practice for managing versions of trained models is the model registry pattern—not ad hoc folders, immediate deletion of history, or random naming. Associate "version and manage trained models" with registry plus metadata and stages, and you will answer consistently with industry MLOps guidance used in production organizations that treat models as first-class deployable artifacts alongside application services and configuration, with clear ownership and change control across the full model lifecycle from experiment through retirement.