Study guide
7.3 Manage Model Lifecycle and Archiving
Microsoft AI-300: Operationalizing Machine Learning and Generative AI Solutions Exam
Track your progress as you read
Finished sections get a check mark.
1 Introduction & Exam Overview
1.1 Current Exam Facts 1.2 Skills Measured, Format, and How This Guide Is Organized 1.3 Candidate Profile, Azure ML v2, Foundry, and DevOps Tooling
2 Chapter 2: Azure Machine Learning Workspaces, Datastores, Compute, and IAM
2.1 Create and Manage Azure Machine Learning Workspaces 2.2 Create and Manage Datastores 2.3 Create and Manage Compute Targets 2.4 Configure Identity and Access Management for Workspaces
3 Chapter 3: Azure Machine Learning Data Assets, Environments, Components, and Registries
3.1 Create and Manage Data Assets 3.2 Create and Manage Environments 3.3 Create and Manage Components 3.4 Share Assets Across Workspaces with Registries
4 Chapter 4: Infrastructure as Code, GitHub, and Network Isolation for Azure ML
4.1 GitHub Integration and Git Source Control for Machine Learning Projects 4.2 Deploy Workspaces and Resources with Bicep and Azure CLI 4.3 Automate Resource Provisioning with GitHub Actions 4.4 Restrict Network Access to Machine Learning Workspaces
5 Chapter 5: MLflow Tracking, AutoML, Training Jobs, and Hyperparameter Sweeps
5.1 Configure Experiment Tracking with MLflow 5.2 Use Automated Machine Learning to Explore Optimal Models 5.3 Notebooks, Command Jobs, and Training Scripts 5.4 Automate Hyperparameter Tuning
6 Chapter 6: Distributed Training, Training Pipelines, and Job Comparison
6.1 Manage Distributed Training for Large and Deep Learning Models 6.2 Implement Training Pipelines 6.3 Compare Model Performance Across Jobs
7 Chapter 7: Model Registration, Responsible AI, and Lifecycle Management
7.1 Register MLflow Models and Package Feature Retrieval Specs 7.2 Evaluate Models with Responsible AI Principles 7.3 Manage Model Lifecycle and Archiving
8 Chapter 8: Online Endpoints, Batch Endpoints, Rollout, and Rollback
8.1 Deploy Models to Managed Online Endpoints 8.2 Deploy Models to Batch Endpoints 8.3 Test, Troubleshoot, Progressive Rollout, and Safe Rollback
9 Chapter 9: Data Drift, Production Metrics, Retraining, and Alerts
9.1 Detect and Analyze Data Drift 9.2 Monitor Production Metrics and Trigger Retraining or Alerts
10 Chapter 10: Microsoft Foundry Resources, IAM, Networking, and IaC
10.1 Create and Configure Foundry Resources and Project Environments 10.2 Managed Identities and RBAC for Foundry 10.3 Foundry Network Security and Private Networking 10.4 Deploy Foundry Infrastructure with Bicep and Azure CLI
11 Chapter 11: Deploying and Managing Foundation Models
11.1 Serverless API Endpoints and Managed Compute for Foundation Models 11.2 Select Foundation Models for Specific Use Cases 11.3 Model Versioning and Production Deployment Strategies 11.4 Provisioned Throughput Units for High-Volume Workloads
12 Chapter 12: Prompt Design, Variants, and Git Version Control
12.1 Design and Develop Prompts 12.2 Create Prompt Variants and Compare Performance 12.3 Version Control for Prompts with Git
13 Chapter 13: Evaluation Datasets, Quality Metrics, Safety, and Automated Workflows
13.1 Test Datasets and Data Mapping for Evaluation 13.2 Groundedness, Relevance, Coherence, and Fluency 13.3 Risk and Safety Evaluations 13.4 Built-in and Custom Automated Evaluation Workflows
14 Chapter 14: Continuous Monitoring, Performance, Cost, Tracing, and Logging
14.1 Continuous Monitoring in Microsoft Foundry 14.2 Latency, Throughput, Token Use, and Cost Metrics 14.3 Logging, Distributed Tracing, and Production Debugging
15 Chapter 15: Retrieval Tuning, Embeddings, Hybrid Search, and RAG Evaluation
15.1 Tune Similarity Thresholds, Chunk Sizes, and Retrieval Strategies 15.2 Select and Fine-Tune Embedding Models 15.3 Hybrid Search: Semantic and Keyword Retrieval 15.4 RAG Relevance Metrics and A/B Testing
16 Chapter 16: Fine-Tuning Methods, Synthetic Data, and Promotion to Production
16.1 Advanced Fine-Tuning Methods (LoRA, QLoRA, Full) 16.2 Create and Manage Synthetic Data for Fine-Tuning 16.3 Monitor, Optimize, and Promote Fine-Tuned Models
7.3 Manage Model Lifecycle and Archiving
Key Takeaways Explain This Topic AI
Re-registering the same model name auto-increments the version. For Azure Machine Learning v2 model assets you can update only description and tags; any other change requires a new version.
Archive with az ml model archive or ml_client.models.archive. Archiving hides the asset from default list queries such as az ml model list but you can still reference and deploy it. Omit --version and you archive every version; a new version under an archived container is also archived.
Do not treat MLflow stages (None, Staging, Production, Archived) as the Azure Machine Learning v2 promotion API. Stages are visible only through the MLflow SDK, not studio, CLI v2, or SDK v2, and deployment from a stage is not supported.
Promote across workspaces with an Azure Machine Learning registry URI (azureml://registries/<name>/models/<model>/versions/<n>). The MLflow client cannot target organizational registries or copy models across workspaces.
Azure Machine Learning does not support renaming a model or deleting the entire model container. Delete individual versions if you must; prefer archive so lineage remains.
Last updated: August 2026
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:
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.
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.
- Mechanism Visible in studio / CLI v2 Can deploy from it Cross-workspace
- MLflow stages ( Staging , Production ) No — MLflow SDK only No No
- v2 tags ( tags.stage=Prod ) Yes Indirect: you still deploy a name plus version No
- v2 archive Hidden from default lists Yes — archived versions remain usable No
- Organizational registry URI Yes Yes Yes — this is the promotion path
- 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:
Train and log an MLflow folder in the dev workspace; register fraud-gbm version 7 .
Run the RAI pipeline on version 7 ; attach a scorecard.
Tag version 7 ( stage=Prod , rai=passed ).
Create (or update) the same model in the organizational registry from that version.
Test and prod workspaces deploy azureml://registries/contoso-ml/models/fraud-gbm/versions/7 .
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.