1.3 Candidate Profile, Azure ML v2, Foundry, and DevOps Tooling

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

1.3 Candidate Profile, Azure ML v2, Foundry, and DevOps Tooling

Key Takeaways Explain This Topic AI

No prior exam is required; Microsoft recommends hands-on Azure Machine Learning and Microsoft Foundry experience, Python, and entry-level DevOps including GitHub Actions and CLIs.

Treat Azure Machine Learning Python SDK v2 ( azure-ai-ml ) and Azure CLI ml extension v2 ( az ml <noun> <verb> with YAML) as current; CLI v1 support ended 30 September 2025 and SDK v1 support ends 30 June 2026.

The generative platform in the skills outline is Microsoft Foundry, formerly branded Azure AI Studio and Azure AI Foundry; hub-based projects remain in the classic experience while new investments target Foundry projects.

Hub workspaces in Azure Machine Learning are the same resource type as Microsoft Foundry hubs and can be used from both Azure Machine Learning studio and Foundry.

Named automation tools on the outline are GitHub Actions, Bicep, Azure CLI, and MLflow for experiment tracking and model registration—not an open-ended list of every CI or IaC product.

Last updated: August 2026

Candidate Profile, Azure ML v2, Foundry, and DevOps Tooling

Quick Answer: AI-300 candidates are MLOps engineers with a data science and Python background, hands-on Azure Machine Learning SDK/CLI v2 , hands-on Microsoft Foundry , and entry-level DevOps ( GitHub Actions , Bicep , Azure CLI ). Experiment tracking and model packaging use MLflow . Do not answer with SDK v1 ( azureml.core ) as the current interface. Do not call the generative platform Azure AI Studio as the current brand—it is Microsoft Foundry .

Who should sit AI-300

Microsoft is certifying a person who can operationalize AI, not a person who can only fit a scikit-learn model on a laptop. The published profile expects:

Subject-matter expertise in MLOps and GenAIOps infrastructure on Azure (together, AIOps )
Experience training, optimizing, deploying, and maintaining traditional models in Azure Machine Learning

Experience deploying, evaluating, monitoring, and optimizing generative applications and agents in Microsoft Foundry

Python fluency sufficient to read training scripts, evaluation code, and job YAML
Entry-level DevOps: Git, GitHub Actions, and CLIs
IaC with Bicep and Azure CLI

There is no required prior exam . AZ-900 or AI-900 can help vocabulary; they are not gates. Azure Data Scientist Associate (DP-100) overlaps experimentation but does not replace endpoint operations, Foundry GenAIOps, or IaC. GitHub certifications are also not prerequisites.

You work with data scientists (who own training logic and metrics), DevOps teams (who own identity, networks, and pipelines), and stakeholders (who own risk, cost, and rollout). Exam items are often written from that handoff: who is allowed to deploy, which identity an endpoint assumes, whether a Bicep module should create a compute cluster, whether a prompt change needs a Git tag before production traffic moves.

If your only interface is the studio click-path, you will miss CLI/YAML and GitHub Actions items. If your only interface is Python in a notebook, you will miss RBAC, private networking, and provisioned throughput items. The candidate Microsoft describes can move among those interfaces without dropping the operational thread.

Azure Machine Learning SDK and CLI v2

Azure Machine Learning is the workspace-centered platform for classic MLOps on this exam. A workspace is the top-level resource: jobs, data assets, models, components, endpoints, plus attached compute, datastores, and security settings. Teams use it to collaborate; administrators use it for access management, cost management, and data isolation. A common pattern is one workspace per project, with Microsoft Entra ID groups assigned roles, associated Azure resources shared where it is safe, and registries used when assets must cross workspaces.

Creating a workspace also brings associated Azure resources. If you do not supply them, Azure Machine Learning creates them:

Associated resource Role in the workspace
Azure Storage account Job logs, default uploads, compute-instance notebooks
Azure Key Vault Secrets that compute and the workspace need
Azure Application Insights Diagnostics for inference endpoints
Azure Container Registry Custom environment images when you build them

For AI-300, the current client is v2 . Microsoft documents no functionality gap between CLI v2 and SDK v2: the command line is convenient in CI/CD; the SDK is convenient in development.

Interface Current artifact Typical use on this exam
Python SDK v2 azure-ai-ml package Author jobs, sweeps, pipelines, and managed endpoints in code
CLI v2 Azure CLI ml extension: az ml <noun> <verb> GitHub Actions steps and YAML-driven create/update
Studio Azure Machine Learning studio Exploration, debugging, operations you can also express in YAML
VS Code Azure Machine Learning extension Local-to-cloud authoring

CLI v2 commands follow az ml <noun> <verb> <options> . The asset or workflow itself is defined in YAML —what it is and where it should run—while your training or scoring logic stays in script files the YAML references. Recognize commands such as:

az ml job create --file my_job_definition.yaml
az ml environment update --name my-env --file my_updated_env_definition.yaml
az ml model list
az ml compute show --name my_compute

Managed online and batch endpoints and reusable pipeline components are v2 capabilities. Answering an endpoint item with a v1 Azure Container Instances or Azure Kubernetes Service deploy pattern is a v1 tell. If an item shows a YAML job and an az ml verb, stay on the v2 side of the fence.

Why v1 is a trap on this exam

Microsoft’s v2 documentation is explicit about support dates: CLI v1 support ended 30 September 2025 . SDK v1 support ends 30 June 2026 . Existing v1 workflows may still run after those dates but can pick up security risk or breaking changes. This exam’s skills measured assume the v2 nouns: jobs, command jobs, components, managed endpoints, registries.

Do not study azureml.core.Workspace , Experiment.submit , or the retired v1 CLI extension as the current way. You will still find v1 snippets in old posts and internal wikis. On AI-300, treat them as distractors unless an item is clearly describing a migration problem—and the outline is not a migration exam.

Hub workspaces in Azure Machine Learning group multiple project workspaces with shared security settings, connections, and compute. Microsoft’s workspace documentation (February 2026) states that hub workspaces are the same resource type as Microsoft Foundry hubs , so you can use them from Azure Machine Learning studio and from Foundry. That overlap matters when an item asks how to centralize governance across classic ML and generative projects without inventing a third control plane.

Microsoft Foundry

Microsoft Foundry is the generative stack on AI-300. It unifies agents, models, and tools under a single management grouping with tracing, monitoring, evaluations, unified role-based access control (RBAC) , networking, and Azure Policy under one Azure resource provider namespace.

Brand evolution—learn it once, then use the current name. The product was previously Azure AI Studio and then Azure AI Foundry . The current brand is Microsoft Foundry . Azure AI Services maps to Foundry Tools . Hub-based projects remain available in the Foundry (classic) portal; Microsoft’s current docs say new investments focus on Foundry projects in the new portal. This guide teaches the March 2026 skills list (Foundry resources and projects, identity, networking, Bicep/CLI, foundation-model deploy, prompts) and notes the 2026 platform evolution without inventing exam coverage of every new agent API name that is not on the outline.

What you must be ready to operationalize on the Foundry side:

Create and configure Foundry resources and project environments
Managed identities and RBAC (prefer a managed identity over copying keys into GitHub Actions)
Network security and private networking
Deploy infrastructure with Bicep templates and Azure CLI
Foundation models on serverless API endpoints and managed compute
Model selection, versioning, and production deployment strategies
Provisioned throughput units for high-volume workloads
Prompt design, variants, comparison, and Git versioning

Later chapters add quality metrics (groundedness, relevance, coherence, fluency), risk and safety evaluations, continuous monitoring, token cost, and tracing. Foundry is not “chat in a playground.” If an item describes production traffic, think identity, network, version, evaluation gate, and rollback—the same instincts as Azure Machine Learning endpoints, with generative-specific metrics.

Coming from Azure OpenAI is a common real-world path: Microsoft documents upgrading an Azure OpenAI resource to a Foundry resource while preserving endpoint, keys, and state. Know that the skills measured name Foundry , not a standalone Azure OpenAI-only control plane, as the GenAIOps platform.

DevOps tooling the outline names

The skills measured do not say “any CI system.” They name a short list. Stay inside it unless an item gives you extra facts.

Git and GitHub Actions

Use Git as the source of truth for job YAML, Bicep, scoring scripts, prompt files, and evaluation datasets you are willing to version. Domain 1 includes configuring GitHub integration with Azure Machine Learning to enable secure access and managing source control for machine learning projects with Git. Domain 3 repeats the Git idea for prompts. GitHub Actions automates resource provisioning and, in later chapters, training and deployment workflows. An Actions workflow that uses a user-assigned managed identity or OpenID Connect federation to Microsoft Entra ID is in-character for this exam. A workflow that pastes a workspace access key into a repository secret and SSHs to a compute instance is not.

Bicep and Azure CLI

Bicep is the declarative IaC language Microsoft lists for both Azure Machine Learning workspaces and Foundry infrastructure. Azure CLI is the imperative companion ( az plus the az ml v2 extension). Exam items often ask which file to change to add a private endpoint, a compute cluster SKU, or a Foundry project—not how to click through the portal the first time. If you can read a Bicep module well enough to spot a missing identity or a public network default, you are studying in the right layer.

MLflow

MLflow is how Azure Machine Learning tracks experiments (parameters, metrics, artifacts) and how models are commonly registered for deployment. You will compare jobs, package an MLflow model, and in some cases attach a feature retrieval specification to the artifact. Treat MLflow as the contract between data science runs and MLOps promotion, not as an optional dashboard you can ignore if studio metrics look fine.

Tooling map you should keep in your head
Author training logic — Python scripts plus MLflow logging
Define the job — SDK v2 or az ml job create YAML
Define the platform — Bicep and Azure CLI
Promote on a merge — GitHub Actions
Serve traditional models — Azure Machine Learning managed online or batch endpoints
Serve foundation models — Foundry serverless endpoints, managed compute, or PTUs
Prove quality — evaluators, drift monitors, traces, token metrics

That map is the rest of this guide in one list. Chapters 2–9 stay mostly on the Azure Machine Learning side. Chapters 10–16 stay mostly on the Foundry side. The same engineer is expected to own both.

Realistic scenario

Sam can train a ranking model in a notebook and chat with a foundation model in a playground. Production asks for a repeatable workspace, a GitHub Actions workflow that deploys Bicep, an MLflow-registered model on a managed online endpoint with a canary rollout, and a Foundry prompt file that is Git-tagged and evaluated for groundedness before traffic shifts. Studio clicks got Sam through a demo. AI-300 items are written like Sam’s production week, including the identity that the workflow assumes and the YAML that defines the job.

Common trap

Two naming traps fail otherwise strong engineers:

SDK v1 muscle memory — Workspace.from_config() , Model.deploy to ACI or AKS, v1 pipelines—when the item is clearly a v2 job YAML or a managed endpoint.

Stale generative branding — answering “Azure AI Studio” or treating Foundry as a rename with no operational surface. The current name is Microsoft Foundry; hub-based (classic) projects still exist; new investment is on Foundry projects. Use the name the skills measured use.

A third trap is tooling sprawl: inventing Terraform, Jenkins, or Kubeflow as the answer when the outline named Bicep , Azure CLI , and GitHub Actions . Those products exist in real shops. They are not what this exam lists. A fourth trap is building only one stack—an Azure Machine Learning workspace with no Foundry project, or a Foundry playground with no v2 job YAML—and hoping the other half of the blueprint does not appear.

What to install before Chapter 2

Azure CLI plus the ml v2 extension.

A Python environment with azure-ai-ml (SDK v2) and MLflow.

A GitHub repository with a sample az ml job create YAML and a Bicep file for a workspace.

Access to an Azure subscription where you can create an Azure Machine Learning workspace and a Microsoft Foundry project—not only one of them.

You do not need every SKU. You need both stacks, v2 clients, and a Git-based promotion story. The remaining chapters assume that baseline.