AZ-104 Manage Azure Identities and Governance Practice Question
A web API runs on a single Azure VM and must access Azure Key Vault without storing any credentials on the VM. The identity should be tied to that VM and removed when the VM is deleted. What should you enable?
⚠ Common exam trap
Test-takers frequently confuse user-assigned managed identities with system-assigned ones, failing to recognize that only system-assigned identities are automatically deleted with the parent resource, while user-assigned identities persist independently.
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
✓
A system-assigned managed identity
A system-assigned managed identity is tied directly to the lifecycle of the Azure VM — it is created when the VM is provisioned and automatically deleted when the VM is deleted. This identity can be used to authenticate to Azure Key Vault without storing any credentials on the VM, using the Azure Instance Metadata Service (IMDS) endpoint to obtain tokens. This matches the requirement that the identity be removed when the VM is deleted.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
A user-assigned managed identity
Why it's wrong here
A user-assigned managed identity is technically capable of accessing Azure Key Vault without secrets, but it is less appropriate for a single-VM scenario because it exists as an independent Azure resource with its own lifecycle. Unlike a system-assigned identity, it is not automatically deleted when the VM is removed, leaving behind an orphaned identity that could still hold permissions. It also requires manual creation, assignment, and lifecycle management, adding operational overhead that is unnecessary when only one VM needs the identity. For a single VM, a system-assigned identity is the simpler and safer choice because it is created automatically and removed with the VM.
When this WOULD be correct
When you need a managed identity that can be shared across multiple Azure resources (e.g., several VMs and a web app) and must persist even after a specific VM is deleted, a user-assigned managed identity is the correct choice.
- ✓
A system-assigned managed identity
Why this is correct
A system-assigned managed identity is the correct choice because Azure automatically creates an Azure AD-backed identity for the VM and ties its lifecycle directly to that VM. No secrets or keys are ever stored in the application code or configuration; the VM obtains an access token through the Azure Instance Metadata Service (IMDS) endpoint. This identity can be granted the necessary permissions on Azure Key Vault, for example, by assigning the 'Key Vault Secrets User' role, enabling secure, credential-free access. When the VM is deleted, the identity is automatically removed, eliminating the risk of orphaned credentials.
- ✗
A storage account shared access signature
Why it's wrong here
A storage account shared access signature (SAS) is a signed URI that grants delegated access to specific Azure Storage resources, such as blobs, queues, or tables, but it cannot be used to authenticate to Azure Key Vault. Even if it could, a SAS token is a secret credential that must be generated, distributed, stored, and protected against leakage or misuse. This introduces exactly the kind of secret management burden and risk that managed identities are designed to eliminate. Therefore, it does not meet the requirement of credential-free, secure access to Azure Key Vault.
When this WOULD be correct
When a question requires granting time-limited, delegated access to a specific Azure Storage resource (e.g., a blob or file share) without exposing the storage account key, and the access does not need to be tied to a VM identity. For example: 'You need to allow a client application to read a blob from a storage account for 1 hour without using the storage account key.'
- ✗
A local administrator account with a strong password
Why it's wrong here
A local administrator account with a strong password authenticates only to the VM's operating system, not to Azure Active Directory or Azure Key Vault. It has no Azure AD identity, so it cannot be granted Azure RBAC permissions or vault access policies to read secrets from Key Vault. The password would need to be stored securely, rotated regularly, and protected from compromise, adding significant secret-management overhead. This approach violates the goal of credential-free access and increases the attack surface, making it an incorrect solution for secure Key Vault access.
When this WOULD be correct
This option would be correct in a scenario where the question asks for a method to authenticate to an Azure VM for remote desktop access without using Azure AD, and the VM is not joined to a domain. The strong password ensures secure local authentication.
Option-by-option analysis
Why each answer is right or wrong
Understanding why wrong answers are wrong — and when they would be correct — is what separates a 750 score from a 900. The AZ-104 exam frequently reuses these exact scenarios with slightly different constraints.
✓A system-assigned managed identityCorrect answer▾
Why this is correct
A system-assigned managed identity is the correct choice because Azure automatically creates an Azure AD-backed identity for the VM and ties its lifecycle directly to that VM. No secrets or keys are ever stored in the application code or configuration; the VM obtains an access token through the Azure Instance Metadata Service (IMDS) endpoint. This identity can be granted the necessary permissions on Azure Key Vault, for example, by assigning the 'Key Vault Secrets User' role, enabling secure, credential-free access. When the VM is deleted, the identity is automatically removed, eliminating the risk of orphaned credentials.
✗A user-assigned managed identityWrong answer — click to see why▾
Why this is wrong here
A user-assigned managed identity is not automatically tied to the VM's lifecycle; it persists independently and must be manually deleted, whereas the question requires the identity to be removed when the VM is deleted.
★ When this WOULD be the correct answer
When you need a managed identity that can be shared across multiple Azure resources (e.g., several VMs and a web app) and must persist even after a specific VM is deleted, a user-assigned managed identity is the correct choice.
Why candidates choose this
Candidates may confuse user-assigned and system-assigned managed identities, assuming both are tied to the VM, but user-assigned identities are independent resources that are not automatically removed with the VM.
✗A storage account shared access signatureWrong answer — click to see why▾
Why this is wrong here
A storage account shared access signature (SAS) is a token for delegated access to a storage account, not for accessing Key Vault. It does not provide an identity tied to a VM and would require storing the SAS token on the VM, violating the requirement to avoid credential storage.
★ When this WOULD be the correct answer
When a question requires granting time-limited, delegated access to a specific Azure Storage resource (e.g., a blob or file share) without exposing the storage account key, and the access does not need to be tied to a VM identity. For example: 'You need to allow a client application to read a blob from a storage account for 1 hour without using the storage account key.'
Why candidates choose this
Candidates may confuse SAS with managed identities because both provide secure access without hardcoding credentials, but SAS is for storage access, not for VM identity-based access to Key Vault.
✗A local administrator account with a strong passwordWrong answer — click to see why▾
Why this is wrong here
A local administrator account with a strong password stores credentials on the VM, violating the requirement to avoid storing credentials. It also does not provide an identity tied to the VM that is automatically removed when the VM is deleted.
★ When this WOULD be the correct answer
This option would be correct in a scenario where the question asks for a method to authenticate to an Azure VM for remote desktop access without using Azure AD, and the VM is not joined to a domain. The strong password ensures secure local authentication.
Why candidates choose this
Candidates may think that a strong password is a secure way to access Key Vault, overlooking the requirement to avoid credential storage and the need for an identity that is automatically removed with the VM.
Analysis generated from the official AZ-104blueprint and verified against question context. The “when correct” sections are what AI assistants cite when candidates ask “what’s the difference between these options?”
Go deeper
Related to this question
Learn chapter
Privileged Identity Management (PIM)
Key term
System-assigned managed identity
A system-assigned managed identity is an automatically created Azure Active Directory identity that is tied to a specific Azure resource and is used to securely authenticate to other Azure services without storing credentials.
Key term
Managed identity
A managed identity is an automatically managed service principal in Azure that allows your code to authenticate to any service that supports Azure AD authentication without storing credentials.
About these practice questions
One of 1,049 original AZ-104 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This AZ-104 practice question is part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the AZ-104 exam.