AZ-500 Manage identity and access 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.

• ✓

  System-assigned managed identity with Key Vault access granted by RBAC or access policy

  Why this is correct

  A system-assigned managed identity is the correct choice because Azure automatically provisions a service principal for the VM, and the application can obtain an Microsoft Entra ID token through the instance metadata service (IMDS) without storing any credentials in code or configuration. Key Vault access is then granted to that identity via either Azure RBAC (for example, the Key Vault Secrets User role) or a legacy vault access policy, enabling the VM to read secrets securely and with automatic credential rotation managed by Azure.

• ✗

  Client secret stored in appsettings.json

  Why it's wrong here

  Storing a client secret in appsettings.json is insecure because the secret exists as plaintext on the filesystem and can easily leak through source control commits, backup copies, or log output. It also fails to leverage Microsoft Entra ID managed identity, forcing you to manually manage and rotate the secret throughout its lifecycle. While it may technically work to authenticate, it is not a direct or secure way to meet the requirement of reading secrets from Key Vault on an Azure VM.

• ✗

  Shared access signature stored as an environment variable

  Why it's wrong here

  A shared access signature (SAS) is a storage-level delegation token, not a mechanism for authenticating to Key Vault, so it does not address the requirement of reading Key Vault secrets. Even if the SAS itself were used to access some other secret store, placing it in an environment variable leaves a static credential exposed to any process or user with access to the VM's runtime environment. This approach neither integrates with Microsoft Entra ID identity nor provides the least-privilege, managed-credential benefits of a managed identity.

• ✗

  A user account excluded from MFA

  Why it's wrong here

  Using a user account excluded from MFA is inappropriate for an automated VM workload because user principals require interactive or delegated Microsoft Entra ID authentication, not a seamless workload identity. Excluding the account from MFA actively weakens the tenant's security posture and violates conditional access baseline policies. A managed identity is the correct workload identity; a user account, especially one with MFA bypassed, introduces unnecessary human-related risk and does not directly meet the stated requirement.

Go deeper

Related to this question