Study guide
11.3 Model Versioning and Production Deployment Strategies
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
11.3 Model Versioning and Production Deployment Strategies
Key Takeaways Explain This Topic AI
Pin a dated model version in production. Standard deployment upgrade policies are OnceNewDefaultVersionAvailable, OnceCurrentVersionExpired (the default when the property is null), and NoAutoUpgrade. Provisioned deployments are not auto-upgraded.
Preview models are not for production and can be force-upgraded or retired with about 30 days of notice. GA Foundry Models sold by Azure typically follow an 18-month lifecycle; some partner GA models (Anthropic, DeepSeek, Fireworks, Mistral) follow 12 months.
The Developer SKU is for fine-tuned model evaluation only: 24-hour lifetime, automatic delete, no SLA, and no data-residency guarantee. It is not a production deployment type.
Spillover sends overflow from a provisioned deployment to a Standard deployment of the same model and version in the same Foundry resource when the PTU path returns 429, 500, 503, or certain 400 long-context errors. Azure OpenAI models that support PTU support spillover; some other Foundry Models currently do not.
Production cutovers use a second deployment (canary or side-by-side) or an in-place provisioned migration (about 20 to 30 minutes, same deployment name). Do not load-balance or fail over across different model versions.
Last updated: August 2026
Model Versioning and Production Deployment Strategies
Quick Answer: Pin a dated model version in production. Standard SKUs can auto-update ( OnceNewDefaultVersionAvailable or OnceCurrentVersionExpired ) or refuse ( NoAutoUpgrade ). Provisioned deployments are not auto-upgraded. Roll out with a second deployment (canary) or an in-place PTU migration . Use spillover from PTU to Standard for overflow. Developer tier is a 24-hour fine-tune eval SKU with no SLA — not production.
Domain 3 asks you to implement model versioning and production deployment strategies . Sections 11.1 and 11.2 chose Serverless versus managed compute and picked a model family. This section decides how that deployment behaves when Microsoft publishes a new snapshot, when you cut traffic, and when PTUs run out.
Two version numbers appear on every call path. The model version is the dated snapshot of weights ( gpt-4.1 version 2025-04-14 ). The API version is the HTTP contract ( api-version on REST, or the SDK generation). A new model version does not always require a new API version. Pin both in production configuration; do not treat either as latest in application code.
Also keep family, version, and variant distinct. A family is a generation (GPT-4o, GPT-5). A version is a dated release inside that family. A variant is a size or capability tier ( gpt-5-mini , gpt-5-nano ). Partner models sometimes publish a new model ID instead of a new date ( Meta-Llama-3-70B-Instruct versus Llama-3.3-70B-Instruct ). Read the card; do not assume a silent swap.
Pin versus auto-update on Standard SKUs
For Global Standard , Data Zone Standard , and Standard (and Priority Processing, which follows the Standard upgrade path), you set versionUpgradeOption on the deployment:
Policy What happens When to use
OnceNewDefaultVersionAvailable Within about two weeks after Microsoft names a new default, the deployment moves to that default Early testing, non-critical apps that should track defaults
OnceCurrentVersionExpired The deployment stays on the pinned version until retirement, then moves to the then-current default. null means this policy Most production apps that want a freeze with a safety net
NoAutoUpgrade The deployment never auto-upgrades. At retirement it stops working and callers see errors Strict change control, if you will migrate before the retirement date
Azure notifies customers at least two weeks before a new version becomes the default. Auto-upgrades of Standard SKUs roll region by region even if the new version is not yet offered as a standalone SKU in that region. You cannot extend a retirement date.
Production default: pin the dated version and set OnceCurrentVersionExpired or NoAutoUpgrade only if the release train will migrate before retirement. Do not leave a customer-facing copilot on OnceNewDefaultVersionAvailable unless product has accepted silent behavior change.
Lifecycle stages on the card are Preview, GA, Legacy (optional), Deprecated, and Retired. Preview can change weights and schema and is not recommended for production ; when Microsoft retires a preview, deployments are force-upgraded or terminated with at least 30 days of notice. GA models sold by Azure typically live 18 months from launch (deprecated to new customers at 12 months; replacement in Global Standard about 90 days before retirement; provisioned replacement about 30 days before). Anthropic, DeepSeek, Fireworks, and Mistral GA models follow a 12-month lifecycle. Retired inference returns 410 Gone . Subscription owners with active deployments get email at least 60 days before a GA retirement; Azure Service Health advisories use the Azure OpenAI Service product name.
Provisioned deployments are not auto-upgraded. You migrate them. Two supported patterns:
In-place migration. Change the model version or even the model family on the same provisioned deployment name and PTU size. Azure shifts traffic over about 20 to 30 minutes . The deployment shows provisioning state Updating , then Succeeded . Version updates can use the portal; family changes use REST or Azure CLI. Capacity must exist for the target.
Side-by-side (multi-deployment). Create a second provisioned (or Standard) deployment, shift traffic yourself, watch Azure Monitor until the old deployment shows no requests for 5 to 10 minutes, then delete the old one. This is the canary. You need quota for both deployments during the overlap.
Batch deployments also move side-by-side: deploy the new model, resubmit jobs, retire the old deployment.
Canary, swap, spillover, and Developer
Foundry Serverless deployments do not use the Azure Machine Learning online-endpoint traffic map from Domain 2. You still canary by creating a second deployment :
Give the candidate a new deployment name and the new model version.
Point a fraction of application traffic, a preview slot, or an evaluation suite at the candidate. Azure API Management or application configuration can split, but the two deployments must be the same model and version if you fail over or round-robin — mixing versions causes surprising answers.
Promote by swapping the name your production code calls (or swapping gateway backends). Keep the previous deployment until rollback is no longer needed.
Delete the old deployment only after metrics are quiet. On PTU SKUs, unused hours still bill until delete.
Spillover is the overflow strategy for provisioned Azure OpenAI deployments. You pair a PTU deployment with a Standard deployment of the same model and version in the same Foundry resource . When the PTU path is full or unhealthy, the service redirects the request:
HTTP 429 when PTUs are exhausted
HTTP 400 for some long-context requests that PTU cannot serve (for example GPT-4.1 provisioned context under 128,000 tokens)
HTTP 500 or 503 server errors
Configure spillover for every request with spilloverDeploymentName on the provisioned deployment, or per request with the x-ms-spillover-deployment header. If both are set, the deployment property wins . Response headers x-ms-spillover-from-deployment , x-ms-deployment-name , and x-ms-spillover-error tell you a spill happened. Spilled tokens bill at Standard input, cache, and output rates; PTU hours do not double-charge those requests. All Azure OpenAI models that support provisioned throughput support spillover. Some other Foundry Models (Azure DeepSeek, Meta Llama) do not currently. Microsoft recommends enabling spillover on global and data zone provisioned deployments so bursts do not surface as user-facing 429s.
Developer ( DeveloperTier ) is easy to misuse on the exam. It exists so you can evaluate a fine-tuned model cheaply. Properties that make it illegal for production:
- 24-hour lifetime , then automatic deletion
- No SLA
- No data-residency guarantee (processing may use any Azure region)
- Pay-per-token, but that does not make it a cheap Global Standard clone
Put fine-tuned production traffic on Standard, Data Zone, or Provisioned SKUs that support the fine-tuned model. Chapter 16 covers promotion of fine-tuned models; this section only needs you to refuse Developer as a production SKU.
Exam scenario
Checkout chat runs on a Global Provisioned gpt-4.1 deployment pinned to version 2025-04-14 . A new default version is two weeks from becoming default. Create a second provisioned or Standard deployment on the new version, run Domain 4 evaluations, and canary a slice of traffic. Keep versionUpgradeOption off auto-default on the live PTU deployment. Enable spillover to a Standard deployment of the same version so Black Friday 429s become Standard tokens instead of failed checkouts. Do not point spillover at a different version. Do not host the canary on Developer.
Common trap
Setting Standard production to auto-update to default and calling that pinning. Pinning is a dated model.version plus OnceCurrentVersionExpired or NoAutoUpgrade . Another trap: failing over from version X to version X+1 inside a load-balancer or spillover pair. A third: expecting provisioned SKUs to auto-upgrade at retirement the way Standard SKUs do — they do not; you migrate. A fourth: using Developer for a week-long staging environment. A fifth: applying Azure Machine Learning traffic percents to Foundry Serverless deployments as if they were managed online endpoints.