Prepare and test your skills

Prepare and test your skills

Free sample question, answered and explained below. The AZ-400 Designing and Implementing Microsoft DevOps Solutions Exam practice bank has 208 more like it. Try 10 free: instant score, no account.
A development team uses Azure DevOps pipelines to deploy applications to various Azure resources, including App Services and Azure SQL Databases. The organization's security policy mandates that all automated connections from Azure DevOps to Azure resources must adhere to the principle of least privilege, utilize automated credential management, and avoid hard-coded secrets.
Which authentication method should the team prioritize for configuring their Azure DevOps service connections to Azure to meet these security requirements?
A Personal Access Token (PAT) is an alternative password used to authenticate to Azure DevOps. It's a string of characters that grants access to specific scopes (e.g., build, release, code) within an Azure DevOps organization or project for a defined period. PATs are typically used for programmatic access to Azure DevOps APIs, command-line tools, or integrating with third-party services.
While PATs are a valid authentication method for Azure DevOps, they do not meet the requirements for automated credential management and avoiding hard-coded secrets when connecting from Azure DevOps to Azure resources.
This answer would be correct if the question asked about authenticating a script or tool to Azure DevOps itself (e.g., to update a work item or trigger a pipeline from an external system), rather than authenticating an Azure DevOps service connection to Azure resources.
An Azure AD User Account with a password is a standard user identity within Microsoft Entra ID (formerly Azure Active Directory) that represents an individual user. This account is typically used for interactive sign-ins by human users to access Azure portal, Azure DevOps, or other Microsoft services.
Using an Azure AD User Account with a password for automated service connections from Azure DevOps to Azure resources is a poor security practice and fails to meet all the stated requirements:
This answer would be correct if the question was about how a human user logs into Azure DevOps or the Azure portal, or if there were no other programmatic authentication options available (which is rarely the case in Azure). However, for automated service connections, this is the least secure and least compliant option.
A Service Principal is an identity created for applications, hosted services, and automated tools to access Azure resources. It's essentially a non-user identity that represents an application or service within Azure AD. When configured with a client secret, the service principal uses this secret (a long, randomly generated string) as a password to authenticate to Azure AD and gain access to authorized resources.
While a Service Principal with a client secret can meet the principle of least privilege (by assigning specific RBAC roles) and avoid hard-coded secrets (if the secret is stored securely, e.g., in Azure Key Vault), it does not fully meet the 'automated credential management' requirement as effectively as Managed Identities.
This answer would be correct if Managed Identities were not supported for the specific Azure DevOps service connection type or the target Azure resource, or if the organization had a strong existing process for automated client secret rotation that made the manual aspect negligible. However, given the explicit preference for "automated credential management" and the availability of Managed Identities, Service Principals with client secrets are a less optimal choice.
Managed Identities are a feature of Azure Active Directory (Azure AD) that provide an automatically managed identity for Azure services. This identity can be used to authenticate to any service that supports Azure AD authentication, without needing to manage credentials in code or configuration files. There are two types: System-assigned managed identities are tied to the lifecycle of the Azure resource (e.g., an Azure VM or App Service) and are automatically deleted when the resource is deleted. User-assigned managed identities are standalone Azure resources that can be assigned to multiple Azure resources and have their lifecycle managed independently.
Managed Identities are the optimal choice because they directly address all the stated security requirements:
Managed Identities are the most secure and operationally efficient method for Azure DevOps service connections to Azure resources. They align perfectly with modern security best practices by automating credential lifecycle, enforcing least privilege, and eliminating the risk of exposed secrets. While Service Principals can also provide programmatic access, they typically involve managing client secrets, which introduces a manual element and potential security risks that Managed Identities are designed to overcome. The documentation's emphasis on "enhanced authentication security" and "avoiding hard-coded credentials" strongly supports Managed Identities as the preferred solution.
Answer them yourself and get your score the moment you finish. No account needed.
Full access includes
Keep the momentum going with these hand-picked practice scenarios
Last updated