Courseiva
Manage Azure Identities and GovernanceeasyMultiple ChoiceObjective-mapped

AZ-104 Manage Azure Identities and Governance Practice Question

A newly created VM must read secrets from Azure Key Vault. The solution must not store credentials on the VM, and the identity should disappear automatically when the VM is deleted. What should the administrator enable?

⚠ Common exam trap

Test-takers frequently confuse user-assigned and system-assigned managed identities, assuming both are tied to the VM lifecycle, but only the system-assigned identity is automatically deleted with the VM.

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

System-assigned managed identity

A system-assigned managed identity is automatically created and tied to the lifecycle of the Azure VM. When the VM is deleted, the identity is automatically removed, satisfying the requirement that the identity disappears. This identity can be granted access to Key Vault secrets via Azure RBAC or access policies, without storing any credentials on the VM.

Answer analysis

Option-by-option breakdown

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

  • User-assigned managed identity

    Why it's wrong here

    A user-assigned managed identity is a standalone Azure resource that can be assigned to multiple VMs and continues to exist long after any one VM is deleted. That means removing the VM does not automatically remove the identity, leaving a valid security principal that might be orphaned or accidentally reused by another workload. Because the requirement implies a tightly coupled one-to-one lifecycle between the VM and its identity, the user-assigned model introduces extra management and a broader attack surface, whereas a system-assigned identity is born with the VM and dies with it.

    When this WOULD be correct

    When the requirement is to share the same identity across multiple Azure resources (e.g., multiple VMs or an App Service and a VM) and the identity must persist even after one resource is deleted, a user-assigned managed identity is the correct choice.

  • System-assigned managed identity

    Why this is correct

    A system-assigned managed identity is tied directly to one VM. Azure creates and manages the identity for that resource, so no passwords or client secrets need to be stored on the server. When the VM is deleted, the identity is removed automatically, which satisfies both security and lifecycle requirements.

  • A service principal with a stored client secret

    Why it's wrong here

    A service principal with a stored client secret fails the core requirement because the secret must reside somewhere on the VM—in a config file, environment variable, or script—creating exactly the credential-at-rest exposure the question forbids. Even if you attempt to store that secret in Key Vault, you face a bootstrap problem: how does the VM fetch the secret without already having a credential? Additionally, service principals are independent app registrations that must be manually created, rotated, and revoked, adding lifecycle overhead that a system-assigned identity avoids entirely.

  • A storage account access key

    Why it's wrong here

    A storage account access key is fundamentally unrelated to authenticating to Key Vault; Key Vault requires an Azure AD token, not a storage account key. Even if the key were somehow used, storing it on the VM would put a static secret on the server, directly violating the no-stored-secrets rule. Access keys also grant broad, long-lived access to storage data and must be manually rotated, making them a poor fit for a single VM's need to read secrets from Key Vault.

    When this WOULD be correct

    When a VM needs to access Azure Storage blobs or files using a shared key, and the key can be stored securely (e.g., in Azure Key Vault) or rotated manually, and there is no requirement for automatic identity lifecycle management.

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.

System-assigned managed identityCorrect answer

Why this is correct

A system-assigned managed identity is tied directly to one VM. Azure creates and manages the identity for that resource, so no passwords or client secrets need to be stored on the server. When the VM is deleted, the identity is removed automatically, which satisfies both security and lifecycle requirements.

User-assigned managed identityWrong answer — click to see why

Why this is wrong here

A user-assigned managed identity persists independently of the VM lifecycle; it does not disappear automatically when the VM is deleted, failing the requirement that the identity should disappear automatically.

★ When this WOULD be the correct answer

When the requirement is to share the same identity across multiple Azure resources (e.g., multiple VMs or an App Service and a VM) and the identity must persist even after one resource is deleted, a user-assigned managed identity is the correct choice.

Why candidates choose this

Candidates may confuse user-assigned and system-assigned managed identities, assuming both are managed identities and thus both meet the 'no credentials stored' requirement, overlooking the automatic lifecycle coupling of system-assigned identities.

A storage account access keyWrong answer — click to see why

Why this is wrong here

A storage account access key is a static credential that must be stored on the VM, violating the requirement to not store credentials on the VM, and it does not automatically disappear when the VM is deleted.

★ When this WOULD be the correct answer

When a VM needs to access Azure Storage blobs or files using a shared key, and the key can be stored securely (e.g., in Azure Key Vault) or rotated manually, and there is no requirement for automatic identity lifecycle management.

Why candidates choose this

Candidates may confuse storage account access keys with managed identities, thinking they provide a simple way to access Azure resources without understanding that keys are static credentials that must be stored on the VM.

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?”

Quick reference

Access Control Model Comparison

ModelAcronymWho Controls Access?Best For
Discretionary Access ControlDACResource ownerSmall teams, file shares
Mandatory Access ControlMACSystem / security labelsClassified govt / military
Role-Based Access ControlRBACAdministrator (via roles)Enterprise environments
Attribute-Based Access ControlABACPolicy engine (user + resource attributes)Fine-grained, dynamic policies
Rule-Based Access ControlRuBACSystem rules / ACLsFirewall rules, network ACLs

Go deeper

Related to this question

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 →

How Courseiva writes practice questions · Editorial policy

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.