AZ-305 Design infrastructure solutions Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Key Vault access policies

  Why it's wrong here

  Key Vault access policies are an authorization layer, not an authentication mechanism. They map Microsoft Entra ID principals (users, groups, service principals) to permissions such as `get`, `list`, and `set` for secrets, keys, and certificates. However, the App Service still needs its own Microsoft Entra ID identity to obtain a token before those permissions can be evaluated; access policies alone do not provision or configure that identity. Therefore, choosing this option leaves the fundamental authentication problem unresolved.

• ✗

  Microsoft Entra ID Application Registration with client secret

  Why it's wrong here

  Microsoft Entra ID Application Registration with a client secret does create a service principal that could be used to acquire a token for Key Vault, but it forces you to store the secret in App Service configuration settings. This approach introduces credential sprawl, secret rotation overhead, and an increased risk of leakage because the secret can appear in logs, source code, or backup snapshots. Managed identity avoids these pitfalls by eliminating the client secret entirely, which is why this option is not recommended.

• ✓

  Managed Identity

  Why this is correct

  Managed Identity is correct because it gives the App Service an Microsoft Entra ID-backed service principal that is automatically created and managed by Azure. The application retrieves a token from the Azure Instance Metadata Service (IMDS) endpoint without any secrets in code or configuration. After enabling the identity, you simply grant it read (`list` and `get`) permissions on the Key Vault via an access policy or RBAC, and the runtime calls Key Vault with that identity. This is the recommended Azure pattern for passwordless, secure access between Azure resources.

• ✗

  App Service Authentication / Authorization

  Why it's wrong here

  App Service Authentication/Authorization (EasyAuth) is an inbound feature that validates tokens presented by the end user's browser or client to protect the app's routes. It does nothing to alter the outbound identity that the application uses when calling downstream services like Key Vault. Even when you enable EasyAuth, the app still runs under the original managed identity or service principal, and outbound token acquisition is unaffected. Thus, this option is irrelevant to the requirement of authenticating the app itself to Key Vault.

Go deeper

Related to this question