AZ-104 Manage Azure Identities and Governance Practice Question
An Azure Automation account is recreated periodically during a migration project. Runbooks must authenticate to Azure resources without embedded secrets, and the identity must continue to work after the account is rebuilt. Which two choices should you make? Select two.
⚠ Common exam trap
Watch out — candidates often assume a system-assigned managed identity is reusable after account recreation, but they fail to recognize that its object ID changes upon deletion and recreation, breaking existing RBAC assignments.
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
✓
Use a user-assigned managed identity so the identity is independent of the Automation account lifecycle.
A user-assigned managed identity exists as a standalone Azure resource independent of the Automation account's lifecycle. When the Automation account is recreated, you can reassign the same user-assigned managed identity to the new account, preserving the identity's object ID and its RBAC role assignments. This ensures that runbooks can authenticate without embedded secrets and continue to work seamlessly after the account is rebuilt.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Use a user-assigned managed identity so the identity is independent of the Automation account lifecycle.
Why this is correct
A user-assigned managed identity is not tied to one specific Automation account instance. That makes it resilient when the account is recreated during migration or recovery activities. It also avoids storing passwords or secrets in the runbook, which satisfies the secure automation requirement.
- ✓
Grant the managed identity the required Azure RBAC roles on the target resources or resource groups.
Why this is correct
An identity without permissions still cannot perform the work, so role assignment is required. Granting only the needed RBAC roles keeps the solution secure and operational. This is the proper way to authorize a secretless automation identity in Azure.
- ✗
Use a service principal with a client secret stored in an encrypted Automation variable.
Why it's wrong here
A service principal with a client secret can technically authenticate a runbook, but storing that secret in an encrypted Automation variable merely shifts the problem: the secret is still persisted in the Automation account and must be retrieved at runtime, which means it can be exposed through logs, memory dumps, or unauthorized runbook access. The encryption protects the variable at rest, but it does not remove the operational burden of securely managing, rotating, and monitoring a long-lived credential, and it conflicts with the stated requirement to avoid embedded credentials. Therefore, this option does not meet the security goal, even though it is functionally viable.
When this WOULD be correct
In a scenario where the Automation account is not recreated, and you need to authenticate to Azure resources using a service principal with a client secret that is securely stored and rotated, this option would be correct. For example, when using a long-lived Automation account with regular secret rotation, storing the secret in an encrypted variable is a valid approach.
- ✗
Use a system-assigned managed identity attached to the Automation account because it is always reusable after recreation.
Why it's wrong here
A system-assigned managed identity is lifecycle-bound to the resource that owns it. If the Automation account is rebuilt, the identity changes as well, which breaks the requirement for continuity across recreation. That makes this option unsuitable here.
When this WOULD be correct
If the Automation account is never deleted or recreated, or if the question states that the identity must be automatically managed and deleted with the account, then a system-assigned managed identity would be the correct choice.
- ✗
Store a storage account key in a runbook asset and retrieve it at runtime.
Why it's wrong here
A storage account key is a secret and behaves like a password. Storing it in a runbook asset still leaves you managing credentials, rotation, and exposure risk. This directly conflicts with the requirement to avoid embedded secrets.
When this WOULD be correct
If the question required authenticating to Azure Storage specifically and allowed using a shared key, and the Automation account was not being recreated (so the stored key would remain valid), then storing a storage account key in a runbook asset could be acceptable.
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.
✓Use a user-assigned managed identity so the identity is independent of the Automation account lifecycle.Correct answer▾
Why this is correct
A user-assigned managed identity is not tied to one specific Automation account instance. That makes it resilient when the account is recreated during migration or recovery activities. It also avoids storing passwords or secrets in the runbook, which satisfies the secure automation requirement.
✗Use a service principal with a client secret stored in an encrypted Automation variable.Wrong answer — click to see why▾
Why this is wrong here
The question requires the identity to continue working after the Automation account is recreated. A service principal with a client secret stored in an encrypted variable still ties the secret to the account lifecycle; if the account is recreated, the variable is lost, and the secret must be re-created. Additionally, embedded secrets are explicitly disallowed.
★ When this WOULD be the correct answer
In a scenario where the Automation account is not recreated, and you need to authenticate to Azure resources using a service principal with a client secret that is securely stored and rotated, this option would be correct. For example, when using a long-lived Automation account with regular secret rotation, storing the secret in an encrypted variable is a valid approach.
Why candidates choose this
Candidates may think that storing the secret in an encrypted variable is secure and independent, but they overlook that the variable is tied to the Automation account and would be lost upon recreation, violating the 'continue to work after rebuild' requirement.
✗Use a system-assigned managed identity attached to the Automation account because it is always reusable after recreation.Wrong answer — click to see why▾
Why this is wrong here
A system-assigned managed identity is tied to the Automation account lifecycle; when the account is deleted and recreated, the identity is also deleted and recreated with a new principal ID, breaking RBAC role assignments that were made to the old identity.
★ When this WOULD be the correct answer
If the Automation account is never deleted or recreated, or if the question states that the identity must be automatically managed and deleted with the account, then a system-assigned managed identity would be the correct choice.
Why candidates choose this
Candidates may assume that system-assigned managed identities are automatically reusable after recreation because they are managed by Azure, but they overlook that the identity's object ID changes upon recreation, invalidating existing role assignments.
✗Store a storage account key in a runbook asset and retrieve it at runtime.Wrong answer — click to see why▾
Why this is wrong here
Storage account keys are long-lived secrets that must be managed and rotated, violating the requirement to avoid embedded secrets. They also do not automatically work after the Automation account is recreated, as the key would need to be re-stored in the new account.
★ When this WOULD be the correct answer
If the question required authenticating to Azure Storage specifically and allowed using a shared key, and the Automation account was not being recreated (so the stored key would remain valid), then storing a storage account key in a runbook asset could be acceptable.
Why candidates choose this
Candidates may think storing a key in an Automation variable is a secure way to avoid hardcoding secrets, but they overlook that the key itself is a static secret that must be managed and does not support the identity lifecycle requirement.
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
Related to this question
Learn chapter
Privileged Identity Management (PIM)
Key term
User-assigned managed identity
A user-assigned managed identity is a standalone Azure identity that can be assigned to one or more Azure resources, enabling them to authenticate to other services without storing credentials.
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 →
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.