AZ-104 Manage Azure Identities and Governance Practice Question
Network Topology
Based on the exhibit, an Azure VM must read secrets from Azure Key Vault during startup. No passwords, certificates, or client secrets may be stored on the VM. What should you configure?
⚠ Common exam trap
Many exam-takers confuse managed identities with service principals or shared access signatures, mistakenly thinking that a client secret or SAS token is needed for authentication, when in fact managed identities eliminate the need for any stored credentials.
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
✓
Enable a system-assigned managed identity on the VM.
A system-assigned managed identity is the correct choice because it is tied directly to the VM's lifecycle, requires no credential storage, and can authenticate to Azure Key Vault without any secrets stored on the VM. When enabled, Azure automatically creates a service principal in Azure AD for the VM, and the VM can request an access token from the Azure Instance Metadata Service (IMDS) endpoint (169.254.169.254) to access Key Vault secrets. This satisfies the requirement of no passwords, certificates, or client secrets 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.
- ✗
Assign a user-assigned managed identity to the VM so it can be shared later.
Why it's wrong here
A user-assigned managed identity does provide a valid managed identity for the VM, but it is an over-engineered solution when only one VM needs Key Vault access. It requires you to separately create, manage, and delete the identity resource, and it is not automatically tied to the VM's lifecycle, meaning it can persist after the VM is removed. The system-assigned identity, by contrast, is created and deleted with the VM, making it the simplest and most direct fit for a single-VM scenario. Sharing is only a hypothetical benefit here, not an actual requirement.
When this WOULD be correct
A user-assigned managed identity would be correct in a scenario where multiple Azure resources (e.g., VMs, App Services) need to share the same identity to access the same Key Vault secrets, and you want to manage the identity independently from the resource lifecycle.
- ✓
Enable a system-assigned managed identity on the VM.
Why this is correct
A system-assigned managed identity is the best fit because it gives the VM an Azure identity without storing secrets on the machine. It is tied directly to that VM, so it is easy to create, use, and automatically remove when the VM is deleted. This matches the requirement for startup access to Key Vault and avoids any embedded credentials.
- ✗
Create a service principal and store its client secret in the VM configuration.
Why it's wrong here
Creating a service principal and embedding its client secret in the VM configuration means the secret exists on the VM's disk or environment, directly violating the requirement to avoid storing credentials on the machine. The secret would also require manual rotation and secure delivery, and if the VM is compromised, the service principal's entire token scope is exposed. Unlike a system-assigned managed identity, where Azure manages the credential lifecycle, a client secret is a long-lived static credential that creates ongoing operational risk.
When this WOULD be correct
If the VM needs to authenticate to an external service that does not support managed identities (e.g., a third-party API), and the client secret can be securely stored in Azure Key Vault and retrieved at runtime without persisting on the VM, then using a service principal with a secret retrieved from Key Vault would be correct.
- ✗
Use a shared access signature in the startup script to authenticate to Key Vault.
Why it's wrong here
A shared access signature (SAS) is a delegated credential for Azure Storage resources, not an authentication mechanism for Azure Key Vault. Key Vault authenticates requests via Azure AD tokens, so a SAS token in a startup script would be ignored and cannot grant access to secrets. Even if it could be used, placing a time-bound SAS in a script still embeds a secret on the VM and forces you to handle expiry and rotation, which is exactly what the managed identity approach avoids.
When this WOULD be correct
A question asks how to grant a client application temporary, restricted access to a specific Azure Storage blob or container without exposing the storage account key. In that scenario, using a SAS token in the application code or startup script would be correct.
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.
✓Enable a system-assigned managed identity on the VM.Correct answer▾
Why this is correct
A system-assigned managed identity is the best fit because it gives the VM an Azure identity without storing secrets on the machine. It is tied directly to that VM, so it is easy to create, use, and automatically remove when the VM is deleted. This matches the requirement for startup access to Key Vault and avoids any embedded credentials.
✗Assign a user-assigned managed identity to the VM so it can be shared later.Wrong answer — click to see why▾
Why this is wrong here
The question requires that no secrets be stored on the VM, and a user-assigned managed identity does not inherently prevent secret storage; however, the key constraint is that the identity must be available during startup without manual configuration. A system-assigned identity is automatically created and tied to the VM's lifecycle, making it the simplest choice for a single VM that needs to access Key Vault at startup without managing secrets.
★ When this WOULD be the correct answer
A user-assigned managed identity would be correct in a scenario where multiple Azure resources (e.g., VMs, App Services) need to share the same identity to access the same Key Vault secrets, and you want to manage the identity independently from the resource lifecycle.
Why candidates choose this
Candidates may think a user-assigned identity is more flexible or reusable, but they overlook that the question's specific requirement (no secrets stored on VM) is already satisfied by any managed identity, and the system-assigned identity is simpler for a single VM.
✗Create a service principal and store its client secret in the VM configuration.Wrong answer — click to see why▾
Why this is wrong here
Storing a client secret in the VM configuration violates the requirement that no passwords, certificates, or client secrets may be stored on the VM. Managed identities eliminate the need for secrets entirely.
★ When this WOULD be the correct answer
If the VM needs to authenticate to an external service that does not support managed identities (e.g., a third-party API), and the client secret can be securely stored in Azure Key Vault and retrieved at runtime without persisting on the VM, then using a service principal with a secret retrieved from Key Vault would be correct.
Why candidates choose this
Candidates may be familiar with service principals for authentication and think they are required for Key Vault access, not realizing that managed identities provide a simpler, secretless alternative for Azure resources.
✗Use a shared access signature in the startup script to authenticate to Key Vault.Wrong answer — click to see why▾
Why this is wrong here
A shared access signature (SAS) is used for delegated access to Azure Storage, not for authenticating to Key Vault. Key Vault does not support SAS tokens for authentication.
★ When this WOULD be the correct answer
A question asks how to grant a client application temporary, restricted access to a specific Azure Storage blob or container without exposing the storage account key. In that scenario, using a SAS token in the application code or startup script would be correct.
Why candidates choose this
Candidates may confuse SAS with a secure token or think it can be used generically for any Azure service authentication, not realizing it is specific to Storage.
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
Access token
A digital key that a computer system gives you to prove your identity and grant you permission to access specific resources or perform actions.
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
This AZ-104 question is part of Courseiva's 1,049-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
Same concept, more angles
3 more ways this is tested on AZ-104
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. A web app running on an Azure VM must read files from Azure Blob Storage without storing any passwords, secrets, or access keys on the VM. The identity should be tied to that VM and removed automatically if the VM is deleted. What should you enable?
easy- ✓ A.A system-assigned managed identity
- B.A shared storage account key in the application settings
- C.A user account with a local password on the VM
- D.A service endpoint on the VM subnet
Why A: A system-assigned managed identity is the correct choice because it creates an identity in Azure AD that is tied directly to the lifecycle of the VM. When the VM is deleted, the identity is automatically removed. The VM can use this identity to authenticate to Azure Blob Storage via Azure AD without storing any credentials on the VM, using the Azure Instance Metadata Service (IMDS) to obtain tokens.
Variation 2. A VM-hosted app must read blobs from Azure Storage without storing a shared key, SAS token, or password. Which two configuration steps should the administrator take? Select two.
easy- ✓ A.Enable a system-assigned managed identity on the VM.
- ✓ B.Assign the Storage Blob Data Reader role to that identity on the storage account.
- C.Store the storage account access key in the app configuration.
- D.Generate a SAS token and embed it in the application code.
- E.Move the VM into a different subnet.
Why A: A system-assigned managed identity on the VM allows Azure to automatically manage a service principal for the VM, eliminating the need for any stored credentials. By assigning the Storage Blob Data Reader role to that identity on the storage account, the VM can authenticate to Azure Storage using Azure AD tokens obtained via the Azure Instance Metadata Service (IMDS) endpoint, without ever storing a shared key, SAS token, or password.
Variation 3. A single Azure virtual machine must read blobs from a storage account without storing any passwords, keys, or connection strings. The identity should be removed automatically if the VM is deleted. Which option should you use?
easy- A.Storage account access key, because it is the simplest authentication method.
- ✓ B.System-assigned managed identity, because it is tied to that VM.
- C.Shared access signature, because it always removes the need for identity management.
- D.User-assigned managed identity, because it is deleted automatically with the VM.
Why B: System-assigned managed identity is tied directly to the lifecycle of the Azure VM. When the VM is deleted, the identity is automatically removed. It allows the VM to authenticate to Azure Storage without storing any credentials, using Azure AD tokens obtained via the Azure Instance Metadata Service (IMDS).
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.