AZ-104 Manage Azure Identities and Governance Practice Question
Three Azure VMs in separate resource groups run the same data-processing agent. The agent must read blobs from a storage account, and the access must continue to work if any VM is rebuilt or replaced. The operations team also wants one identity they can reassign to future VMs without creating another credential. Which identity approach should be used?
⚠ Common exam trap
Many exam-takers confuse system-assigned and user-assigned managed identities, assuming both are equally reusable, but system-assigned identities are deleted with the VM, making them unsuitable for scenarios requiring identity persistence across VM rebuilds.
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 the VMs.
A user-assigned managed identity (D) is the correct choice because it is a standalone Azure resource that can be created independently and then attached to multiple VMs. If a VM is rebuilt or replaced, the same user-assigned identity can be reassigned to the new VM without any credential rotation or secret management. This ensures continuous blob access via Azure AD authentication, meeting the requirement for a single, reusable 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 VM.
Why it's wrong here
System-assigned managed identities are tied to an individual VM resource. They disappear when that VM is deleted and cannot be directly reused by future VMs, which makes them a poor fit for shared identity reuse.
When this WOULD be correct
A system-assigned managed identity would be correct if each VM needs its own unique identity (e.g., for individual auditing) and the VMs are never rebuilt or replaced, or if the role assignment is recreated automatically via infrastructure-as-code.
- ✗
A storage account shared key embedded in the application settings.
Why it's wrong here
A storage account shared key is a static credential, not an Azure identity. Embedding it in application settings means the key must be stored, protected, and rotated manually, and it exposes the entire storage account if leaked. Since the requirement is to avoid any credential management and use a reusable Azure identity, this option fails because it introduces a secret that must be handled and does not scale across VMs as an identity.
When this WOULD be correct
This option would be correct if the question required a simple, low-cost solution for a single VM that does not need identity reassignment, and security requirements are minimal (e.g., a development or test environment).
- ✗
A service principal credential stored in a Key Vault secret.
Why it's wrong here
A service principal can authenticate, but it still relies on a secret or certificate that must be managed. The requirement specifically asks for an identity that can be reused across VMs without creating another credential.
When this WOULD be correct
This option would be correct if the question required the identity to be used by applications running outside Azure (e.g., on-premises) or if the VMs were in a different tenant, where managed identities are not supported. It would also be correct if the scenario explicitly required storing the credential in a secure vault for auditing or rotation purposes.
- ✓
A user-assigned managed identity attached to the VMs.
Why this is correct
A user-assigned managed identity is the right choice when the same Azure identity must be shared across multiple VMs and survive VM replacement. You can grant it access once, attach it to current and future VMs, and avoid storing passwords or access keys in the workload.
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 the VMs.Correct answer▾
Why this is correct
A user-assigned managed identity is the right choice when the same Azure identity must be shared across multiple VMs and survive VM replacement. You can grant it access once, attach it to current and future VMs, and avoid storing passwords or access keys in the workload.
✗A system-assigned managed identity on each VM.Wrong answer — click to see why▾
Why this is wrong here
A system-assigned managed identity is tied to the lifecycle of a single VM; if the VM is rebuilt, the identity is deleted and recreated, breaking the RBAC role assignment on the storage account. The question requires the identity to persist across VM rebuilds.
★ When this WOULD be the correct answer
A system-assigned managed identity would be correct if each VM needs its own unique identity (e.g., for individual auditing) and the VMs are never rebuilt or replaced, or if the role assignment is recreated automatically via infrastructure-as-code.
Why candidates choose this
Candidates may think managed identities are always the best practice for Azure resources, and system-assigned seems simpler to enable without extra setup, overlooking the lifecycle dependency.
✗A storage account shared key embedded in the application settings.Wrong answer — click to see why▾
Why this is wrong here
A storage account shared key embedded in application settings is not secure and does not support identity reassignment; if a VM is rebuilt, the key must be re-deployed, and it cannot be easily reassigned to future VMs without creating a new credential.
★ When this WOULD be the correct answer
This option would be correct if the question required a simple, low-cost solution for a single VM that does not need identity reassignment, and security requirements are minimal (e.g., a development or test environment).
Why candidates choose this
Candidates may think embedding a shared key in application settings is straightforward and avoids the complexity of managed identities, overlooking security and manageability requirements.
✗A service principal credential stored in a Key Vault secret.Wrong answer — click to see why▾
Why this is wrong here
A service principal credential stored in Key Vault requires managing a secret and rotating it, and if the VM is rebuilt, the application must retrieve the secret again, which adds complexity and a dependency on Key Vault availability. The question requires a single identity that can be reassigned to future VMs without creating another credential, which user-assigned managed identity fulfills more directly.
★ When this WOULD be the correct answer
This option would be correct if the question required the identity to be used by applications running outside Azure (e.g., on-premises) or if the VMs were in a different tenant, where managed identities are not supported. It would also be correct if the scenario explicitly required storing the credential in a secure vault for auditing or rotation purposes.
Why candidates choose this
Candidates may think Key Vault is the best practice for storing secrets and that a service principal is the standard way to grant access to Azure resources, overlooking that managed identities eliminate the need to manage credentials entirely.
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
Blob
A blob is a large piece of unstructured data, like a photo or video, stored in the cloud with a unique identifier.
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.
About these practice questions
This AZ-104 question is part of Courseiva's 1,049-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
Same concept, more angles
3 more ways 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. Three Azure virtual machines in different resource groups must all use the same Azure identity to access a storage account. The identity should keep working even if one VM is rebuilt. What should you use?
easy- A.A system-assigned managed identity on each VM
- ✓ B.A user-assigned managed identity
- C.A shared VM administrator password
- D.A storage account SAS token
Why B: A user-assigned managed identity is created as a standalone Azure resource and can be assigned to multiple VMs, even across resource groups. It persists independently of any VM lifecycle, so rebuilding a VM does not affect the identity's availability or its permissions to access the storage account.
Variation 2. A scheduled script runs on several Azure virtual machines that are created and replaced over time. The script must use the same Azure identity on every VM, and the identity should continue to exist even if one VM is deleted and recreated. What should the administrator use?
medium- A.A system-assigned managed identity on each VM.
- ✓ B.A user-assigned managed identity attached to the VMs.
- C.A service principal with a client secret stored in each VM.
- D.A shared access signature stored in the VM registry.
Why B: A user-assigned managed identity is the correct choice because it is an Azure resource that exists independently of any VM, and it can be attached to multiple VMs. When a VM is deleted and recreated, the same user-assigned managed identity can be reattached, ensuring the script uses the same identity consistently. This decouples the identity lifecycle from the VM lifecycle, meeting the requirement for persistence across VM replacements.
Variation 3. A scheduled script runs on several Azure VMs. The VMs are rebuilt often, and the script must always use the same Azure identity across every rebuild without storing secrets on disk. Which two steps should the administrator take? Select two.
hard- ✓ A.Create a user-assigned managed identity.
- ✓ B.Assign that user-assigned identity to each VM that runs the script.
- C.Use a system-assigned managed identity on one VM and clone it.
- D.Store a service principal secret in the script configuration.
- E.Use a shared access signature to authenticate to Azure Resource Manager.
Why A: A user-assigned managed identity is the correct choice because it is an Azure identity that exists independently of any VM and can be assigned to multiple VMs. When a VM is rebuilt, you simply assign the same user-assigned identity to the new VM, and the script can authenticate using the identity's client ID without storing any secrets on disk. This ensures the script always uses the same identity across rebuilds, as the identity's credentials are managed entirely by Azure and rotated automatically.
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.