AZ-400 Practice Test 30 — 15 Questions

Question 1

Your team uses GitFlow and wants to enforce that all feature branches are deleted after merging to develop. Which automation should you implement?

Accepted Answer

Enable the 'Automatically delete source branches' policy in the branch policy.. The 'Automatically delete source branches' policy in Azure Repos branch policies automatically removes a feature branch once its pull request is completed into the target branch (e.g., develop). This directly enforces the GitFlow requirement without manual intervention or pipeline scripting, as it is a native repository-level setting.

Answer

Use a post-merge script in the pipeline.

Answer

Train developers to delete branches manually.

Answer

Configure branch retention policies in Azure Repos.

Question 2

You need to ensure that only authorized users can access the Azure DevOps organization. Which identity provider should you configure for single sign-on (SSO)?

Accepted Answer

Microsoft Entra ID. Microsoft Entra ID (formerly Azure AD) is the required identity provider for configuring single sign-on (SSO) for Azure DevOps organizations. Azure DevOps relies on Entra ID to authenticate users and enforce conditional access policies, ensuring only authorized identities from your tenant can sign in. This integration also supports SAML-based SSO and OAuth 2.0 flows, making it the native and only supported IdP for Azure DevOps SSO.

Answer

Google Workspace

Answer

Microsoft account (MSA)

Answer

GitHub ID

Question 3

A company has a policy that all code changes must be reviewed by at least two people. However, for urgent bug fixes, they want to allow a single reviewer. How should they configure the branch policy?

Accepted Answer

Set minimum number of reviewers to 2, but allow policy override for urgent fixes. Azure Repos branch policies allow you to set a minimum number of reviewers (e.g., 2) and then enable the 'Allow policy override' setting for urgent fixes. This lets authorized users bypass the two-reviewer requirement for critical bug fixes while maintaining the default policy for normal changes.

Answer

Set minimum number of reviewers to 1 and require a separate approval from a manager

Answer

Set minimum number of reviewers to 2 and allow resetting code review votes on new pushes

Answer

Configure a build validation policy that checks number of approvals

Question 4

A company uses Azure DevOps to manage code. They want to enforce that all changes to the main branch must go through a pull request with at least two reviewers. What should they configure?

Accepted Answer

Branch policy on the main branch. Branch policies in Azure DevOps allow you to enforce requirements on pull requests targeting a specific branch. By configuring a branch policy on the main branch, you can require a minimum number of reviewers (e.g., two) and mandate that all changes must go through a pull request. This ensures that no direct commits bypass the review process.

Answer

Add a tag to the main branch

Answer

Repository permissions

Answer

Configure a service hook

Question 5

You are designing a compliance strategy for Azure DevOps pipelines that deploy to production. The company policy requires that all production deployments must be reviewed by a security lead. Additionally, the deployment must use a specific release pipeline that has been pre-approved. How should you implement this?

Accepted Answer

Define a 'production' environment in Azure DevOps and configure an approval check that requires the security lead. Have the pipeline deploy to that environment.. Azure DevOps environments allow you to define approval checks that must be satisfied before a deployment proceeds. By creating a 'production' environment and adding a pre-deployment approval check requiring the security lead, you enforce the mandatory review. The pipeline then deploys to that environment, ensuring only the pre-approved release pipeline is used.

Answer

Create a branch policy that requires the security lead to approve the pull request before merging.

Answer

Use a Classic release pipeline with a pre-deployment approval gate for the production stage.

Answer

Store the approved pipeline definition in a variable group and reference it in all pipelines.

Question 6

Your team is using GitHub Flow for a web application. Developers create feature branches from main, make changes, and open pull requests. Recently, several pull requests were merged without required reviews because the branch protection rules were not enforced on the main branch. What should you do to ensure all pull requests to main require at least one reviewer?

Accepted Answer

Enable the 'Require a pull request before merging' rule in branch protection for main, and set 'Required approvals' to 1.. Branch protection rules in GitHub can enforce required pull request reviews before merging. By enabling 'Require a pull request before merging' and setting 'Required approvals' to 1, any pull request to main must have at least one reviewer approve before merging. Option B is incorrect because deleting head branches after merge does not enforce reviews. Option C is incorrect because requiring branches to be up to date is about ensuring the branch is current with the base branch, not about requiring reviews. Option D is incorrect because CODEOWNERS are optional and do not enforce mandatory reviews unless branch protection rules are set accordingly.

Answer

Configure the repository to automatically delete head branches after pull requests are merged.

Answer

Enable the 'Require branches to be up to date' rule in branch protection for main.

Answer

Add a CODEOWNERS file and configure it so that every file has at least one owner.

Question 7

You are creating a YAML pipeline that builds a .NET Core application. The pipeline must use a multi-stage build with separate stages for 'Build', 'Test', and 'Deploy'. The 'Deploy' stage should only run if both 'Build' and 'Test' succeed. Which two conditions can you use to achieve this? (Select all that apply.)

Accepted Answer

In the Deploy stage, set 'dependsOn: [Build, Test]'. Setting 'dependsOn: [Build, Test]' in the Deploy stage ensures that the Deploy stage only starts after both the Build and Test stages have completed. By default, a stage runs only if all its dependencies succeed, so this alone meets the requirement without needing an explicit condition. This is the standard way to enforce sequential execution in multi-stage YAML pipelines.

Answer

In the Deploy stage, set 'condition: and(succeeded('Build'), succeeded('Test'))'

Answer

In the Deploy stage, set 'dependsOn: [Build, Test]' and 'condition: stageDependencies.Build.result == 'Succeeded''

Question 8

Your team uses GitHub Actions to deploy a microservices application to a Kubernetes cluster. The workflow builds Docker images and pushes them to a container registry, then updates the Kubernetes deployment. The deployment often fails due to image pull errors, specifically 'ErrImagePull' and 'ImagePullBackOff'. You investigate and find that the image tag in the Kubernetes manifest is the commit SHA. The workflow uses the 'azure/k8s-deploy@v1' action. You suspect that the image is not being pulled because the registry credentials are not properly configured. You have stored the registry credentials as secrets. What is the most likely cause and solution?

Accepted Answer

The action does not automatically create imagePullSecrets; you need to add a step to create the secret in the cluster and reference it in the deployment.. The 'azure/k8s-deploy@v1' action deploys to Kubernetes but does not automatically create imagePullSecrets for private container registries. Even if the registry credentials are stored as secrets in GitHub, they are not automatically applied to the cluster. You must explicitly create a Kubernetes secret of type docker-registry and add an imagePullSecrets entry to the deployment manifest. Option A is wrong because using 'latest' tag is not a best practice and does not address authentication. Option B is wrong because the image name is likely correct; the issue is pulling due to lack of credentials. Option C is wrong because the action does support private registries when credentials are properly configured.

Answer

The commit SHA tag is not valid; use 'latest' tag instead.

Answer

The image name is incorrect; verify the registry URL.

Answer

The 'azure/k8s-deploy' action does not support private registries; use a different action.

Question 9

Your team uses Microsoft-hosted agents for builds. Recently, builds are taking longer to start. What is the best way to reduce queue times?

Accepted Answer

Provision self-hosted agents.. Microsoft-hosted agents share a global pool with other Azure DevOps organizations, so queue times increase during peak usage. Provisioning self-hosted agents gives you dedicated compute resources that are always available, eliminating dependency on the shared pool and reducing queue wait times.

Answer

Increase the number of parallel jobs in the organization.

Answer

Use more pipeline triggers.

Answer

Reduce the number of parallel jobs.

Question 10

A team is migrating from TFVC to Git. They have a large codebase with many branches. What is the recommended approach to preserve the history during migration?

Accepted Answer

Use the git-tfs tool to clone the TFVC repository with changesets. Git-tfs is a specialized bridge tool that converts TFVC changesets into Git commits, preserving the full history, author information, and branch structure during migration. Unlike Git-TF, which is deprecated and lacks support for newer TFVC features, git-tfs handles complex scenarios like merges and shelvesets, making it the recommended approach for preserving history when moving from TFVC to Git.

Answer

Copy the latest version of the code to a new Git repository and start fresh

Answer

Use the Git-TF tool to clone the TFVC repository

Answer

Export TFVC as a Git bundle and import with --no-metadata

Question 11

Your release pipeline deploys to multiple environments (Dev, QA, Prod) using approvals. You need to ensure that the deployment to Prod only proceeds if the deployment to QA succeeded and an approval is granted. Which combination of triggers and pre-deployment conditions should you configure?

Accepted Answer

Set the trigger on Prod to 'After stage' and select QA as the stage, and add a pre-deployment approval on Prod.. It configures the Prod stage trigger to 'After stage' with QA selected as the preceding stage, ensuring that the release to Prod only starts after QA completes successfully. Adding a pre-deployment approval on Prod then enforces that a manual approval is granted before the deployment actually begins. This combination satisfies both conditions: dependency on QA success and required approval.

Answer

Set the trigger on Prod to 'Automatic' and add a post-deployment approval on QA.

Answer

Set the trigger on Prod to 'After release' and add a pre-deployment approval on Prod.

Answer

Set the trigger on Prod to 'Manual only' and add a pre-deployment approval on Prod.

Question 12

Your Azure DevOps organization contains multiple teams. You need to ensure that code reviews require approval from a member of the security team before merging to the main branch. What is the best way to implement this?

Accepted Answer

Configure branch policies in Azure Repos. Configuring branch policies in Azure Repos (option D) is the correct approach because branch policies allow you to require specific reviewers—such as members of the security team—for pull requests targeting the main branch. This ensures that every merge to main must be approved by the security team. Option A is incorrect: Azure Pipelines is designed for continuous integration and delivery (CI/CD), not for enforcing code review requirements. Option B is incorrect: Microsoft Defender for Cloud focuses on cloud security posture management and threat protection, not on code review policies. Option C is incorrect: Microsoft Sentinel is a security information and event management (SIEM) tool for security analytics and threat intelligence, not for managing branch-level review policies.

Answer

Add a validation step in Azure Pipelines

Answer

Enable Microsoft Defender for Cloud

Answer

Deploy Microsoft Sentinel

Question 13

Drag and drop the steps to set up a continuous integration pipeline in Azure Pipelines into the correct order.

Accepted Answer

Create the pipeline, then select the source repository, then configure triggers, then add tasks, then validate the pipeline.. The correct order for setting up a continuous integration pipeline in Azure Pipelines is: first create the pipeline, then select the source repository (e.g., Azure Repos or GitHub), then configure triggers (e.g., on commit or PR), then add tasks (build, test, etc.), and finally validate the pipeline by running it. This sequence is reflected in option A. Starting with source selection or adding tasks before creation is incorrect.

Answer

Create the pipeline, then configure triggers, then select the source repository, then add tasks, then validate the pipeline.

Answer

Create the pipeline, then add tasks, then select the source repository, then configure triggers, then validate the pipeline.

Answer

Select the source repository, then create the pipeline, then configure triggers, then add tasks, then validate the pipeline.

Question 14

Your team uses GitHub Actions to build and deploy a static website to Azure Storage. The workflow uses the 'azure/storage-blob-upload' action to deploy to a storage account static website. Recently, deployments started failing with 'Error: Failed to get credentials'. The workflow uses OpenID Connect (OIDC) for authentication. What is the most likely cause?

Accepted Answer

The service principal used for OIDC does not have the 'Storage Blob Data Contributor' role on the storage account.. The 'azure/storage-blob-upload' action requires the service principal used for OIDC authentication to have the 'Storage Blob Data Contributor' role on the storage account to upload static website content. Without this role, the action fails to obtain credentials for blob write operations, resulting in the 'Failed to get credentials' error.

Answer

The storage account firewall is blocking the GitHub Actions IP range.

Answer

The OIDC configuration in GitHub is missing the 'client secret' field.

Answer

The 'azure/storage-blob-upload' action does not support static websites.

Question 15

You are reviewing a branch protection rule JSON for a GitHub repository. Developers complain that they cannot merge pull requests. What is the most likely cause?

Accepted Answer

The signed commit requirement is enforced but developers are not signing commits.. When a branch protection rule requires signed commits, any pull request containing unsigned commits will be blocked from merging. GitHub verifies commit signatures using GPG or S/MIME, and if developers are not signing their commits, the merge will fail regardless of other settings.

Answer

The required approving review count is set to 1.

Answer

Rebase merging is disabled.

Answer

Squash merge is the only allowed method.