AZ-104 Manage Azure Identities and Governance Practice Question
An Azure application and an Azure Automation account need Azure access without any stored secrets. The same identity should be reusable and should not require manual secret rotation. Which two identity choices meet the requirement? Select two.
⚠ Common exam trap
Candidates often confuse service principals with managed identities, thinking that storing a client secret in an app setting or Key Vault is acceptable, but the question explicitly requires 'no stored secrets' and 'no manual secret rotation,' which only managed identities satisfy.
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 attached to the resource that needs access.
System-assigned managed identity (Option A) is correct because it is automatically created and tied to a specific Azure resource, such as a virtual machine or App Service, and provides an Azure AD identity that can be used to authenticate to any service supporting Azure AD authentication without storing any secrets. The identity is managed by Azure, eliminating the need for manual secret rotation, and it is automatically deleted when the resource is deleted, ensuring no orphaned secrets.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
System-assigned managed identity attached to the resource that needs access.
Why this is correct
A system-assigned managed identity is created directly with the Azure resource and has the same lifecycle, so when the resource is deleted, the identity is deleted too. It is automatically rotated and requires no secret management, making it the most straightforward way for a single resource like an application or an automation account to authenticate to Azure AD and access other Azure resources. This identity is bound exclusively to that one resource and cannot be shared.
- ✓
User-assigned managed identity that can be attached to multiple Azure resources.
Why this is correct
A user-assigned managed identity exists as a standalone Azure AD identity that can be assigned to multiple Azure resources, which is ideal when both an application and an automation account need to share the same identity. It remains independently manageable and persists beyond the lifetime of any assigned resource, allowing centralized control of permissions. However, because it is not automatically tied to a resource's lifecycle, it requires explicit cleanup and assignment management.
- ✗
Service principal with a client secret stored in an app setting.
Why it's wrong here
A service principal with a client secret stored in an app setting is a legacy pattern where the client secret is a long-lived credential that must be carefully stored, rotated, and protected from leaking. If the secret is compromised, an attacker can impersonate the service principal until it is rotated, and the secret is often checked into code or configuration files. Managed identities avoid this entire class of problems by automatically rotating the credential and never requiring the secret to be stored in application settings.
When this WOULD be correct
A question that asks for an identity solution for an Azure resource that needs to access external APIs or services that do not support managed identities, and where secret rotation can be automated via Key Vault or lifecycle policies.
- ✗
Shared administrator username and password stored in a Key Vault secret.
Why it's wrong here
Storing a shared administrator username and password in Key Vault still relies on a password-based credential, which is subject to theft, brute-force attacks, and the need for periodic rotation. Key Vault protects the secret at rest and in transit, but it does not eliminate the fundamental problem of managing a static, high-privilege credential. This approach also does not leverage Azure AD identity features, such as conditional access or managed identity, and the password may be exposed through logs or configuration.
When this WOULD be correct
In a scenario where an application needs to authenticate to a legacy system that only supports username/password authentication, and the organization has a policy to rotate secrets automatically via Key Vault, storing credentials in Key Vault would be correct.
- ✗
SAS token generated once and reused indefinitely by both resources.
Why it's wrong here
A SAS token, even if initially generated with broad permissions, is not an identity; it is a shared-key-style credential that grants whoever possesses it the same level of access until it expires. Reusing one indefinitely across multiple resources and automation tasks creates a long-lived static secret that is extremely difficult to revoke without regenerating and redistributing it. It also bypasses Azure AD-based access control, making it unsuitable for scenarios that require auditability and granular permission management.
When this WOULD be correct
In a scenario where an Azure Storage account needs to grant temporary, delegated access to a specific blob or container for a client application, and the access can be time-bound and permissions-limited, a SAS token would be the correct choice. For example, generating a SAS token for a web app to download a file from a private container for a limited duration.
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 identity attached to the resource that needs access.Correct answer▾
Why this is correct
A system-assigned managed identity is created directly with the Azure resource and has the same lifecycle, so when the resource is deleted, the identity is deleted too. It is automatically rotated and requires no secret management, making it the most straightforward way for a single resource like an application or an automation account to authenticate to Azure AD and access other Azure resources. This identity is bound exclusively to that one resource and cannot be shared.
✗Service principal with a client secret stored in an app setting.Wrong answer — click to see why▾
Why this is wrong here
Service principals with client secrets require manual secret rotation and storing the secret in an app setting still exposes it as a stored secret, violating the requirement of no stored secrets and no manual rotation.
★ When this WOULD be the correct answer
A question that asks for an identity solution for an Azure resource that needs to access external APIs or services that do not support managed identities, and where secret rotation can be automated via Key Vault or lifecycle policies.
Why candidates choose this
Candidates may think a service principal is the standard way to grant Azure access and that storing the secret in an app setting is secure, overlooking the 'no stored secrets' and 'no manual rotation' constraints.
✗Shared administrator username and password stored in a Key Vault secret.Wrong answer — click to see why▾
Why this is wrong here
Shared administrator username and password stored in a Key Vault secret require manual rotation and expose static credentials, violating the requirements of no stored secrets and no manual rotation.
★ When this WOULD be the correct answer
In a scenario where an application needs to authenticate to a legacy system that only supports username/password authentication, and the organization has a policy to rotate secrets automatically via Key Vault, storing credentials in Key Vault would be correct.
Why candidates choose this
Candidates may think Key Vault eliminates all security concerns, but it still stores secrets that require manual rotation unless automated, and the question explicitly forbids stored secrets and manual rotation.
✗SAS token generated once and reused indefinitely by both resources.Wrong answer — click to see why▾
Why this is wrong here
A SAS token is a shared access signature that grants time-limited access to specific resources like storage accounts. It requires manual generation, cannot be reused indefinitely without exposing the account key, and does not provide a reusable identity without stored secrets, failing the requirement of no manual secret rotation.
★ When this WOULD be the correct answer
In a scenario where an Azure Storage account needs to grant temporary, delegated access to a specific blob or container for a client application, and the access can be time-bound and permissions-limited, a SAS token would be the correct choice. For example, generating a SAS token for a web app to download a file from a private container for a limited duration.
Why candidates choose this
Candidates may think a SAS token is a 'secret-free' identity because it can be generated without storing a password, but they overlook that it still requires manual creation and rotation, and it's not a true identity but a delegation mechanism tied to the storage account key.
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
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.
Key term
Azure Automation
Azure Automation is a cloud-based service that lets you automatically create, deploy, monitor, and maintain resources in your Microsoft Azure environment using runbooks and configuration management.
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 →
Same concept, more angles
1 more way 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. Based on the exhibit, which identity should be enabled on the VM so the application can access Azure Blob Storage and the identity disappears when the VM is deleted?
medium- ✓ A.System-assigned managed identity
- B.User-assigned managed identity
- C.Storage account shared key
- D.SAS token stored in a startup script
Why A: A 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 can be granted access to Azure Blob Storage via Azure RBAC, allowing the application to authenticate without storing credentials. This matches the requirement for an identity that disappears with the VM.
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.