Match each VM identity concept to its best use.
Drag a concept onto its matching description — or click a concept then click the description.
Best for one VM; the identity is deleted with the VM.
Can be attached to multiple VMs.
Lets an app get Azure tokens without storing secrets.
Grants permissions to an Azure resource at a chosen scope.
Answer choices
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
System-assigned managed identity: Tied to the VM lifecycle, automatically created and deleted with the VM, best for accessing Azure resources without managing credentials.
Managed identities (system or user-assigned) eliminate credential management; Azure AD app identity is for custom apps; IMDS provides tokens; role assignments grant access to resources.
Answer analysis
For each option: why learners choose it and why it is or isn't the right answer here.
System-assigned managed identity: Tied to the VM lifecycle, automatically created and deleted with the VM, best for accessing Azure resources without managing credentials.
Why this is correct
A system-assigned managed identity is intrinsically linked to the VM's lifecycle: it is provisioned when the VM is created and automatically deleted when the VM is deleted. This identity is then granted role-based access control (RBAC) permissions to Azure resources, allowing the VM to authenticate without any credential storage or rotation management. Its primary advantage is zero administrative overhead for credential management, making it ideal for a single workload running on one VM that needs straightforward access to Azure services.
System-assigned managed identity: Best when a pre-provisioned identity is needed before the VM is created, or the identity must be assigned to multiple resources.
Why it's wrong here
This statement is incorrect because it describes the characteristics of a user-assigned managed identity, not a system-assigned one. A system-assigned identity cannot be pre-provisioned before the VM exists, as it is created only when the VM is provisioned. Furthermore, it is tied to that specific VM and cannot be shared or assigned to multiple resources; each VM gets its own unique system-assigned identity. Therefore, the stated use case—requiring a pre-existing identity or one that spans multiple resources—is exactly the scenario where a user-assigned identity is the correct choice.
User-assigned managed identity: Standalone identity that can be assigned to multiple VMs or other Azure resources, best when the identity must exist before resources or be reused.
Why this is correct
A user-assigned managed identity is created as a standalone Azure resource, independent of any VM lifecycle. Because it is a separate resource, it can be created in advance and then assigned to one or more VMs (or other Azure resources) at any time. This makes it the right choice when the identity must exist before the resource is deployed, or when the same identity must be reused across multiple resources to avoid managing separate identities. Its lifecycle is managed independently, so it persists even after the VMs using it are deleted.
User-assigned managed identity: Automatically created and deleted with the VM, best for a single VM requiring access to Azure resources.
Why it's wrong here
This statement is false because it conflates user-assigned managed identities with system-assigned managed identities. A user-assigned identity is not automatically created or deleted when a VM is created or deleted; it is an independent resource that must be explicitly provisioned and assigned. It is not limited to a single VM either—the same user-assigned identity can be assigned to multiple VMs and other Azure resources. The scenario described (automatically generated and deleted with the VM) applies to system-assigned identities, which are tied to a single VM's lifecycle.
Azure AD application (service principal): Used by custom applications that need their own identity to authenticate to Azure services, not tied to VM lifecycle.
Why this is correct
An Azure AD application (service principal) is a dedicated application identity in Microsoft Entra ID that is used by custom applications, daemon processes, or CI/CD pipelines to authenticate to Azure services. Unlike managed identities, this identity is not tied to a VM's lifecycle; it exists independently and has its own configured credentials (such as client secrets or certificates). It is the appropriate choice when the application itself needs to authenticate—often from outside an Azure VM—and requires fine-grained control over credential rotation and permissions, rather than relying on an automatically managed identity.
Go deeper
About these practice questions
One of 1,049 original AZ-104 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
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.