This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
Choose the best response for each question.
Why is Microsoft Entra ID keyless authentication preferred over API keys when an app connects to Azure OpenAI in Microsoft Foundry?
It avoids storing and transmitting shared API keys and lets you enforce least-privilege RBAC for each user, app, or managed identity.
It makes every authenticated identity an administrator for the Foundry project.
It lets developers bypass Microsoft Entra ID and role assignments by using a hidden service key.
What does a managed identity provide for an Azure-hosted workload that accesses Azure OpenAI?
A Microsoft Entra-managed identity for the Azure resource, so the workload can get tokens without storing app secrets.
A separate authentication system that replaces Microsoft Entra ID for Azure OpenAI.
A user name and password that developers rotate manually for the Azure resource.
Which RBAC approach is appropriate for current Microsoft Foundry project access that uses Microsoft Entra authentication?
Assign an appropriate Foundry role, such as Foundry User, at the Foundry resource or project scope to the user or managed identity, and make sure the person assigning it has Microsoft.Authorization/roleAssignments/write at that scope.
Assign Reader to the app identity. Reader can call the Foundry data plane and assign any missing roles.
Assign Cognitive Services OpenAI User for every current Foundry project because Cognitive Services roles are the current Foundry project roles.
You must answer all questions before checking your work.
Was this page helpful?
Need help with this topic?
Want to try using Ask Learn to clarify or guide you through this topic?