Manage Azure Identities and Governance →hardMultiple ChoiceObjective-mapped

AZ-104 Manage Azure Identities and Governance Practice Question

Exhibit

Bicep snippet:
resource vm 'Microsoft.Compute/virtualMachines@2023-09-01' = {
  name: 'appvm01'
  location: resourceGroup().location
  identity: {
    type: 'SystemAssigned'
  }
  properties: {
    hardwareProfile: {
      vmSize: 'Standard_D2s_v5'
    }
    osProfile: {
      computerName: 'appvm01'
    }
  }
}

Operational note:
- The VM is rebuilt every month from source control.
- The workload must read secrets from Key Vault and upload logs to Blob Storage.
- Recreating the VM must not require new role assignments for the workload identity.

Based on the exhibit, which change should the administrator make so the application identity remains stable across VM redeployments without reapplying RBAC assignments?

⚠ Common exam trap

Many exam-takers confuse system-assigned and user-assigned managed identities, assuming both persist across VM redeployments, but only user-assigned identities survive VM deletion because they are separate Azure resources.

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 and attach it to the VM template.

A user-assigned managed identity is decoupled from the VM lifecycle, so it persists independently of VM redeployments. By attaching the same user-assigned identity to the new VM instance, the application retains its Azure AD object ID and all existing RBAC role assignments remain valid without requiring reapplication.

Answer analysis

Option-by-option breakdown

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

✗
Keep the system-assigned identity and reapply the same RBAC roles after each rebuild.
Why it's wrong here
A system-assigned managed identity is tied to the lifecycle of the VM; when the VM is deleted, the identity is also deleted, and a new VM gets a brand-new system-assigned identity with a different object ID. That means you must locate and delete the old RBAC role assignments and reapply the same roles to the new identity every time the VM is rebuilt, which is operationally tedious and error-prone. This does not provide a stable identity across redeployments, so it is not a durable solution for automated rebuilds.
When this WOULD be correct
If the question asked for a solution that automatically reapplies RBAC roles after each rebuild (e.g., via automation scripts), keeping the system-assigned identity and reapplying roles could be acceptable, though not ideal.
✓
Create a user-assigned managed identity and attach it to the VM template.
Why this is correct
A user-assigned managed identity is an Azure AD identity that exists as a standalone Azure resource, independent of any VM's lifecycle. Because the identity object ID remains stable across VM deletion and redeployment, you can assign RBAC roles to it once and attach the same identity to the VM template, ensuring the rebuilt VM automatically inherits the same Azure permissions. This is the correct approach for a workload that must be repeatedly rebuilt without manual RBAC reconfiguration.
✗
Store a local administrator password in Key Vault and use it for Azure resource access.
Why it's wrong here
Storing the local administrator password in Key Vault only provides the credentials needed to sign in to the VM's operating system, not for the VM to authenticate to Azure control plane services like Key Vault or Storage. When the VM tries to retrieve that password from Key Vault, it must first prove its identity to Azure AD—which requires a managed identity or service principal—so using a stored password creates a circular dependency and does not grant any RBAC or Azure resource access.
✗
Replace the identity with a shared access signature so the VM can authenticate to Azure services.
Why it's wrong here
A shared access signature (SAS) is not an identity—it is a time-limited, resource-specific token that grants access to a particular storage account or container. A SAS cannot be used to authenticate to Azure AD, cannot be assigned RBAC roles, and does not allow the VM to access other services such as Key Vault; it is only a scoped credential for specific storage operations. Replacing the VM's identity with a SAS would break authentication to other Azure services and is not a general-purpose solution for Azure resource access.
When this WOULD be correct
When the question asks for a method to grant a client application time-limited access to a specific Azure Storage blob or container without exposing the storage account key, and the access does not need to persist across VM redeployments or involve RBAC.

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 and attach it to the VM template.Correct answer▾

Why this is correct

A user-assigned managed identity is an Azure AD identity that exists as a standalone Azure resource, independent of any VM's lifecycle. Because the identity object ID remains stable across VM deletion and redeployment, you can assign RBAC roles to it once and attach the same identity to the VM template, ensuring the rebuilt VM automatically inherits the same Azure permissions. This is the correct approach for a workload that must be repeatedly rebuilt without manual RBAC reconfiguration.

✗Keep the system-assigned identity and reapply the same RBAC roles after each rebuild.Wrong answer — click to see why▾

Why this is wrong here

System-assigned identity is tied to the VM lifecycle; redeploying the VM creates a new identity, requiring RBAC reassignment. This does not keep the identity stable.

★ When this WOULD be the correct answer

If the question asked for a solution that automatically reapplies RBAC roles after each rebuild (e.g., via automation scripts), keeping the system-assigned identity and reapplying roles could be acceptable, though not ideal.

Why candidates choose this

Candidates may think system-assigned identity is simpler and that reapplying roles is a minor overhead, overlooking that the identity itself changes on redeployment.

✗Replace the identity with a shared access signature so the VM can authenticate to Azure services.Wrong answer — click to see why▾

Why this is wrong here

A shared access signature (SAS) is used for delegated access to specific Azure storage resources, not for VM identity. It cannot provide a stable application identity across VM redeployments and does not support RBAC assignments.

★ When this WOULD be the correct answer

When the question asks for a method to grant a client application time-limited access to a specific Azure Storage blob or container without exposing the storage account key, and the access does not need to persist across VM redeployments or involve RBAC.

Why candidates choose this

Candidates may confuse SAS with managed identities because both provide authentication without storing credentials, but SAS is for storage access only and lacks the identity stability and RBAC integration required for this scenario.

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

Model	Acronym	Who Controls Access?	Best For
Discretionary Access Control	DAC	Resource owner	Small teams, file shares
Mandatory Access Control	MAC	System / security labels	Classified govt / military
Role-Based Access Control	RBAC	Administrator (via roles)	Enterprise environments
Attribute-Based Access Control	ABAC	Policy engine (user + resource attributes)	Fine-grained, dynamic policies
Rule-Based Access Control	RuBAC	System rules / ACLs	Firewall rules, network ACLs

Go deeper