How to Use a User-Assigned Managed Identity Across VMs in Different Resource Groups
Three application VMs in different resource groups must use the same Azure identity to read blobs from a storage account. The identity must continue to work if the VMs are redeployed. What should you use?
Quick Answer
The answer is a user-assigned managed identity. This is the correct choice because it is a standalone Azure resource that exists independently of any VM lifecycle, meaning it persists even when VMs are redeployed, and it can be assigned to multiple VMs across different resource groups simultaneously. On the AZ-104 exam, this question tests your understanding of managed identity types and their scope—specifically, that system-assigned identities are tied to a single VM and cannot be shared, while user-assigned identities are designed for cross-resource group scenarios. A common trap is assuming a system-assigned identity can be reused, but it is destroyed when the VM is deleted. Remember: user-assigned identities are like a shared library card that works across multiple branches (resource groups), while system-assigned is a single-use card locked to one branch. For the exam, think “user for sharing, system for single.”
⚠ Common exam trap
Candidates often choose a system-assigned managed identity (Option A) because they assume it can be shared, but it is per-resource and cannot be assigned to multiple VMs across resource groups.
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
A user-assigned managed identity is the correct choice because it is a standalone Azure resource that can be assigned to multiple VMs across different resource groups. It persists independently of the VM lifecycle, so it continues to work even if the VMs are redeployed, and it can be used to authenticate to Azure Storage for blob read operations via Azure AD.
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 VM
Why it's wrong here
Each system-assigned identity is tied to one VM instance, so it is not a shared identity.
When this WOULD be correct
A system-assigned managed identity would be correct if each VM needs its own unique identity to access a resource (e.g., each VM authenticates to a different storage account), and the identity is not required to persist across redeployments.
- ✓
A user-assigned managed identity
Why this is correct
A user-assigned managed identity can be attached to multiple VMs and survives VM redeployment.
- ✗
A shared access signature stored in a configuration file
Why it's wrong here
A SAS token is a secret credential and is not a durable managed identity for multiple VMs.
When this WOULD be correct
A shared access signature would be correct for granting time-limited, delegated access to a specific storage resource (e.g., a single blob or container) from a client application that can securely store the SAS token (e.g., in Azure Key Vault) and regenerate it as needed, without requiring an Azure AD identity.
- ✗
The local Administrator account on each VM
Why it's wrong here
Local accounts do not provide a shared Azure identity and would require separate credential management.
When this WOULD be correct
This option would be correct if the question asked for a way to allow local administrative access to the VMs themselves (e.g., RDP) using a consistent local account across redeployments, such as when using a custom image with a preconfigured local admin password.
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 identityCorrect answer▾
Why this is correct
A user-assigned managed identity can be attached to multiple VMs and survives VM redeployment.
✗A system-assigned managed identity on each VMWrong answer — click to see why▾
Why this is wrong here
System-assigned managed identities are tied to each VM's lifecycle and cannot be shared across multiple VMs in different resource groups. If the VMs are redeployed, each VM would get a new identity, breaking the shared access requirement.
★ When this WOULD be the correct answer
A system-assigned managed identity would be correct if each VM needs its own unique identity to access a resource (e.g., each VM authenticates to a different storage account), and the identity is not required to persist across redeployments.
Why candidates choose this
Candidates may think managed identities are the right approach but confuse system-assigned (per-VM) with user-assigned (shareable), or assume that 'managed identity' automatically implies sharing capability.
✗A shared access signature stored in a configuration fileWrong answer — click to see why▾
Why this is wrong here
A shared access signature (SAS) stored in a configuration file does not persist across VM redeployments because the file is lost when the VM is deallocated, and it cannot be shared across multiple VMs in different resource groups without manual management.
★ When this WOULD be the correct answer
A shared access signature would be correct for granting time-limited, delegated access to a specific storage resource (e.g., a single blob or container) from a client application that can securely store the SAS token (e.g., in Azure Key Vault) and regenerate it as needed, without requiring an Azure AD identity.
Why candidates choose this
Candidates may think a SAS is a simple, shared credential that can be placed in a configuration file and used by multiple VMs, overlooking the fact that the file is ephemeral and the SAS does not support automatic identity management across redeployments.
✗The local Administrator account on each VMWrong answer — click to see why▾
Why this is wrong here
The local Administrator account is a static credential tied to each VM, not an Azure identity. It cannot be used to authenticate to Azure Storage across multiple VMs, and it does not persist across redeployments if the VM is reimaged or recreated.
★ When this WOULD be the correct answer
This option would be correct if the question asked for a way to allow local administrative access to the VMs themselves (e.g., RDP) using a consistent local account across redeployments, such as when using a custom image with a preconfigured local admin password.
Why candidates choose this
Candidates may think a local admin account can be used as a shared identity across VMs because it is a common credential, and they may overlook that Azure RBAC requires an Azure AD identity, not a local OS account.
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
Dynamic Membership Groups
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
Blob
A blob is a large piece of unstructured data, like a photo or video, stored in the cloud with a unique identifier.
About these practice questions
Courseiva writes every AZ-104 question from scratch — 1,049 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
Same concept, more angles
1 more way this is tested on AZ-104
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. An App Service application needs to read secrets from Azure Key Vault. The security team does not want any password, certificate, or client secret stored in application settings, and they want the identity removed automatically if the app is deleted. What should the administrator enable?
medium- A.A service principal with a client secret stored in App Service configuration.
- ✓ B.A system-assigned managed identity on the App Service.
- C.A user-assigned managed identity shared by all applications.
- D.A shared access signature stored in Key Vault.
Why B: A system-assigned managed identity (Option B) is the correct choice because it provides an identity for the App Service that is automatically managed by Azure, tied to the lifecycle of the resource (deleted when the app is deleted), and requires no credentials to be stored in application settings. This allows the app to authenticate to Key Vault using Azure AD tokens without any secrets, satisfying the security team's requirements.
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.