Study guide
10.2 Managed Identities and RBAC for Foundry
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
10.2 Managed Identities and RBAC for Foundry
Key Takeaways Explain This Topic AI
Use Microsoft Entra ID for production. API keys are all-or-nothing per resource, have no per-user audit, and cannot call Foundry Agent Service or evaluations. Token audience is https://ai.azure.com/.default . A custom subdomain is required for token auth.
Control plane (Azure RBAC actions: create accounts/projects, deploy models, Private Link, rotate keys) is separate from data plane (RBAC dataActions: chat, agents, evaluations, fine-tune jobs). Azure Owner and Contributor do not grant Foundry dataActions.
Built-in Foundry roles were renamed in 2026: Foundry User (formerly Azure AI User, ID 53ca6127-db72-4b80-b1b0-d745d6d5456d), Foundry Owner, Foundry Account Owner, Foundry Project Manager, plus Foundry Agent Consumer. Role IDs did not change. Prefer GUIDs in automation during the rename.
Do not use Azure AI Developer for Foundry projects (it is for Azure Machine Learning workspaces and hubs). Do not use Cognitive Services * roles, including Cognitive Services OpenAI User, as the Foundry project data-plane role — assign Foundry User instead.
Assign Foundry User on the Foundry resource to both the human developer and the project's managed identity. Use a user-assigned managed identity when several Azure resources must share one identity. Set disableLocalAuth to true after callers are keyless.
Last updated: August 2026
Managed Identities and RBAC for Foundry
Quick Answer: Production uses Microsoft Entra ID , not API keys. Control plane = Azure RBAC actions (create the account, deploy models, Private Link). Data plane = dataActions (chat, agents, evaluations). Assign Foundry User (formerly Azure AI User , role ID 53ca6127-db72-4b80-b1b0-d745d6d5456d ) to developers and the project managed identity . Owner / Contributor cannot call the playground. Agents and evaluations require Entra ID.
Domain 3's second platform bullet is configure identity and access management with managed identities and RBAC . The same Entra tenant you used for Azure Machine Learning in Chapter 2 now issues tokens for Foundry. The role names on the exam may still say Azure AI User because Microsoft renamed the Foundry roles in 2026; the IDs did not change.
Control plane versus data plane
Azure always splits resource management from using the resource . Foundry makes that split explicit.
Plane Scope Typical operations Tools Authorization
Control plane Account, projects, networking, encryption, connections, model deployments Create/delete resources, assign roles, rotate keys, Private Link Azure portal, Azure CLI, Bicep, Terraform Azure RBAC actions
Data plane Inference, agents, evaluations, content safety, fine-tune jobs Chat completions, embeddings, start evals, send agent messages SDKs, REST, Foundry playground Azure RBAC dataActions
Control-plane examples: Foundry resource creation, project creation, account/project capability hosts, model deployment, connection creation. Data-plane examples: building agents, running an evaluation, tracing, fine-tuning.
Trap: granting a developer Contributor on the resource group and expecting the playground to work. Contributor can create the account and deploy models. It does not include Foundry dataActions . The playground returns 403 . Pair Contributor (or Foundry Account Owner) with Foundry User , or use Foundry Owner when one person truly needs both planes.
Authentication methods
Foundry supports two ways to prove identity:
Microsoft Entra ID — OAuth 2.0 bearer tokens for audience https://ai.azure.com/.default . Enables conditional access, MFA, managed identities, per-principal audit, and least-privilege RBAC. Required for Agent Service, evaluations, Toolbox, and managed-identity tool access. Recommended for production.
API keys — static secrets on the Foundry resource. Language-agnostic and fine for a laptop prototype. All-or-nothing on the resource: a key cannot express "this user may chat but not fine-tune." Keys do not work for agents or evaluations. Rotate them; never commit them.
Token auth needs a custom subdomain on the account. A regional *.cognitiveservices.azure.com endpoint without the subdomain fails with an error that a custom subdomain is required.
Identity types you assign roles to:
User principal — a human in Entra ID.
Service principal — an app registration with a certificate (prefer) or client secret.
System-assigned managed identity — bound to one Azure resource, deleted with the resource. Each Foundry project should have one for runtime calls.
User-assigned managed identity — a standalone identity you attach to multiple resources (Foundry, App Service, GitHub OIDC). Use it for cross-resource access so you are not copying system-assigned IDs into every Bicep module.
In Python, DefaultAzureCredential() then credential.get_token("https://ai.azure.com/.default") is the production pattern. api-key headers are the prototype pattern.
After every caller is keyless, set disableLocalAuth: true (Bicep property, or Set-AzCognitiveServicesAccount -DisableLocalAuth $true ). Azure Policy Foundry Tools resources should have key access disabled can enforce that. Keys then stop working on purpose.
Built-in Foundry roles (current names and old names)
Microsoft renamed the Foundry RBAC roles. Foundry User , Foundry Owner , Foundry Account Owner , and Foundry Project Manager were previously Azure AI User , Azure AI Owner , Azure AI Account Owner , and Azure AI Project Manager . During rollout you may see either string. Use the role definition GUID in CLI and Bicep.
Role Role ID Create accounts Create projects Data plane (build) Assign roles Manage models Call agent endpoints
- Foundry Agent Consumer eed3b665-ab3a-47b6-8f48-c9382fb1dad6 No No No No No Yes
- Foundry User (Azure AI User) 53ca6127-db72-4b80-b1b0-d745d6d5456d No No Yes No No Yes
- Foundry Project Manager eadc314b-1a2d-4efa-be10-5d325db5065e No No Yes Foundry User only No Yes
- Foundry Account Owner e47c6f54-e4a2-4754-9501-8e0985b135e1 Yes Yes No Foundry User, ACR, monitoring Yes No
- Foundry Owner c883944f-8b7b-4483-af10-35834be79c4a Yes Yes Yes Foundry User, ACR, monitoring Yes Yes
Azure Owner can create accounts and assign any role but still has no Foundry dataActions. Azure Reader can see the account and cannot build. Foundry Account Owner is the platform-admin shape: manage the resource and deployments, then conditionally assign Foundry User when someone needs to build. Fine-tuning a model needs both planes: Foundry Owner alone, or Foundry User plus Foundry Account Owner .
Minimum onboarding Microsoft documents:
Foundry User on the Foundry resource to the user principal .
Foundry User on the Foundry resource to the project's managed identity .
If the creator is Azure Owner and they create the project in the Foundry portal UI , both assignments are added automatically. SDK/CLI creates do not auto-assign Foundry User — you must az role assignment create .
- Assign with the GUID: az role assignment create \
- -assignee <principal-id> \
- -role "53ca6127-db72-4b80-b1b0-d745d6d5456d" \
- -scope /subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.CognitiveServices/accounts/<account>
You can also scope Foundry User to a project ARM ID, or scope Foundry Agent Consumer to a single agent:
/subscriptions/.../accounts/<account>/projects/<project>/agents/<agentName>
Agent-scope assignments are evaluated only for that agent's endpoints. They do not grant control-plane rights.
Roles you should not pick for Foundry projects
Microsoft's RBAC article is blunt:
Do not assign built-in roles that start with Cognitive Services for Foundry scenarios. Those roles target AI Services resources used directly , not Foundry projects. Cognitive Services OpenAI User is the classic Azure OpenAI data-plane role ( Microsoft.CognitiveServices/accounts/OpenAI/*/read style dataActions). On a standalone Azure OpenAI account it still lets you call deployments. On a Foundry project , the role you want is Foundry User .
Do not use Azure AI Developer for Foundry projects. Despite the name, it is scoped to Azure Machine Learning workspaces and Foundry hubs (including workspaces/hubs/join/action ). For Foundry project access, use Foundry User or Foundry Owner .
If a stem still says "Azure AI User on the project," map it to Foundry User . If it says "Azure AI Developer so scientists can join the hub," that is the classic hub join role, not the new project data-plane role.
Managed identities for runtime and connections
The project managed identity is what Agent Service and evaluation jobs present when they call models, Search, Storage, or Cosmos DB. If that identity lacks Foundry User on the account, tool calls 403 even though your user principal can open the portal.
When the agent reads Blob Storage or Search:
Grant the project identity (or a user-assigned identity attached to the project) Storage Blob Data Reader (or Contributor if it must write) on the storage account.
Grant a Search data-plane role such as Search Index Data Reader on the Search service.
Create the Foundry connection with authType: AAD , not a stored admin key.
System-assigned identity is simplest for one project. Choose user-assigned when App Service, a GitHub Actions OIDC federated credential, and the Foundry project must share one principal so you rotate one identity, not three.
Enterprise mapping Microsoft publishes:
IT admin: Azure Owner on the subscription.
Platform manager: Foundry Account Owner on the resource.
Team lead: Foundry Project Manager on the resource (creates projects, publishes agents, can assign Foundry User).
Developer: Foundry User on the project plus Reader on the account.
Calling application: Foundry Agent Consumer on the project or agent.
You need Owner or User Access Administrator at the assignment scope to grant these roles. Custom roles can narrow dataActions to Microsoft.CognitiveServices/accounts/AIServices/agents/* when Foundry User is still too broad.
Exam scenario
A squad lead can deploy gpt-4o from the Azure portal (Contributor on the resource group) but every playground chat and agent run returns 403. API keys were disabled by policy ( disableLocalAuth: true ).
Assign Foundry User to the squad lead and to the project managed identity at the Foundry resource (or project) scope. Keep Contributor for control-plane deploys, or replace it with Foundry Account Owner if they should not have subscription-wide rights. Do not re-enable API keys to "unblock" production, and do not add Cognitive Services OpenAI User as the fix for a Foundry project.
Common trap
Treating Azure AI Developer or Cognitive Services OpenAI User as the Foundry developer role. The first joins hubs ; the second is a classic OpenAI data-plane role. Another trap is assigning Foundry User only to people and forgetting the project managed identity , so the portal works and Agent Service cannot reach Search. A third is using API keys for agents — the feature matrix is No for keys on Agent Service and evaluations.