AI-300 Exam Guide 2026: Operationalizing ML and Generative AI
AI-300 is the exam for the job that starts after the model works: pipelines, registries, endpoints, drift, evaluation, tracing and cost. Azure ML on one side, Microsoft Foundry on the other.
On this page
AI-300 — Operationalizing Machine Learning and Generative AI Solutions — certifies the work that begins once a model works on someone's laptop: getting it into production, keeping it there, and knowing when it degrades.
Microsoft groups MLOps and GenAIOps together as AI operations (AIOps), and the exam is split almost evenly between them. Built against the official study guide published 5 March 2026.
What AI-300 certifies
The audience profile is demanding. You need a data science background with Python, an entry-level grasp of DevOps including GitHub Actions and CLIs, and hands-on experience with Azure Machine Learning, Microsoft Foundry, GitHub Actions, and infrastructure as code using Bicep and Azure CLI.
Responsibilities named: designing and implementing MLOps infrastructure, model lifecycle and operations, GenAIOps infrastructure, generative AI quality assurance and observability, and optimising generative AI systems and model performance.
This sits at the intersection of data science and platform engineering. If you are a data scientist who has never written a pipeline, or a DevOps engineer who has never evaluated a model for groundedness, expect to do real work on your weaker half. The exam refuses to let you specialise.
Five domains and their weights
Roughly 45 percent classic MLOps, roughly 45 percent generative AI operations, and the model lifecycle domain alone is the biggest single block.
The MLOps half
MLOps infrastructure (15–20%)
Azure ML workspace resources — workspaces, datastores, compute targets, and identity and access management. Workspace assets — data assets, environments, components, and sharing across workspaces using registries. Then infrastructure as code: GitHub integration for secure access, deploying workspaces with Bicep and Azure CLI, automating provisioning with GitHub Actions, restricting network access, and source control with Git.
Model lifecycle and operations (25–30%)
The heaviest domain, in four parts:
- Orchestrate training — experiment tracking with MLflow, automated machine learning, notebooks, automated hyperparameter tuning, training scripts, distributed training for large and deep models, training pipelines, and comparing performance across jobs.
- Registration and versioning — packaging a feature retrieval specification with the model artifact, registering an MLflow model, evaluating against responsible AI principles, and managing lifecycle including archiving.
- Deployment — real-time or batch endpoints with managed inference, testing and troubleshooting endpoints, and progressive rollout with safe rollback.
- Monitoring — detecting and analysing data drift, monitoring production performance metrics, and configuring retraining or alert triggers when thresholds are exceeded.
Notice how often versioning appears — models, prompts, environments, components, endpoints. If a question describes a change reaching production without a way back, the answer usually involves versioning plus progressive rollout and rollback.
The GenAIOps half
GenAIOps infrastructure (20–25%)
Foundry environments and platform configuration — creating Foundry resources and project environments, identity and access with managed identities and RBAC, network security and private networking, and deployment via Bicep templates and Azure CLI.
Model deployment for production — serverless API endpoints versus managed compute, selecting models for use cases, versioning and production deployment strategies, and configuring provisioned throughput units for high-volume workloads.
Then prompt management: designing and developing prompts, creating prompt variants and comparing their performance, and version control for prompts using Git. Prompts are treated as versioned source artifacts — a small idea that carries real exam weight.
Quality assurance and observability (10–15%)
Evaluation — test datasets and data mapping, AI quality metrics (groundedness, relevance, coherence, fluency), risk and safety evaluations for harmful content, and automated evaluation workflows with built-in and custom metrics.
Observability — continuous monitoring in Foundry, performance metrics (latency, throughput, response times), cost metrics including token consumption, and detailed logging, tracing and debugging for production troubleshooting.
Groundedness, relevance, coherence and fluency are named explicitly and are easy to blur together. Groundedness asks whether the answer is supported by the source; relevance whether it addresses the question; coherence whether it hangs together logically; fluency whether the language itself is well formed. Expect to be asked which metric catches which failure.
RAG optimisation and fine-tuning
The final domain (10–15%), and the most technically specific.
Chunk size and similarity threshold are the two knobs most likely to appear in a scenario. Be able to say what happens when each is set too high or too low, and why hybrid search rescues cases pure semantic retrieval misses.
The two mindsets AI-300 forces together
This exam is harder than its weightings suggest because its two halves come from different engineering cultures, and it tests both to the same standard.
| MLOps half | GenAIOps half | |
|---|---|---|
| The artifact | A model you trained | A prompt, a model you call, and an agent |
| Quality means | Accuracy metrics against a test set | Groundedness, relevance, coherence, fluency, plus safety |
| Failure looks like | Data drift degrading predictions | Hallucination, unsafe output, latency, token cost |
| Versioning covers | Models, environments, components | Prompts, model deployments, evaluation sets |
| The tooling | Azure ML, MLflow, AutoML | Microsoft Foundry, evaluations, tracing |
| You watch | Drift and retraining triggers | Latency, throughput, token consumption |
Two habits close the gap. First, on any monitoring question ask which half am I in? — drift belongs to MLOps, groundedness to GenAIOps, and options that mix them are usually distractors. Second, note that cost is an explicit objective only on the generative side, where token consumption is a first-class metric rather than an afterthought.
Candidates study the half they already live in and skim the other. At roughly 45 percent each, skimming either one caps your score below a pass no matter how strong the other is. Audit yourself honestly in week one and spend your time on the weaker half.
A six-week study plan
Coming from a data science background? Our DP-100 guide covers the modelling side that AI-300 assumes you already have. The study-time calculator will size the plan to your hours.
Frequently Asked Questions
What is AI-300?
AI-300 is Operationalizing Machine Learning and Generative AI Solutions. It certifies setting up infrastructure for MLOps and GenAIOps on Azure, together referred to as AI operations or AIOps.
What background does AI-300 assume?
A data science background with Python programming, an entry-level understanding of DevOps including GitHub Actions and CLIs, plus experience with Azure Machine Learning, Microsoft Foundry, and infrastructure as code using Bicep and Azure CLI.
How many domains does AI-300 have?
Five: MLOps infrastructure (15-20%), model lifecycle and operations (25-30%), GenAIOps infrastructure (20-25%), generative AI quality assurance and observability (10-15%), and optimizing generative AI systems (10-15%).
Is AI-300 the same as DP-100?
No. DP-100 centres on designing and running data science solutions. AI-300 is about operationalising them, and roughly half of it covers generative AI operations that DP-100 does not address at all.
Practise AI-300 Before You Book
500–1,000+ AI-300 practice questions with worked explanations across all five domains.
AI-300 Practice Test
Practice Before You Book
500–1,000+ practice questions per exam with detailed explanations, across Azure, AWS, GCP, security, and AI certifications.