Manage Azure Identities and Governance →mediumMultiple SelectObjective-mapped

AZ-104 Manage Azure Identities and Governance Practice Question

Three application VMs in separate resource groups must use the same identity to read a configuration endpoint. The identity must keep working if any one VM is deleted and later recreated. Which three actions should the administrator take? Select three.

⚠ Common exam trap

Many candidates confuse user-assigned and system-assigned managed identities, incorrectly assuming that a system-assigned identity can be shared across VMs or that its access token can be copied, when in fact system-assigned identities are per-resource and cannot survive resource deletion.

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

✓

Create a user-assigned managed identity that can exist independently of any single VM.

A user-assigned managed identity is an Azure resource that exists independently of any VM, unlike a system-assigned identity which is tied to the VM lifecycle. This independence ensures the identity persists even when a VM is deleted and recreated, maintaining continuous access to the configuration endpoint. By creating a user-assigned managed identity, the administrator decouples the identity from any single VM, satisfying the requirement that the identity must keep working after VM deletion and recreation.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✓
Create a user-assigned managed identity that can exist independently of any single VM.
Why this is correct
A user-assigned managed identity has its own lifecycle and is not deleted when a VM is removed. That makes it the correct choice when multiple VMs need the same identity and the identity must survive VM recreation.
✓
Attach the same user-assigned managed identity to each of the three VMs.
Why this is correct
Attaching the same user-assigned managed identity to each of the three VMs leverages Azure's support for a single identity being assigned to multiple resources. Because user-assigned identities exist as top-level Azure resources, they can be associated with any number of VMs, and those VMs will all present the same principal ID when authenticating to Azure AD. This avoids creating separate credentials per machine and ensures that if any VM is recreated, the identity remains available for reassignment without orphaned or duplicated secrets.
✓
Grant the user-assigned identity the minimum required RBAC role on the target configuration endpoint.
Why this is correct
The identity still needs authorization to read the endpoint, so RBAC must be assigned at the appropriate scope. Least privilege keeps the permission set narrow while allowing all VMs that use the shared identity to succeed.
✗
Use a system-assigned managed identity on only one VM and copy its access token to the other two VMs.
Why it's wrong here
A system-assigned managed identity is intrinsically bound to a single VM and is deleted when that VM is deleted, so using it on only one VM and copying its access token to the other two is not a viable shared identity. Access tokens are short-lived (typically under 24 hours) and must be continuously refreshed, which would force the other VMs to depend on the one source VM remaining alive. Furthermore, extracting and replaying tokens outside the intended resource violates Azure's token-handling model and creates a security risk, because the token is not scoped to the other VMs' identities and cannot be renewed without accessing the original VM's identity endpoint.
When this WOULD be correct
If the question required a single VM to access a resource without managing credentials, and the identity could be recreated automatically when the VM is recreated, a system-assigned managed identity would be correct.
✗
Store one application password locally on each VM and use it instead of Azure-managed identities.
Why it's wrong here
Storing an application password locally on each VM reintroduces the exact credential-management burden that managed identities eliminate. Passwords must be securely stored, rotated, and protected on every VM, and a leaked or stale password becomes a shared secret that an attacker can reuse across all three systems. Azure-managed identities, by contrast, are backed by Azure Active Directory and require no static secrets on the VM, so this option fundamentally fails the requirement to rely on an Azure identity that persists independently of VM lifecycle.
When this WOULD be correct
This option would be correct in a scenario where the application requires a client secret for authentication to an external service that does not support managed identities, and the VMs are in a stable environment where secrets can be securely stored and rotated.

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.

✓Create a user-assigned managed identity that can exist independently of any single VM.Correct answer▾

Why this is correct

A user-assigned managed identity has its own lifecycle and is not deleted when a VM is removed. That makes it the correct choice when multiple VMs need the same identity and the identity must survive VM recreation.

✗Use a system-assigned managed identity on only one VM and copy its access token to the other two VMs.Wrong answer — click to see why▾

Why this is wrong here

System-assigned managed identities are tied to a single VM's lifecycle; deleting and recreating the VM would break the identity, and copying access tokens is insecure and not supported for cross-VM use.

★ When this WOULD be the correct answer

If the question required a single VM to access a resource without managing credentials, and the identity could be recreated automatically when the VM is recreated, a system-assigned managed identity would be correct.

Why candidates choose this

Candidates may think system-assigned identities are simpler and that tokens can be shared, overlooking the identity lifecycle dependency and security implications.

✗Store one application password locally on each VM and use it instead of Azure-managed identities.Wrong answer — click to see why▾

Why this is wrong here

Storing an application password locally on each VM violates the requirement for the identity to keep working if a VM is deleted and recreated, as the password would be lost or require manual reconfiguration. It also introduces security risks and does not use Azure-managed identities.

★ When this WOULD be the correct answer

This option would be correct in a scenario where the application requires a client secret for authentication to an external service that does not support managed identities, and the VMs are in a stable environment where secrets can be securely stored and rotated.

Why candidates choose this

Candidates may think that using a local password is simpler and more familiar than managed identities, or they may not fully understand how managed identities work and their benefits for resilience and security.

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

AZ-104 Manage Azure Identities and Governance Practice Question

Why each option matters

Option-by-option breakdown

Why each answer is right or wrong

Related to this question