AZ-104 Manage Azure Identities and Governance Practice Question
Three Azure VMs run the same scheduled script and must access both Storage and Key Vault. The team wants one identity that can be reused if a VM is rebuilt, and they do not want the identity tied to a single machine. What should the administrator create?
⚠ Common exam trap
Candidates often confuse system-assigned and user-assigned managed identities, incorrectly assuming that system-assigned identities can be shared across VMs or persist after VM deletion, when in fact only user-assigned identities are independent, reusable resources.
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 user-assigned managed identity attached to all three virtual machines.
A user-assigned managed identity is the correct choice because it is an independent Azure resource that can be assigned to multiple VMs, persists independently of any single VM's lifecycle, and can be reused when a VM is rebuilt. This identity provides seamless authentication to both Storage and Key Vault without managing credentials, meeting the requirement for a reusable, non-machine-tied identity.
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 system-assigned managed identity on each virtual machine.
Why it's wrong here
System-assigned managed identities create a separate Azure AD service principal for each VM, with the identity lifecycle tied to the individual VM. If you assign one to each of the three VMs, you end up with three distinct principals that must each be granted access to storage and Key Vault, and deleting any VM destroys its identity. The scheduled script would have to authenticate as different identities depending on which VM it runs on, which complicates RBAC assignments and makes the solution less maintainable than a shared user-assigned identity.
When this WOULD be correct
When the requirement is for a single VM to access Azure resources without managing credentials, and the identity should be automatically deleted when the VM is deleted (e.g., a temporary VM for a specific task).
- ✗
A service principal with a certificate file copied to each VM.
Why it's wrong here
Registering a service principal and copying a certificate file to each VM gives the VMs the same principal, but it relies on distributing and protecting a private key across multiple machines. Certificate-based authentication requires ongoing certificate rotation and secure storage on every VM, and if one VM is compromised the certificate must be revoked and re-deployed. A user-assigned managed identity achieves the same 'single principal' goal without any secret management because Azure rotates the underlying credentials automatically.
When this WOULD be correct
When the requirement is to authenticate an on-premises application or a service running outside Azure, and the identity must be managed independently of Azure resources, using a service principal with certificate-based authentication is appropriate.
- ✓
A user-assigned managed identity attached to all three virtual machines.
Why this is correct
A user-assigned managed identity is a standalone Azure AD identity that can be assigned to multiple resources, including all three VMs, making it a single service principal shared by the scheduled script. Because the identity's lifecycle is separate from any VM, you can attach it to all three instances and later add or remove VMs without recreating the identity. Once the identity is assigned, you grant it the necessary RBAC role on the storage account and an access policy in Key Vault, allowing all three VMs to authenticate via the Azure Instance Metadata Service (IMDS) without storing any credential.
- ✗
A shared access signature for each storage account and Key Vault access policy.
Why it's wrong here
Using a shared access signature (SAS) for storage and an access policy for Key Vault does not create a reusable identity across the three VMs. A SAS is a delegated URI that grants scoped, time-limited access to a specific storage service, but it is not a security principal; Key Vault access policies must be assigned to an Azure AD principal, so you still need a service principal or managed identity to authenticate to the vault. This approach forces you to distribute and rotate SAS tokens and client secrets separately, introducing credential management that managed identities eliminate.
When this WOULD be correct
A shared access signature would be correct if the question asked for a time-limited, delegated access token to grant a client (e.g., a script) direct access to a specific storage account or Key Vault without requiring an Azure AD identity, such as when the client cannot use managed identities.
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 user-assigned managed identity attached to all three virtual machines.Correct answer▾
Why this is correct
A user-assigned managed identity is a standalone Azure AD identity that can be assigned to multiple resources, including all three VMs, making it a single service principal shared by the scheduled script. Because the identity's lifecycle is separate from any VM, you can attach it to all three instances and later add or remove VMs without recreating the identity. Once the identity is assigned, you grant it the necessary RBAC role on the storage account and an access policy in Key Vault, allowing all three VMs to authenticate via the Azure Instance Metadata Service (IMDS) without storing any credential.
✗A system-assigned managed identity on each virtual machine.Wrong answer — click to see why▾
Why this is wrong here
A system-assigned managed identity is tied to the lifecycle of a specific VM; if the VM is rebuilt, the identity is deleted and recreated, so it cannot be reused across rebuilds or shared among multiple VMs.
★ When this WOULD be the correct answer
When the requirement is for a single VM to access Azure resources without managing credentials, and the identity should be automatically deleted when the VM is deleted (e.g., a temporary VM for a specific task).
Why candidates choose this
Candidates may think system-assigned managed identities are simpler to set up and assume they can be reused, not realizing they are tied to the VM's lifecycle and cannot be shared.
✗A service principal with a certificate file copied to each VM.Wrong answer — click to see why▾
Why this is wrong here
A service principal with a certificate file copied to each VM requires manual certificate management and rotation, and the identity is tied to the VM's certificate file, not reusable if the VM is rebuilt without the same certificate.
★ When this WOULD be the correct answer
When the requirement is to authenticate an on-premises application or a service running outside Azure, and the identity must be managed independently of Azure resources, using a service principal with certificate-based authentication is appropriate.
Why candidates choose this
Candidates may think a service principal is the standard way to assign permissions to applications, and using a certificate seems secure and reusable, but they overlook the management overhead and the fact that managed identities are designed for Azure resources.
✗A shared access signature for each storage account and Key Vault access policy.Wrong answer — click to see why▾
Why this is wrong here
A shared access signature (SAS) provides delegated access to a specific storage account or Key Vault but is not an identity that can be reused across VMs; it is a token tied to a resource, not an Azure AD identity, and does not support the requirement of a single reusable identity.
★ When this WOULD be the correct answer
A shared access signature would be correct if the question asked for a time-limited, delegated access token to grant a client (e.g., a script) direct access to a specific storage account or Key Vault without requiring an Azure AD identity, such as when the client cannot use managed identities.
Why candidates choose this
Candidates may confuse SAS with a form of identity because it provides access without a password, or they might think it can be reused across VMs by copying the token, overlooking that SAS is resource-specific and not an Azure AD identity object.
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
User-assigned managed identity
A user-assigned managed identity is a standalone Azure identity that can be assigned to one or more Azure resources, enabling them to authenticate to other 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.