7.3 Manage Model Lifecycle and Archiving

Manage Model Lifecycle and Archiving

Quick Answer: Workspace models are versioned assets. Registering the same name again auto-increments the version. You can update only description and tags; everything else is immutable, so behavior changes require a new version. Archive (az ml model archive) hides the version from default list queries but the asset remains usable. Omit --version and you archive every version; new versions under an archived container are auto-archived. Promote across workspaces with an Azure Machine Learning registry, not MLflow stages. MLflow Staging/Production stages exist only through the MLflow SDK, are invisible in studio/CLI/SDK v2, and cannot be used as a deploy target.

Exam AI-300 Domain 2 asks you to manage model lifecycle, including archiving models. Registration (7.1) and RAI (7.2) produce a candidate. Lifecycle is how that candidate is labeled, hidden when retired, and promoted into other workspaces without rewriting the artifact.

Versions, tags, and immutability

A registered model has a name (the container) and integer versions. The first az ml model create --name fraud-gbm is version 1 unless you pass --version. The next create with the same name becomes 2, then 3, and so on. Each version points at an immutable blob of files (the MLflow folder, custom file, or Triton repo).

Microsoft is explicit about updates:

az ml model update --name fraud-gbm --version 7 --set description="GBM after RAI review." --set tags.stage="Prod"

SDK v2 sets model.description and model.tags then calls ml_client.models.create_or_update. Only description and tags are mutable. Weights, type, path, and signature are not. To change how the model scores, log and register a new version. Tags are the supported v2 place to store workflow labels (stage=candidate, stage=Prod, approved_by=risk, rai_dashboard=loan-v4-fairness). Those tags are not MLflow stages; they are ordinary key/value metadata you can filter in studio search.

Everyday CLI/SDK operations:

• List — az ml model list (all names) or az ml model list --name fraud-gbm (every version of that name). SDK: ml_client.models.list() / list(name=...).
• Show — az ml model show --name fraud-gbm --version 7. SDK: ml_client.models.get(name=..., version=...).
• Update — description and tags only.
• Archive — covered next.

Azure Machine Learning does not support renaming a model. It does not support deleting the entire model container. The MLflow client can delete_model_version for one version; deleting every version is the only way to empty a name. Prefer archive so endpoints, jobs, and RAI dashboards that still point at the version keep working and lineage stays in the workspace.

Archive versus delete

Archiving hides a model from default list queries such as az ml model list. You can still reference and use an archived model in jobs, pipelines, and endpoint deployments. That is the production-safe retire operation.

az ml model archive --name fraud-gbm --version 3

SDK: ml_client.models.archive(name="fraud-gbm", version="3").

Two rules catch people on the exam:

1. If you omit --version (or the SDK version argument), the command archives all versions of that name. A stem that says "archive the old candidate" and shows a command with only --name is wiping the whole family from lists, including the production version.
2. If the container is archived, a newly created version is also archived automatically. You cannot sneak a live version out from under an archived name by incrementing.

Archive is not Azure Blob's archive access tier, and it is not the MLflow Archived stage. Blob archive is a storage-account cost tier with rehydration delay. MLflow Archived is a stage flag you set with transition_model_version_stage that studio will not show. Azure Machine Learning archive is the v2 asset-lifecycle hide.

MLflow stages: exist, but are not the v2 API

When the tracking URI points at a workspace, the MLflow client still implements stages: None, Staging, Production, Archived. You can client.transition_model_version_stage(name, version, stage="Staging"), optionally with archive_existing_versions=True, and load with models:/<name>/Production.

Microsoft documents the limitations in the same article:

• You can access stages only with the MLflow SDK.
• Stages are not visible in Azure Machine Learning studio.
• You cannot retrieve stages with Azure Machine Learning SDK v2, CLI v2, or the REST API.
• Deployment from a specific model stage is not currently supported.
• Stage names are case sensitive (Staging not staging).

So a 2026 AI-300 answer that says "transition the model to Production, then deploy from that stage" is describing open-source MLflow / Databricks workspace registry behavior, not Azure Machine Learning v2. The v2 equivalent is: register a version, run RAI, tag it (tags.stage=Prod or approved=true), archive superseded versions, and deploy by name plus version (or by registry URI). If a teammate already set MLflow stages, treat them as an unofficial sidecar, not as something az ml online-deployment create can consume.

Promote with registries, not cross-workspace MLflow

Assets (models, environments, components, data) are workspace-agnostic once you put them in an Azure Machine Learning registry. Resources (compute, jobs, endpoints) stay workspace-specific. Registries replicate blobs and a container registry across the regions you list so a model trained in East US can be deployed from a West US workspace without a copy-paste job.

Reference a promoted model as:

azureml://registries/<registry-name>/models/<model-name>/versions/<version>

Create that registry in CLI v2, studio, portal, or REST (az ml registry create). Names are 2–32 characters, start with alphanumeric, allow hyphen and underscore, and are unique in the Microsoft Entra tenant. You cannot rename a registry after creation. MLflow cannot manage organizational registries; CLI v2 and studio can. MLflow also cannot register a run from workspace A into workspace B. The documented way to preserve lineage while moving models is the registry, not a second mlflow.register_model against another tracking URI.

A clean promotion path for this exam:

1. Train and log an MLflow folder in the dev workspace; register fraud-gbm version 7.
2. Run the RAI pipeline on version 7; attach a scorecard.
3. Tag version 7 (stage=Prod, rai=passed).
4. Create (or update) the same model in the organizational registry from that version.
5. Test and prod workspaces deploy azureml://registries/contoso-ml/models/fraud-gbm/versions/7.
6. Archive dev versions 3–6 with --version so version 7 remains listed in dev.

Exam scenario

fraud-gbm versions 1–6 are experiments. Version 7 passed RAI and a week of shadow traffic. The MLOps engineer runs az ml model update --name fraud-gbm --version 7 --set tags.stage=Prod, archives versions 3 through 6 individually, and publishes version 7 into contoso-ml registry. The production workspace's online endpoint YAML sets model: azureml://registries/contoso-ml/models/fraud-gbm/versions/7. A colleague had already called transition_model_version_stage(..., stage="Production") in a notebook; that flag is invisible in studio and cannot be the model: field on the deployment. They do not run az ml model archive --name fraud-gbm without a version, which would hide version 7 too.

Common trap

Treating MLflow Staging/Production as the Azure Machine Learning promotion and deploy API. Sibling traps: archiving without --version and hiding the production version; deleting instead of archiving so lineage and running endpoints break; trying to rename a model; editing weights in place instead of a new version; expecting the MLflow client to write to an organizational registry or another workspace; confusing model archive with Blob archive tier rehydration.