AZ-104 Manage Azure Identities and Governance Practice Question
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.
⚠ Common exam trap
It's easy for candidates to confuse system-assigned managed identities with user-assigned ones, mistakenly thinking a system-assigned identity can be reused across VM rebuilds, when in fact it is deleted when the VM is deleted and cannot be transferred.
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.
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.
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.
Why this is correct
A user-assigned managed identity is created as a standalone Azure resource in Azure AD, making it independent of any specific VM. Because it is not tied to a VM's lifecycle, it persists even after VMs are deleted or rebuilt, and the same identity can be reassigned to replacement VMs. This provides a stable, distributed identity for the scheduled script, and Azure automatically rotates its backing credentials, eliminating the need to store any secrets on the VMs.
- ✓
Assign that user-assigned identity to each VM that runs the script.
Why this is correct
After creating the user-assigned identity, you must explicitly attach it to every VM that executes the scheduled script, either during provisioning or by updating the VM. This assignment makes the identity available through the VM's managed identity endpoint (IMDS), allowing the script to obtain Azure AD tokens without embedding credentials. When a VM is rebuilt, you simply reattach the same user-assigned identity, ensuring the script retains the exact same permissions and identity across all instances.
- ✗
Use a system-assigned managed identity on one VM and clone it.
Why it's wrong here
A system-assigned managed identity is intrinsically linked to the lifecycle of the specific VM it is enabled on—when that VM is deleted, the identity is destroyed. There is no way to 'clone' it because each system-assigned identity is a unique service principal bound to one resource. Even if you deployed the same script to multiple VMs, each would have a distinct identity, which complicates permissions and breaks when those VMs are replaced; a user-assigned identity avoids this by design.
When this WOULD be correct
If the question required an identity that is automatically tied to a single VM's lifecycle and no cross-VM consistency was needed, using a system-assigned managed identity would be correct.
- ✗
Store a service principal secret in the script configuration.
Why it's wrong here
Storing a service principal secret in script configuration means placing a long-lived credential on the disk of each VM, which not only violates the best practice of avoiding secrets in code/config but also creates a significant security risk if a VM image is compromised. Since VMs are rebuilt, you would have to ensure the secret is securely injected into each new instance, adding manual, error-prone secret management. Managed identities solve this by using short-lived tokens acquired via ARM, never requiring the script to know or handle any secret material.
When this WOULD be correct
When an application needs to authenticate to Azure services using a service principal, and the secret can be securely stored in Azure Key Vault or environment variables, not on disk.
- ✗
Use a shared access signature to authenticate to Azure Resource Manager.
Why it's wrong here
Shared access signature (SAS) tokens are designed exclusively for granting delegated access to Azure Storage resources such as blobs, queues, or files, and they cannot be used to authenticate to the Azure Resource Manager API for control-plane operations. The scheduled script, as described, is presumably interacting with ARM to manage Azure resources, which requires an Azure AD–issued bearer token, not a SAS. This approach would fail outright for the stated purpose and is unrelated to identity management for VMs.
When this WOULD be correct
A question asks for a way to grant a client application time-limited access to a specific Azure Storage blob without exposing the storage account key. Using a SAS token with the appropriate permissions and expiry would be the correct answer.
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.Correct answer▾
Why this is correct
A user-assigned managed identity is created as a standalone Azure resource in Azure AD, making it independent of any specific VM. Because it is not tied to a VM's lifecycle, it persists even after VMs are deleted or rebuilt, and the same identity can be reassigned to replacement VMs. This provides a stable, distributed identity for the scheduled script, and Azure automatically rotates its backing credentials, eliminating the need to store any secrets on the VMs.
✗Use a system-assigned managed identity on one VM and clone it.Wrong answer — click to see why▾
Why this is wrong here
System-assigned managed identities are tied to a specific VM instance and cannot be cloned or reused across rebuilt VMs; each new VM would get a new identity, breaking the requirement for a consistent identity.
★ When this WOULD be the correct answer
If the question required an identity that is automatically tied to a single VM's lifecycle and no cross-VM consistency was needed, using a system-assigned managed identity would be correct.
Why candidates choose this
Candidates may think system-assigned identities can be 'cloned' like a VM image, not realizing they are unique per resource and cannot be transferred.
✗Store a service principal secret in the script configuration.Wrong answer — click to see why▾
Why this is wrong here
Storing a service principal secret in the script configuration violates the requirement of not storing secrets on disk. Managed identities eliminate the need for secrets entirely.
★ When this WOULD be the correct answer
When an application needs to authenticate to Azure services using a service principal, and the secret can be securely stored in Azure Key Vault or environment variables, not on disk.
Why candidates choose this
Candidates may be familiar with service principals for authentication and overlook the managed identity alternative, or they may not fully understand that managed identities are the recommended approach for Azure VMs.
✗Use a shared access signature to authenticate to Azure Resource Manager.Wrong answer — click to see why▾
Why this is wrong here
Shared access signatures (SAS) are used for delegated access to Azure Storage resources, not for authenticating to Azure Resource Manager or providing an identity for Azure VMs. They cannot serve as a consistent identity across VM rebuilds.
★ When this WOULD be the correct answer
A question asks for a way to grant a client application time-limited access to a specific Azure Storage blob without exposing the storage account key. Using a SAS token with the appropriate permissions and expiry would be the correct answer.
Why candidates choose this
Candidates may confuse SAS with a general authentication mechanism for Azure services, or think it can be used as an identity token for VMs, because SAS tokens are commonly used for secure access to resources without hardcoding keys.
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
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.