AZ-104 Manage Azure Identities and Governance Practice Question

Answer analysis

Option-by-option breakdown

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

• ✗

  A system-assigned managed identity on each VM.

  Why it's wrong here

  A system-assigned managed identity is born with a VM and dies with it: when the VM is deleted, the identity is automatically deleted, so if the VM is rebuilt, a brand-new identity is created and all role assignments must be reapplied. Because each VM gets its own unique system-assigned identity, the scheduled script on every VM would authenticate as a different principal, requiring separate role grants per VM; this does not provide a single shared identity that persists across VM rebuilds. While system-assigned identities avoid credential storage, they are unsuitable for a fleet of VMs that need to share one identity and survive resource lifecycle changes, which is exactly the problem a user-assigned managed identity solves.

  When this WOULD be correct

  When each VM needs a unique identity that is automatically created and deleted with the VM, and there is no requirement for the identity to persist after VM deletion.

• ✓

  A user-assigned managed identity attached to the VMs.

  Why this is correct

  A user-assigned managed identity is created as a separate Azure resource and can be attached to multiple VMs. Because it is not tied to the lifecycle of a single VM, the same identity remains available even if one VM is deleted and rebuilt, which fits the requirement for shared, durable authentication.

• ✗

  A service principal with a client secret stored in each VM.

  Why it's wrong here

  Using a service principal with a client secret stored in each VM technically authenticates to Azure AD, but it violates modern security best practices by placing a static, high-privilege credential on every disk. The secret must be securely stored, rotated periodically, and protected from theft — any compromise of one VM exposes the credential, potentially granting broad access to all resources the principal can reach. Unlike a managed identity, this approach requires manual lifecycle management and does not leverage Azure's integrated, secretless authentication model; it also fails the 'no secrets in code or VMs' pattern that managed identities are designed to eliminate, introducing unnecessary operational burden and attack surface.

  When this WOULD be correct

  When the script needs to authenticate to external services that do not support managed identities, and the administrator can securely store the client secret in Azure Key Vault with VM access via a managed identity or certificate.

• ✗

  A shared access signature stored in the VM registry.

  Why it's wrong here

  A shared access signature (SAS) grants fine-grained, time-limited access only to specific Azure Storage resources (e.g., a container, blob, or queue), not to the broader set of Azure ARM APIs or services that the scheduled script may need to authenticate against. Storing the SAS in the VM registry also introduces a credential-in-plaintext risk that can be exfiltrated, and the token expires and must be renewed manually, creating operational overhead. Moreover, if the VM is rebuilt, the registry key must be re-created, and the SAS is not an Azure identity object at all — it cannot be assigned RBAC permissions across multiple services, making it fundamentally incompatible with the requirement for durable, shared authentication.

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.

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