3.2.1. Identity and Access: Managed Identity and Least-Privilege RBAC
💡 First Principle: Authentication answers "who are you?" (prefer managed identity — an Azure-managed credential with no secret to leak), and authorization answers "what may you do?" (assign the narrowest RBAC role that covers the need). The two are separate decisions, and the exam tests both.
Managed identity gives a workload an Entra identity Azure rotates automatically — your code authenticates without any stored secret, which is why DefaultAzureCredential (from Phase 2) is the production-correct pattern. On authorization, least privilege is the rule: a runtime app that only makes inference calls should get a scoped role like Cognitive Services OpenAI User, not Contributor or Owner. Over-privileged runtime identities are a classic wrong answer. For agents specifically, Microsoft Entra Agent ID provides scoped, short-lived tokens for agent function access. Mind the scope distinction: direct model inference (calling a deployment) uses Cognitive Services OpenAI User, while Foundry project data-plane work — building agents, running evaluations, uploading files — uses the Foundry-native Foundry User role, and Microsoft advises against the Cognitive Services * roles for Foundry project access.
⚠️ Exam Trap: Assigning Contributor or Owner to a runtime/service identity "so it just works" is the trap. The right answer grants the specific data-plane role the task needs (e.g., the OpenAI User role for inference) and nothing more. Broad roles on runtime identities fail least-privilege and show up as the deliberately-too-permissive distractor.
Reflection Question: A web app needs only to send chat-completion requests. Why is Cognitive Services OpenAI User the right role and Contributor wrong, even though both would make the app function?
