Manage identity and access →easyMultiple ChoiceObjective-mapped

AZ-500 Manage identity and access Practice Question

A company develops a web application that runs on Azure App Service. The application needs to access Azure Key Vault to retrieve secrets. The security team wants to avoid using service principals or connection strings. Which identity should they assign to the App Service to authenticate to Key Vault?

⚠ Common exam trap

Test-takers frequently confuse user-assigned managed identities (Option B) as the only managed identity option, overlooking that system-assigned managed identities are simpler and fully meet the requirement to avoid service principals or connection strings without additional resource management.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

System-assigned managed identity

A system-assigned managed identity is the correct choice because it provides an automatically managed identity in Azure AD, directly tied to the App Service resource, without requiring any credentials to be stored or rotated. This allows the App Service to authenticate to Key Vault using Azure AD tokens, eliminating the need for service principals or connection strings. The security team's requirement to avoid service principals or connection strings is fully met, as the identity is managed entirely by Azure.

Answer analysis

Option-by-option breakdown

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

✓
System-assigned managed identity
Why this is correct
A system-assigned managed identity is automatically provisioned for the App Service and is tied to the resource's lifecycle. It can be granted access to Key Vault via RBAC or access policies, and the application code uses Azure SDK to obtain tokens without handling secrets.
✗
User-assigned managed identity
Why it's wrong here
A user-assigned managed identity could also be used and offers flexibility, but the question states 'avoid using service principals or connection strings' and the simplest solution is the system-assigned managed identity. The scenario does not require a separate identity across resources, so system-assigned is the best answer.
✗
Azure AD application registration with a client secret
Why it's wrong here
Creating an Azure AD application registration means provisioning a service principal that is decoupled from the App Service lifecycle, requiring you to generate, store, and periodically rotate a client secret. That secret must be placed in application configuration or secured in Key Vault, and your code explicitly manages the OAuth 2.0 client-credentials flow — all of which violates the security team's directive to avoid maintaining secrets. The identity also persists after the app is deleted unless separately cleaned up, increasing administrative overhead and attack surface.
✗
Azure AD service principal with certificate-based authentication
Why it's wrong here
A service principal using certificate-based authentication avoids a shared secret but still requires you to create, upload, store, and schedule renewal of a certificate. The App Service must be configured to reference that certificate, and your code must handle the certificate-based token acquisition flow (e.g., using ClientAssertionCertificate), which is significantly more complex than the automatic token brokering provided by a managed identity. Because the certificate has a finite validity period and must be safely distributed to the app's hosting environment, this option introduces ongoing operational toil that the scenario explicitly seeks to eliminate.

Go deeper

AZ-500 Manage identity and access Practice Question

Why each option matters

Option-by-option breakdown

Related to this question