Model registry and versioning quiz

Question 1

What distinguishes an experiment tracking system from a model registry in an ML platform?

Accepted Answer

Tracking logs runs and metrics; the registry manages promoted artifacts with lifecycle and governance

Answer

They are synonymous—both store models and metrics

Answer

The registry tracks hyperparameters; tracking manages deployment endpoints

Answer

Tracking is only for deep learning; the registry is for classical ML

Question 2

In MLflow Model Registry, what are the three built-in lifecycle stages and what do they signify?

Accepted Answer

Staging, Production, and Archived

Answer

Dev, Staging, and Prod

Answer

Training, Validation, and Serving

Answer

Experimental, Staging, and Deployed

Question 3

How do you register an MLflow run's logged model artifact into the Model Registry in a single API call?

Accepted Answer

mlflow.register_model(model_uri, name)

Answer

mlflow.save_model(run_id, stage='Production')

Answer

mlflow.promote_model(run_id, stage='Staging')

Answer

mlflow.create_registered_model(run_id)

Question 4

Why is naive semantic versioning (MAJOR.MINOR.PATCH) insufficient for ML models, and what additional metadata must accompany a model version?

Accepted Answer

SemVer lacks training data provenance, metrics snapshots, and feature schema

Answer

SemVer is fully sufficient for ML models

Answer

SemVer only lacks the framework version

Answer

The model file checksum alone supplements SemVer

Question 5

How does DVC track model artifacts alongside code, and how does it integrate with Git to enable reproducible checkouts?

Accepted Answer

DVC stores artifacts in remote storage and commits pointer files to Git, enabling atomic code+model checkouts

Answer

DVC stores binary weights directly in Git LFS

Answer

DVC replaces Git for all versioning in ML projects

Answer

DVC only tracks datasets, not model artifacts

Question 6

What is model lineage, and which registry features enable end-to-end lineage tracking?

Accepted Answer

Lineage is the traceable chain from data through training to deployment, enabled by linking registry versions to source runs

Answer

Lineage only tracks who deployed the model, not how it was built

Answer

Lineage is automatically captured by Git tags alone

Answer

Only cloud-native registries like SageMaker and Vertex AI support lineage

Question 7

Describe the champion/challenger pattern as implemented through a model registry.

Accepted Answer

Both versions coexist in the registry with aliases; traffic is split and the winner replaces the current champion via alias swap

Answer

Champion/challenger requires two separate isolated model registries

Answer

The challenger must complete a full Staging cycle before receiving any live traffic

Answer

Champion/challenger applies only to A/B tests, not canary deployments

Question 8

What is a model card, and why should it be stored as a first-class artifact in the model registry?

Accepted Answer

A model card documents intended use, subgroup metrics, limitations, and ethics; stored in the registry for governance and compliance

Answer

A model card stores compressed model weights for fast loading

Answer

A model card is a Kubernetes deployment configuration file

Answer

Model cards are required only for NLP models by regulation

Question 9

MLflow 2.x deprecated lifecycle stages in favor of named aliases. What fundamental problem do aliases solve that the fixed three stages did not?

Accepted Answer

Aliases are arbitrary named pointers allowing multiple custom labels per version, unlike the fixed three stages

Answer

Aliases add cryptographic signing that stages lacked

Answer

Aliases automatically deploy models whereas stages required manual action

Answer

Aliases are only for experiment tracking, not the model registry

Question 10

Design a CI/CD gate that blocks model promotion to a production alias in the registry unless evaluation criteria are met. What does the pipeline look like?

Accepted Answer

An evaluation job compares candidate metrics to the production baseline and calls the registry API to set the production alias only if all thresholds pass

Answer

Promotion should always be manual; automation introduces unacceptable risk

Answer

CI/CD gates apply to code pipelines only, not ML model promotion

Answer

The registry automatically promotes models based on lowest validation loss

Question 11

How does Google Vertex AI Model Registry differ from MLflow Model Registry in multi-region deployment and governance?

Accepted Answer

Vertex AI integrates IAM, multi-region endpoints, and org-level audit logs natively; MLflow requires custom RBAC and storage setup

Answer

MLflow natively supports multi-region replication; Vertex AI does not

Answer

Both are identical in governance capabilities for enterprise use

Answer

Vertex AI only supports TensorFlow models in its registry

Question 12

In AWS SageMaker Model Registry, what is a model package group and how does its approval status gate deployment?

Accepted Answer

It is a versioned container for model packages, each gated by approval status (Pending/Approved/Rejected) before deployment

Answer

A model package group is a collection of Docker images for inference

Answer

Approval status applies only to real-time inference, not batch transform jobs

Answer

SageMaker does not support manual approval workflows in its registry

Question 13

What is model artifact immutability in a registry context, and why is it critical for regulatory compliance?

Accepted Answer

Once registered, a version's artifact cannot be overwritten; any historical prediction can be reproduced for audit and compliance

Answer

Immutability means models cannot be deleted for 30 days after registration

Answer

Immutability applies only to the model card, not the serialized weights

Answer

Immutability is an optional enterprise-only feature absent from open-source registries

Question 14

How is a model rollback performed in a production registry workflow without retraining?

Accepted Answer

Re-aliasing the previous stable version pointer causes the serving layer to load the older immutable artifact instantly

Answer

Rollback requires retraining from the previous dataset snapshot

Answer

Rollback deletes the faulty version from the registry to prevent confusion

Answer

Rollback is impossible without a blue-green environment

Question 15

How would you implement shadow deployment for a new model version using a model registry?

Accepted Answer

Both versions are in the registry; the shadow receives mirrored traffic with predictions logged but not returned to users

Answer

Shadow deployment requires a completely separate cluster without registry involvement

Answer

Shadow deployment means the new model is only evaluated offline, never receiving real requests

Answer

Only real-time inference models can participate in shadow deployment

Question 16

What metadata should be automatically captured at model registration time to ensure future reproducibility and root-cause analysis?

Accepted Answer

Run ID, dataset hash, Git SHA, framework versions, hyperparameters, metrics, feature schema, and registrant identity

Answer

Only the model file checksum is needed for reproducibility

Answer

Just the model file and the training completion timestamp

Answer

Only hyperparameters and final validation accuracy are required

Question 17

How does a feature store integrate with a model registry to prevent training-serving skew?

Accepted Answer

The registry records the feature view name and version used at training; serving uses the same version to eliminate skew

Answer

Feature stores and model registries are entirely separate systems that do not integrate

Answer

Feature store version is logged only in experiment tracking, not in the model registry

Answer

Training-serving skew is prevented by retraining the model daily with fresh data

Question 18

What are the unique versioning challenges posed by large language models in a registry compared to classical ML models?

Accepted Answer

LLMs require hierarchical versioning of base weights, adapters, quantization variants, and prompt templates

Answer

LLMs have no unique registry challenges beyond larger file sizes

Answer

LLMs should not be stored in standard registries due to their size

Answer

Only the tokenizer version matters for LLM registry governance

Question 19

How does MLflow's pyfunc flavor enable framework-agnostic model serving from the registry?

Accepted Answer

pyfunc wraps any framework behind a uniform predict() interface using the MLmodel manifest for deserialization

Answer

pyfunc only supports scikit-learn models from the registry

Answer

pyfunc requires manual Docker image configuration per framework

Answer

pyfunc is only suitable for batch inference, not real-time serving

Question 20

Describe a registry-driven canary deployment strategy for an ML model update.

Accepted Answer

A small traffic slice routes to the canary alias; traffic is incrementally shifted as metrics validate, with instant rollback via alias swap

Answer

Canary deployment means deploying the new model to a non-production test environment only

Answer

Canary requires a complete production downtime window to switch model versions

Answer

Canary deployment is technically impossible when using a versioned model registry

Question 21

What are model registry webhooks and how do they enable event-driven MLOps automation?

Accepted Answer

Webhooks fire HTTP callbacks on registry events, enabling event-driven notifications and deployment automation

Answer

Webhooks encrypt model artifacts at rest when they are accessed

Answer

Webhooks are only used for security auditing in enterprise deployments

Answer

Webhooks only function with self-hosted MLflow deployments, not cloud registries

Question 22

How should ONNX format be used in a model registry to support cross-platform and cross-framework serving?

Accepted Answer

ONNX is logged alongside the native artifact; ONNX Runtime serves it cross-platform without framework dependencies

Answer

ONNX replaces the model registry entirely by providing a universal format

Answer

ONNX is only appropriate for edge/IoT deployment, not production cloud servers

Answer

Standard model registries cannot store ONNX models

Question 23

How does Azure Machine Learning Model Registry handle environment pinning for reproducible inference at deployment time?

Accepted Answer

Azure ML registers a pinned Environment (Docker image + conda YAML) linked to the model version for reproducible serving

Answer

Azure ML uses only public Docker Hub images without any version pinning

Answer

Azure ML only pins the Python major version, not library patch versions

Answer

Environment pinning is unsupported in the Azure ML model registry

Question 24

What is the difference between model tags and model aliases in a registry, and when should each be used?

Accepted Answer

Tags are metadata for search and governance; aliases are named routing pointers for serving infrastructure

Answer

Tags and aliases are identical features with different syntax

Answer

Aliases are for experiment tracking; tags are for the model registry only

Answer

Only one alias can exist per registered model at any time

Question 25

How does model registry RBAC prevent unauthorized promotion to production, and what roles are typically defined?

Accepted Answer

RBAC restricts stage transitions by role; only authorized users or pipelines can promote to Production, enforced by IAM or SSO

Answer

Any authenticated user with registry access can promote a model to Production

Answer

RBAC in model registries only controls who can delete model versions

Answer

RBAC is unavailable in open-source registries like MLflow

Question 26

What constitutes a 'model package' as a best practice for registry-driven reproducible deployment?

Accepted Answer

A model package bundles artifact, inference code, environment spec, and schema into a self-contained deployable unit

Answer

A model package is simply a ZIP archive of the serialized model weights

Answer

Model packages apply only to SageMaker and are not a general best practice

Answer

A model package excludes preprocessing code to keep the artifact lightweight

Question 27

How do you version LoRA adapters for a fine-tuned LLM in a registry while keeping the multi-gigabyte base model artifact shared and non-duplicated?

Accepted Answer

Adapters are registered separately with a metadata pointer to the parent base model version; base weights are shared

Answer

Each LoRA fine-tune must store a full copy of the base weights for reproducibility

Answer

LoRA adapters cannot be stored in standard model registries and require custom tooling

Answer

Base model and LoRA adapter must always reside in the same single registry entry

Question 28

What is dataset co-registration with a model version in the registry, and why is it important for root-cause analysis?

Accepted Answer

Co-registration links a dataset version URI and hash to the model version, enabling exact reproduction and root-cause analysis

Answer

Dataset versioning is a data engineering concern that should not appear in the model registry

Answer

Only the dataset name (not the version) needs to be recorded in the registry

Answer

Dataset co-registration is required only in financial services regulations

Question 29

How can model registry promotion events automatically trigger downstream monitoring configuration for the newly deployed version?

Accepted Answer

Registry promotion events trigger a listener that auto-provisions monitoring jobs scoped to the new version's schema

Answer

Monitoring configuration must always be set up manually after each deployment

Answer

Registry events only send email notifications and cannot trigger external systems

Answer

Monitoring configuration is embedded statically in the model artifact itself

Question 30

What is the 'evaluate before register' pattern versus 'register then evaluate', and when should each be preferred?

Accepted Answer

'Evaluate before register' only creates registry entries for passing models; 'register then evaluate' registers first and gates promotion after evaluation

Answer

Both patterns produce identical outcomes and the choice is purely aesthetic

Answer

'Register then evaluate' is always preferred for compliance-sensitive industries

Answer

'Evaluate before register' is only available in MLflow, not cloud registries

Test yourself