User-Assigned Managed Identity for Automation Account Recreation
An Azure Automation account runs PowerShell runbooks that must authenticate to Azure resources without embedded secrets. The automation account is recreated periodically during deployment, and the identity must continue to work after recreation without reissuing credentials. Which identity should you use?
Quick Answer
The answer is a user-assigned managed identity for automation account recreation because this identity exists as a standalone Azure resource independent of the Automation account’s lifecycle. When the Automation account is deleted and recreated during deployment, the user-assigned managed identity persists and can simply be reassigned to the new account, allowing runbooks to continue authenticating without reissuing credentials or embedding secrets. On the AZ-104 exam, this scenario tests your understanding of managed identity types and their lifecycle dependencies—a common trap is choosing system-assigned managed identity, which is deleted along with the Automation account and forces credential re-creation. Remember the memory tip: “User-assigned is reusable; system-assigned is disposable.” This distinction is critical for maintaining seamless authentication in automated deployment pipelines.
⚠ Common exam trap
It's easy for candidates to assume a system-assigned managed identity is simpler and sufficient, but they overlook that it is deleted with the resource, making it unsuitable for scenarios where the resource is recreated and identity continuity is required.
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
✓
A user-assigned managed identity.
A user-assigned managed identity (B) is the correct choice because it is an independent Azure resource that persists even when the Automation account is recreated. Unlike a system-assigned managed identity, which is tied to the lifecycle of the Automation account and is deleted when the account is deleted, a user-assigned managed identity can be reassigned to the new Automation account after recreation without requiring new credentials. This allows the runbooks to authenticate seamlessly using the same identity, avoiding embedded 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.
- ✗
A system-assigned managed identity.
Why it's wrong here
A system-assigned managed identity is tied to the automation account's lifecycle, so recreating the account destroys the identity and its role assignments, breaking authentication. A user-assigned managed identity persists independently and would be correct here.
When this WOULD be correct
A system-assigned managed identity is correct when the Automation account is created once and never recreated, and you want the identity to be automatically deleted with the resource to avoid orphaned identities.
- ✓
A user-assigned managed identity.
Why this is correct
A user-assigned managed identity exists as a standalone Azure resource, so its object ID and role assignments survive the automation account's deletion and recreation. Reattaching the same identity restores access without reissuing credentials, satisfying the stem's requirement that authentication persist across periodic redeployment.
- ✗
A service principal with a client secret stored in Key Vault.
Why it's wrong here
A service principal with a client secret stored in Key Vault still relies on a credential that must be reissued or rotated, contradicting the no-reissue requirement. It would be correct when workload identity federation is unavailable and secret rotation is managed.
When this WOULD be correct
A service principal with a client secret stored in Key Vault would be correct in a scenario where the automation account is not recreated, and you need to authenticate to external services or resources that do not support managed identities, while securely storing the secret in Key Vault.
- ✗
A shared access signature token.
Why it's wrong here
A shared access signature token is a time-limited delegated credential for storage data-plane access, so it expires and cannot authenticate runbooks to Azure Resource Manager. It would be correct for granting temporary scoped access to blobs, queues or files.
When this WOULD be correct
A question asking for a method to grant time-limited access to a specific Azure Storage blob or container for a download operation, where the access must be revocable and scoped to that resource only, would make a SAS token the correct answer.
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.
✓A user-assigned managed identity.Correct answer▾
Why this is correct
A user-assigned managed identity exists as a standalone Azure resource, so its object ID and role assignments survive the automation account's deletion and recreation. Reattaching the same identity restores access without reissuing credentials, satisfying the stem's requirement that authentication persist across periodic redeployment.
✗A system-assigned managed identity.Wrong answer — click to see why▾
Why this is wrong here
A system-assigned managed identity is tied to the lifecycle of the Automation account; when the account is recreated, a new identity is created, breaking the association with existing role assignments and requiring reassignment.
★ When this WOULD be the correct answer
A system-assigned managed identity is correct when the Automation account is created once and never recreated, and you want the identity to be automatically deleted with the resource to avoid orphaned identities.
Why candidates choose this
Candidates may think system-assigned is simpler and automatically managed, overlooking the requirement that the identity must persist across account recreation without manual intervention.
✗A service principal with a client secret stored in Key Vault.Wrong answer — click to see why▾
Why this is wrong here
The question requires that the identity continue to work after the automation account is recreated without reissuing credentials. A service principal with a client secret stored in Key Vault would require reissuing the secret or updating the runbook's reference after recreation, violating the 'without reissuing credentials' constraint.
★ When this WOULD be the correct answer
A service principal with a client secret stored in Key Vault would be correct in a scenario where the automation account is not recreated, and you need to authenticate to external services or resources that do not support managed identities, while securely storing the secret in Key Vault.
Why candidates choose this
Candidates may think that using a service principal with Key Vault is a secure and flexible authentication method, and they might overlook the requirement that the identity must survive recreation without reissuing credentials.
✗A shared access signature token.Wrong answer — click to see why▾
Why this is wrong here
A shared access signature (SAS) token is used for delegated access to Azure Storage resources, not for authenticating runbooks to Azure resources in general. It does not support the identity lifecycle requirement of surviving Automation account recreation without reissuing credentials.
★ When this WOULD be the correct answer
A question asking for a method to grant time-limited access to a specific Azure Storage blob or container for a download operation, where the access must be revocable and scoped to that resource only, would make a SAS token the correct answer.
Why candidates choose this
Candidates may confuse SAS tokens with managed identities because both can provide access without embedding secrets, but SAS tokens are limited to Storage and are not identities that can be reassigned after resource recreation.
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
Storage Account Failover and RA-GZRS
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.
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 Microsoft Entra ID authentication without storing credentials.
About these practice questions
Courseiva writes every AZ-104 question from scratch — 1,053 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. 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. 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.
hard- ✓ A.Use a user-assigned managed identity so the identity is independent of the Automation account lifecycle.
- ✓ B.Grant the managed identity the required Azure RBAC roles on the target resources or resource groups.
- C.Use a service principal with a client secret stored in an encrypted Automation variable.
- D.Use a system-assigned managed identity attached to the Automation account because it is always reusable after recreation.
- E.Store a storage account key in a runbook asset and retrieve it at runtime.
Why A: 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.
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.