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

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:

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.

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:

1. 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.
2. 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

1. Azure CLI plus the ml v2 extension.
2. A Python environment with azure-ai-ml (SDK v2) and MLflow.
3. A GitHub repository with a sample az ml job create YAML and a Bicep file for a workspace.
4. 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.