AZ-104 Manage Azure Identities and Governance Practice Question
A system-assigned managed identity is attached to an Azure VM to call Key Vault. The VM is frequently reimaged and sometimes redeployed to a different name during scale events, but the application must keep the same identity and secretless access. What should the administrator use instead?
⚠ Common exam trap
Many candidates assume system-assigned identities are reusable across VM redeployments, but they are instance-scoped and destroyed with the VM, whereas user-assigned identities are persistent and can be reassigned to any resource.
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 associated with the workload.
A user-assigned managed identity is decoupled from the VM lifecycle, so it persists independently when VMs are reimaged or redeployed with different names. This allows the application to retain the same identity and secretless access to Key Vault without requiring manual reconfiguration or credential rotation.
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 newly deployed VM.
Why it's wrong here
A system-assigned managed identity is tied directly to the lifecycle of the VM it is created on. If that VM is deleted, the identity is automatically deleted with it, and a newly deployed VM gets a brand-new identity. This means the identity does not persist across VM reimages or redeployments, breaking the workload's ability to maintain consistent access to resources like Key Vault. It also complicates management when the workload scales to multiple VMs, because each VM would have a separate identity, requiring duplicate access grants.
When this WOULD be correct
A system-assigned managed identity would be correct if the VM is never reimaged or redeployed, and the identity is used only for a single, persistent VM instance that does not change over time.
- ✓
A user-assigned managed identity associated with the workload.
Why this is correct
A user-assigned managed identity is a standalone Azure resource that exists independently of any single VM. It can be assigned to multiple VMs or scale sets and remains valid across reimages, redeployments, or replacement of underlying compute. This identity allows the workload to authenticate to Azure Active Directory and securely retrieve secrets from Key Vault without embedding credentials, making it the correct choice for a workload that needs a stable identity across infrastructure changes.
- ✗
A shared storage account key placed in the VM custom script.
Why it's wrong here
Placing a storage account key in a custom script exposes a long-lived credential, which is exactly the kind of secret leakage that managed identities are designed to avoid. Storage account keys grant broad access to all blobs, queues, and tables in the account, far exceeding the principle of least privilege. Additionally, any storage account key that appears in script text can be copied by anyone who can read the script, and rotating the key would require updating and redeploying every VM—making it an insecure and operationally burdensome approach.
When this WOULD be correct
In a scenario where a legacy application cannot use managed identities and needs to access Azure Storage from a VM, and the requirement is to avoid interactive logins, a storage account key in a custom script (or better, a managed identity) could be used, but only if secretless access is not required.
- ✗
A policy exemption for the Key Vault access policy.
Why it's wrong here
A policy exemption only excludes the Key Vault from an Azure Policy assignment; it does not grant any kind of authentication or authorization. To access Key Vault, the workload still must present a valid identity (for example, a managed identity) that has been granted an access policy or RBAC role. Without an identity, an exemption cannot enable the VM to authenticate, and therefore does not satisfy the requirement for secretless access.
When this WOULD be correct
A policy exemption would be correct if the question described a scenario where an Azure Policy (e.g., requiring Key Vault firewall rules) is blocking legitimate access, and the administrator needs to allow access for a specific VM while maintaining the policy for other resources.
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 associated with the workload.Correct answer▾
Why this is correct
A user-assigned managed identity is a standalone Azure resource that exists independently of any single VM. It can be assigned to multiple VMs or scale sets and remains valid across reimages, redeployments, or replacement of underlying compute. This identity allows the workload to authenticate to Azure Active Directory and securely retrieve secrets from Key Vault without embedding credentials, making it the correct choice for a workload that needs a stable identity across infrastructure changes.
✗A system-assigned managed identity on each newly deployed VM.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 instance. When the VM is reimaged or redeployed with a different name, the identity is lost, and the new VM would get a new identity, breaking the application's access.
★ When this WOULD be the correct answer
A system-assigned managed identity would be correct if the VM is never reimaged or redeployed, and the identity is used only for a single, persistent VM instance that does not change over time.
Why candidates choose this
Candidates may think system-assigned managed identities are simpler to configure and assume they persist across VM operations, not realizing they are tied to the VM's lifecycle and are lost on reimage or redeployment.
✗A shared storage account key placed in the VM custom script.Wrong answer — click to see why▾
Why this is wrong here
A shared storage account key placed in a custom script exposes a static secret that must be managed and rotated, violating the requirement for secretless access and not preserving identity across VM reimages or redeployments.
★ When this WOULD be the correct answer
In a scenario where a legacy application cannot use managed identities and needs to access Azure Storage from a VM, and the requirement is to avoid interactive logins, a storage account key in a custom script (or better, a managed identity) could be used, but only if secretless access is not required.
Why candidates choose this
Candidates may think a shared key is a simple way to provide consistent access without understanding that it introduces a static secret, contradicts secretless access, and fails to maintain identity across VM changes.
✗A policy exemption for the Key Vault access policy.Wrong answer — click to see why▾
Why this is wrong here
A policy exemption does not provide authentication; it only bypasses Azure Policy effects. The VM still needs a managed identity or other credential to authenticate to Key Vault, and a policy exemption does not grant access to secrets.
★ When this WOULD be the correct answer
A policy exemption would be correct if the question described a scenario where an Azure Policy (e.g., requiring Key Vault firewall rules) is blocking legitimate access, and the administrator needs to allow access for a specific VM while maintaining the policy for other resources.
Why candidates choose this
Candidates may confuse policy exemptions with access policies or think that exempting a VM from policy automatically grants it access to Key Vault, misunderstanding the separation between Azure Policy and Azure RBAC/access policies.
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
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
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 →
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.