AZ-104 Manage Azure Identities and Governance Practice Question
A build server in an on-premises datacenter must deploy ARM templates to Azure. The automation must not use a human account password, and Microsoft Entra conditional access for device sign-in is not available because the server is outside Azure. The security team allows a non-human credential but wants the strongest practical option for this scenario. What should the administrator configure?
⚠ Common exam trap
It's easy for candidates to confuse managed identities (which are Azure-only) with service principals, assuming managed identities can be used for on-premises resources, but managed identities require an Azure resource context and cannot be assigned to non-Azure machines.
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 service principal authenticated with a certificate.
A service principal authenticated with a certificate provides a non-human credential that does not require a human password and is the strongest practical option for an on-premises build server that cannot use managed identities (which are Azure-resource-scoped) or device-based conditional access. Certificate-based authentication for service principals uses asymmetric cryptography (X.509 certificates) with a private key stored securely on the build server, offering higher security than a client secret and meeting the requirement to avoid human account passwords.
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 the build server.
Why it's wrong here
A system-assigned managed identity is created and tied to a specific Azure resource, such as an Azure VM or App Service, and cannot be assigned to an on-premises build server because that server is not an Azure resource. Without an Azure resource identity, there is no way for the build server to obtain a token from the Azure Instance Metadata Service (IMDS) endpoint. The only way to use a system-assigned identity on-premises would be via Azure Arc, but that would still require the server to be enrolled as an Azure resource, which is not the case here.
When this WOULD be correct
A question where the build server is an Azure VM (e.g., Azure DevOps self-hosted agent on an Azure VM) and the requirement is to deploy ARM templates without managing credentials, with conditional access available.
- ✓
A service principal authenticated with a certificate.
Why this is correct
A certificate-based service principal is the correct choice for on-premises automation because it provides non-interactive authentication to Azure AD without storing a password in scripts or configuration files. The certificate is installed on the build server, and the service principal is assigned RBAC permissions (e.g., Contributor) on the target resource group, enabling ARM template deployments. This method is secure, supports automatic rotation, and is specifically designed for scenarios like a build server running outside Azure.
- ✗
A user-assigned managed identity shared with the build server.
Why it's wrong here
User-assigned managed identities are tied to an Azure resource (such as a VM, App Service, or Azure Arc-enabled server) and cannot be directly used by an on-premises build server that is not connected to Azure Arc. Even if the identity is 'shared', the build server has no Azure resource context to request a token from the IMDS endpoint, so authentication would fail. To use a user-assigned identity on-premises, you would need Azure Arc, but the question assumes a standard on-premises server, making this incorrect.
When this WOULD be correct
If the build server were an Azure VM (or other Azure resource) and the requirement was to deploy ARM templates without storing credentials, a system-assigned managed identity would be the correct answer, as it provides an automatically managed identity tied to that resource.
- ✗
A resource lock on the target resource group to permit template deployment.
Why it's wrong here
A resource lock on the target resource group is a governance control that prevents accidental deletion or modification of resources, but it does not authenticate the build server or grant any permissions. In fact, a resource lock (especially a ReadOnly or Delete lock) can block ARM template deployments that attempt to change or delete existing resources. Locks are purely for protection and have no role in authentication or authorization for deployments, so this option is irrelevant and incorrect.
When this WOULD be correct
An administrator needs to prevent accidental deletion of a critical resource group that contains production virtual machines. A resource lock (e.g., CanNotDelete) should be applied to the resource group to protect it from unintended changes.
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 service principal authenticated with a certificate.Correct answer▾
Why this is correct
A certificate-based service principal is the correct choice for on-premises automation because it provides non-interactive authentication to Azure AD without storing a password in scripts or configuration files. The certificate is installed on the build server, and the service principal is assigned RBAC permissions (e.g., Contributor) on the target resource group, enabling ARM template deployments. This method is secure, supports automatic rotation, and is specifically designed for scenarios like a build server running outside Azure.
✗A system-assigned managed identity on the build server.Wrong answer — click to see why▾
Why this is wrong here
Managed identities are Azure-resident and cannot be assigned to an on-premises build server; they only work for Azure resources like VMs or App Services.
★ When this WOULD be the correct answer
A question where the build server is an Azure VM (e.g., Azure DevOps self-hosted agent on an Azure VM) and the requirement is to deploy ARM templates without managing credentials, with conditional access available.
Why candidates choose this
Candidates may think managed identities are the simplest non-human credential option and overlook the on-premises constraint, assuming they can be used anywhere.
✗A user-assigned managed identity shared with the build server.Wrong answer — click to see why▾
Why this is wrong here
Managed identities cannot be assigned to on-premises servers; they are only available for Azure resources like VMs or App Services. The build server is outside Azure, so a managed identity cannot be used.
★ When this WOULD be the correct answer
If the build server were an Azure VM (or other Azure resource) and the requirement was to deploy ARM templates without storing credentials, a system-assigned managed identity would be the correct answer, as it provides an automatically managed identity tied to that resource.
Why candidates choose this
Candidates may think managed identities are the strongest non-human credential option and overlook the on-premises constraint, assuming they can be used anywhere like service principals.
✗A resource lock on the target resource group to permit template deployment.Wrong answer — click to see why▾
Why this is wrong here
Resource locks prevent accidental deletion or modification of resources but do not provide any authentication or authorization mechanism for deploying ARM templates. They cannot replace a credential for automation.
★ When this WOULD be the correct answer
An administrator needs to prevent accidental deletion of a critical resource group that contains production virtual machines. A resource lock (e.g., CanNotDelete) should be applied to the resource group to protect it from unintended changes.
Why candidates choose this
Candidates may confuse resource locks with access control or think they can secure deployments by locking resources, misunderstanding that locks do not authenticate or authorize the deployment process itself.
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
Symmetric Encryption Algorithm Comparison
| Algorithm | Key Size | Block Size | Status | Notes |
|---|---|---|---|---|
| AES-128 | 128-bit | 128-bit | Current standard | NIST approved; WPA3, TLS |
| AES-256 | 256-bit | 128-bit | Current standard | Preferred for sensitive / govt data |
| 3DES | 112-bit effective | 64-bit | Deprecated (2023) | Replaced by AES |
| DES | 56-bit | 64-bit | Broken | Cracked in < 24 h; never deploy |
| ChaCha20 | 256-bit | Stream cipher | Current | TLS 1.3, WireGuard |
Go deeper
Related to this question
Learn chapter
Managed Identities for Azure Resources
Key term
Conditional access
Conditional access is a security framework that evaluates signals like user location, device health, and risk level to grant or block access to resources in real time.
Key term
Security
Security in IT is the practice of protecting systems, networks, and data from unauthorized access, damage, or theft.
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.