AI-300 Practice Question 7: Keyless Authentication Foundry
Microsoft Machine Learning Operations Engineer Associate (AI-300) · Test 1 · question 7 of 10
An agent application hosted on an Azure App Service calls a Microsoft Foundry project by using an API key stored in the app's configuration. A security review demands three things: every data plane call must be attributable to a specific principal, access must be revocable without a secret rotation that breaks other callers, and the app must hold only the permissions it actually needs. What should you implement?
Show answer and explanation
Answer:
Microsoft Foundry supports two authentication methods, and the documentation is explicit: use Microsoft Entra ID for production workloads to get conditional access, managed identities, and least privilege RBAC. A managed identity gives the App Service a credential-free identity; assigning it a built-in role such as Foundry User scopes it to data plane usage only, the token carries tenant and object IDs so calls are attributable per principal, and revocation is a role removal rather than a key rotation (option A). API keys support none of these: the feature matrix marks least privilege, managed identity, and per-request user attribution as No for keys, and the Agents service accepts Entra ID only.
- B is wrong because Key Vault protects the secret at rest but doesn't change what the secret *is*. An API key still provides full access to the resource, can't be scoped, and can't identify the caller, and rotating it breaks every other holder. - C is wrong because a shared client secret reintroduces the same problem one layer up. All callers appear as one principal, so per-caller attribution is lost, and the secret needs manual rotation and distribution. - D is wrong because Private Link addresses network reachability, not identity. Anyone who reaches the endpoint with the key still has unattributed, all-or-nothing access.
Reference: Authentication and authorization in Microsoft Foundry