Design and implement a GenAIOps infrastructure
Microsoft Foundry Environments and Platform Security
CoreCreate Foundry resources and projects with Bicep and Azure CLI, grant access with managed identities and the Foundry RBAC roles, and isolate the platform with private endpoints and Agent Service network injection.
Aligned to the live AI-300 guide, which publishes no skills-measured date; guide and product behavior verified October 10, 2026.
Why this matters
The Foundry resource is where governance, networking, and model deployments live, and projects are where teams build. Getting the hierarchy, identities, and network boundary right first prevents key sprawl, accidental public exposure, and rework when agents need to reach private data.
Must Know
- A Foundry resource is the Azure resource type Microsoft.CognitiveServices/accounts with kind AIServices. It holds governance settings such as networking, security, and model deployments.
- A Foundry project is the subresource Microsoft.CognitiveServices/accounts/projects, a development boundary where a team builds and evaluates its use cases.
- Hub-based projects open only in the Foundry (classic) portal; new investment is focused on Foundry projects in the current portal.
- Foundry User is the least-privilege role for developers building and testing agents. Foundry Account Owner manages the resource but cannot build in projects without also holding Foundry User, and Foundry Project Manager can conditionally assign Foundry User to others. These roles were previously named Azure AI User, Azure AI Account Owner, and Azure AI Project Manager.
- Prefer Microsoft Entra ID with managed identities over API keys, because a key grants full access without role restrictions.
- A project managed identity needs the Foundry User role on the Foundry resource. When someone who can assign roles creates the project in the Foundry portal, the portal assigns it automatically, but projects created through the SDK, CLI, or templates need it assigned explicitly.
- Set public network access to Disabled and add a private endpoint for private inbound access. Removing private endpoints later does not make the resource public again.
- Foundry Agent Service network injection places agents in your virtual network through a subnet delegated to Microsoft.App/environments, sized /27 or larger. It must be configured at creation; adding it later requires redeploying Foundry.
Compare and Distinguish
- Foundry resource versus project: governance, networking, and deployments versus a team’s development boundary.
- Foundry project versus hub-based project: current portal and resource model versus classic portal only.
- Foundry User versus Foundry Account Owner: build in projects versus manage the resource without building rights.
- Managed identity with RBAC versus API key: scoped, auditable access versus an all-powerful shared secret.
Scenario examples
- Scenario: Two product teams need separate workspaces for agents but shared governance and model deployments. Think: one Foundry resource with a project per team.
- Scenario: An app hosted in Azure Container Apps must call a Foundry project without any stored keys. Think: a managed identity on the app with the Foundry User role.
- Scenario: Agents must call internal APIs and a private Azure AI Search index. Think: Agent Service network injection with a delegated subnet, planned before the resource is created.
Exam traps
- Built-in roles whose names begin with Cognitive Services are not the recommended way to grant Foundry project access; Cognitive Services Usages Reader for quota visibility is the documented exception.
- Foundry Account Owner alone does not let someone build agents in a project.
- A template deployment does not automatically grant the project managed identity its role.
- Agent Service network injection cannot be switched on for an existing Foundry resource.
Key takeaways
- Use one Foundry resource for governance and separate projects for team isolation.
- Grant Foundry User to people and managed identities, and avoid keys.
- Plan private endpoints and agent network injection before the first deployment.
How it works
- Requests to a project are authorized against Azure RBAC on the Foundry resource unless key authentication is used.
- Private endpoints map the resource to private IP addresses through privatelink DNS zones in your network.
Objects and administrative surfaces
- Microsoft Foundry portal for projects, connections, and deployments.
- Bicep templates that declare accounts and accounts/projects, deployed with az deployment group create.
- Azure portal access control (IAM) and Networking settings on the Foundry resource.
When to use it
- Use separate projects when teams need isolated assets, and separate Foundry resources when they need different network or governance settings.
- Use Selected networks when a few trusted public ranges must still reach the resource.
Security and governance implications
- Disable key-based access where every caller can use Microsoft Entra ID.
- Assign roles to groups and managed identities at the narrowest workable scope.
Troubleshooting signals
- An agent that fails to reach a connected resource after a CLI deployment often lacks the role assignment the portal would have created.
- A client that times out after public access is disabled usually lacks private DNS resolution to the private endpoint.
More detail
- Create Foundry resources and projects and recognize hub-based projects.
- Configure managed identities and Foundry RBAC roles.
- Implement private endpoints, public network access settings, and agent network injection.
- Deploy Foundry infrastructure with Bicep templates and Azure CLI.
Ready for the quiz?
- What is the resource type and kind of a Foundry resource?
- Which role is the least-privilege choice for a developer building agents?
- What must you do for a project managed identity when deploying with Bicep?
- Why must agent network injection be planned at creation time?
Related objectives
- D3.1.S1 — Create and configure Foundry resources and project environments
- D3.1.S2 — Configure identity and access management with managed identities and role-based access control (RBAC)
- D3.1.S3 — Implement network security and private networking configurations
- D3.1.S4 — Deploy infrastructure using Bicep templates and Azure CLI