Foundry Environments and Platform Configuration

Provision the Microsoft Foundry^[1] resource before anything else: it is the top-level Azure resource, and its Azure Resource Manager type is Microsoft.CognitiveServices/accounts. Everything a team builds lives in a project, a child scope inside the resource that groups the models, agents, connections^[2], and deployments for one piece of work.

Foundry gives you two project types, and the exam rewards knowing which is the default. A Foundry project is the generally available default and the only type that exposes the Foundry API and Foundry Agent Service. A hub-based project is required only when you need Azure Machine Learning compatibility, managed compute, or open-source model hosting and fine-tuning; for everything else the Foundry project is the right choice (resource types^[1]). Choosing a hub-based project just to use prompt flow is a trap: prompt flow is on a retirement path, so it is not a reason to pick a hub for new work.

Do not confuse the Foundry container with the classic ML container. The Azure Machine Learning workspace stays the top-level resource for traditional ML assets such as datasets, jobs, and registered models; generative AI projects belong in a Foundry resource, not a workspace.

You rarely want a raw storage key pasted into every agent. A connection solves that: it is a named, project-scoped object that stores the endpoint and credentials for an external resource, so many agents and components reuse one definition instead of each carrying its own secret (add a connection^[2]). Typical targets include Azure Storage, Azure AI Search, Application Insights, Azure Key Vault, and Azure Cosmos DB.

Keyless connections

A connection can authenticate to its target with a Microsoft Entra identity (the resource's managed identity, defined under Identity and access below) instead of an API key. An Entra-based connection keeps secrets out of the connection object and lets Azure role-based access control (RBAC) decide who may use it. When a connection does hold a secret, Foundry stores it in a managed Azure Key Vault that Microsoft provisions for the resource; you can instead bring your own Key Vault, with a limit of one Key Vault connection per resource. Adding any connection requires at least the Foundry User role (or Azure Contributor), the same least-privilege role covered in the next section.

Two mechanisms govern access to a Foundry resource: the identity the resource uses to reach its own dependencies, and the RBAC roles that decide which people can act on it. This section covers both, starting with the identity.

Managed identities: keyless access

A managed identity is a special kind of service principal in Microsoft Entra ID whose credentials Azure creates and rotates automatically, so a Foundry resource can reach its dependencies (Storage, Key Vault, and more) with no stored secret (managed identities^[3]). It comes in two forms:

Identity type	Lifecycle	Sharing
System-assigned	Created and deleted with the resource (one to one)	Cannot be shared
User-assigned	Standalone Azure resource with its own lifecycle	Attach to many resources

Prefer Microsoft Entra ID token authentication over API keys for production, and you can disable local (key) authentication so every data-plane call is authorized through Entra ID and RBAC rather than a shared key. As the RBAC docs note, a key grants full access with no role restrictions, which is exactly why keys are harder to scope, rotate, and revoke than an Entra identity (RBAC for Foundry^[4]).

Least-privilege built-in roles

Assign the narrowest built-in role that lets a person work (RBAC for Foundry^[4]):

• Foundry User (formerly Azure AI User): the least-privilege role for developers building and testing in a project. It performs data actions and reads projects, but cannot create projects, deploy models, or publish agents.
• Foundry Project Manager: the elevated build role. It is the minimum role that can publish agents, and it can conditionally assign the Foundry User role to others. The canonical RBAC matrix does not grant it create-project or model-deployment rights, so do not assume it can. Some doc pages disagree on those two powers; key only its consistent powers, agent publishing plus conditional Foundry User assignment.
• Foundry Account Owner and Foundry Owner: full resource management and model deployment. Account Owner can create projects and deploy models but cannot publish agents; Foundry Owner does everything, including publishing agents.
• Foundry Agent Consumer: least privilege for a principal that only calls an agent's endpoint, with no build rights at all.

A practical mapping: give team members Foundry User at project scope, a team lead Foundry Project Manager when they must publish agents, and a manager Foundry Account Owner to provision and deploy models. Reserve Owner and Contributor for genuine administrators.

By default a Foundry resource is reachable over the public internet. Two independent controls lock it down: an outbound managed VNet and an inbound private endpoint.

Outbound: managed VNet isolation modes

A managed virtual network (VNet) has two isolation modes (configure a managed network^[5]):

• Allow internet outbound: agents may reach public endpoints.
• Allow only approved outbound: outbound traffic is limited to approved private endpoints, service tags, and fully qualified domain name (FQDN) rules.

Only Allow only approved outbound turns on automatic data-exfiltration protection; Allow internet outbound does not. When you add an outbound FQDN rule in the approved-outbound mode, Foundry automatically provisions an Azure Firewall to enforce it (Standard SKU by default, or Basic), and Azure Firewall charges then appear on your bill. Note the documented caveat: once you add outbound rules, Microsoft cannot guarantee protection against exfiltration to those specific destinations.

Inbound: private endpoint plus disabling public access

For inbound isolation, create a private endpoint (Azure Private Link) so the resource gets a private IP inside your VNet, then set public network access to Disabled (configure network isolation^[6]). A private endpoint alone is not enough: while public network access stays enabled, the public path is still reachable. Do not confuse a private endpoint with a service endpoint: a service endpoint keeps the resource's public IP and only extends your subnet's identity to it, whereas a private endpoint projects the resource into your subnet as a private IP (private endpoint overview^[7]). Private endpoints to connected resources such as Storage, Search, and Cosmos DB are not auto-created; add them separately.

Portal click-ops is not repeatable, and a Foundry configuration built by hand cannot be reviewed or promoted across environments. Define the resource, its projects, and model deployments as Bicep templates instead, and deploy them with the Azure CLI (deploy a Foundry resource by using Bicep^[8]). A Bicep template for a Foundry environment declares the Microsoft.CognitiveServices/accounts resource and its Microsoft.CognitiveServices/accounts/projects children, so one coordinated deployment recreates identical dev, test, and prod environments.

Deploy a Foundry resource and project with the Azure CLI

# Create the resource group, then deploy the Bicep template into it
az group create --name exampleRG --location eastus
az deployment group create \
  --resource-group exampleRG \
  --template-file main.bicep \
  --parameters aiFoundryName=myai aiProjectName=myai-proj
# ...

az group create provisions the resource group; az deployment group create applies main.bicep into it, passing the resource and project names as parameters. A successful run reports "provisioningState": "Succeeded".

Two facts worth remembering. First, a managed-network Foundry resource has no portal creation experience, so it must be deployed with Bicep or Terraform, or through az rest and the Azure CLI. Second, if you already built a resource in the portal, you can export its configuration to a Bicep file (Automation > Export template) as a starting point rather than authoring one from scratch.

Most questions on this objective test one of a handful of distinctions. Read the stem for the signal, then pick the answer that matches.

• Container: 'build agents' or 'generative AI' points to a Foundry resource and project, not an Azure Machine Learning workspace. The workspace is only for classic ML assets.
• Project type: a Foundry project is the default; reach for a hub-based project only for Azure ML compatibility, managed compute, or open-source model hosting and fine-tuning. 'To use prompt flow' is not a valid reason.
• Credentials: prefer a shared connection using Microsoft Entra (managed identity) authentication over an API key hard-coded into each agent. Keys grant unscoped access and are harder to rotate and revoke.
• Roles: Foundry User is least privilege for build-and-test; Foundry Project Manager is the minimum role that can publish agents but cannot create projects or deploy models; Foundry Account Owner deploys models but cannot publish agents. Do not answer Owner or Contributor when a Foundry role fits.
• Outbound network: 'prevent data exfiltration' means Allow only approved outbound, never Allow internet outbound. Adding an FQDN rule provisions an Azure Firewall.
• Inbound network: a private endpoint plus public network access set to Disabled. A private endpoint alone, or a service endpoint, leaves the public path open.
• Deployment: 'repeatable across dev, test, and prod' means Bicep with az deployment group create, not portal click-ops; a managed-network resource has no portal creation UI.