AZ-400 Practice Test 3 — 25 Questions

Question 1

You are configuring a YAML pipeline that deploys to multiple environments. The pipeline should automatically trigger when changes are pushed to the main branch, but only if the build artifact changes. Which trigger configuration should you use?

Accepted Answer

trigger: paths: include: - src/*. Option B is correct because the `trigger: paths: include: - src/*` configuration specifies that the pipeline should only trigger when changes are pushed to the `main` branch AND those changes affect files under the `src/` directory. This ensures that the pipeline runs only when the build artifact (source code) changes, not for other changes like documentation or configuration files. The `paths` filter works in conjunction with the branch filter to provide fine-grained control over pipeline triggers.

Answer

trigger: branches: include: - main

Answer

pr: branches: include: - main

Answer

resources: containers: - container: myContainer

Question 2

Which TWO actions are required to securely use Azure Key Vault secrets in an Azure Pipelines build? (Choose 2)

Accepted Answer

Use the 'Azure Key Vault' task to download secrets as pipeline variables.. Option B is correct because the Azure Key Vault task in Azure Pipelines is the recommended way to securely download secrets from a Key Vault and expose them as pipeline variables. This task automatically handles authentication and ensures that secret values are masked in logs, preventing accidental exposure. It eliminates the need to manually manage secret retrieval and mapping in YAML.

Answer

Set the 'secrets' output variable to 'true' in the pipeline.

Answer

Use the 'Environment Variables' section in the pipeline to map secrets.

Answer

Reference the secret identifier directly in the pipeline YAML.

Question 3

You are designing a release pipeline that uses Azure App Service deployment slots. The pipeline must perform a swap after deployment to the staging slot. Which three tasks or actions should you include in the pipeline? (Select all that apply.)

Accepted Answer

Azure App Service deploy: Deploy to staging slot. Option A is correct because the Azure App Service deploy task with the 'Deploy to staging slot' action is the standard method to deploy an application to a staging slot before a swap. This ensures the new release is validated in an isolated environment without affecting the production slot.

Answer

Azure App Service manage: Delete staging slot

Answer

Azure CLI: Run az webapp deployment slot swap

Question 4

You have a multi-stage YAML pipeline with stages: Build, Test, and Deploy. The Deploy stage requires approval from a specific user group. You want to ensure that the approval request is sent only after the Test stage completes successfully. Which configuration should you use?

Accepted Answer

Define an environment with required approvers and reference it in the Deploy stage.. Option B is correct because Azure Pipelines environments allow you to define required approvers (user groups) that must approve a deployment before it proceeds. By referencing the environment in the Deploy stage, the approval request is automatically triggered only after the preceding Test stage completes successfully, since stages execute sequentially by default.

Answer

Add a manual validation task in the Deploy stage.

Answer

Use the 'condition' keyword: condition: eq(variables['Build.SourceBranch'], 'refs/heads/main')

Answer

Configure branch policies on the main branch.

Question 5

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]'. Option A is correct because 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 6

Your pipeline runs on a Microsoft-hosted agent. You need to securely reference an Azure Key Vault secret in a pipeline variable without exposing the value in logs. Which variable group type should you use and how should you reference the secret?

Accepted Answer

Create a variable group linked to Key Vault, then reference as $(KeyVaultName.SecretName). Option A is correct because linking a variable group to Azure Key Vault allows you to securely reference secrets as pipeline variables without exposing their values in logs. The $(KeyVaultName.SecretName) syntax retrieves the secret value at runtime from Key Vault, and the value is automatically masked in any output.

Answer

Use the 'Azure Key Vault' task to download secrets and assign to variables

Answer

Store the secret as a plain text variable and mark it as 'secret'

Answer

Reference the secret directly as $(SecretName) from a library variable group

Question 7

You want to trigger a pipeline automatically when a new commit is pushed to the 'develop' branch of your repository. Which trigger configuration should you use in the YAML pipeline?

Accepted Answer

trigger:
  branches:
    include:
      - develop. Option D is correct because the `trigger` keyword in an Azure Pipelines YAML file defines the CI (continuous integration) trigger that automatically starts a pipeline run when a commit is pushed to the specified branch. By using `trigger: branches: include: - develop`, the pipeline will trigger on every push to the 'develop' branch, which is the standard way to enable automatic builds for a specific branch.

Answer

schedules:
- cron: "0 0 * * *"
  branches:
    include:
      - develop

Answer

pr:
  branches:
    include:
      - develop

Answer

resources:
  repositories:
  - repository: self
    trigger:
      branches:
        include:
          - develop

Question 8

Which TWO are valid strategies to reduce build times in Azure Pipelines? (Choose 2)

Accepted Answer

Use the Cache task to cache NuGet packages or npm modules.. Option A is correct because the Cache task in Azure Pipelines allows you to store and restore dependencies like NuGet packages or npm modules across pipeline runs. By caching these dependencies, you avoid re-downloading them on every build, which significantly reduces build time, especially for large projects with many dependencies.

Answer

Use 'dotnet build --no-restore' to skip restore.

Answer

Use a larger agent pool with more parallel jobs.

Answer

Increase the build job timeout.

Question 9

A team uses a monorepo with multiple projects in one Git repository. They want to enforce that each commit message must reference a work item from Azure Boards. Which branch policy should they configure?

Accepted Answer

Require a work item linking policy in branch policies. The 'Require a work item linking policy' in Azure Repos branch policies enforces that every pull request must be associated with at least one Azure Boards work item before it can be completed. This policy directly meets the requirement to ensure each commit message references a work item, as the linking is validated at merge time.

Answer

Automatically include work items in pull request descriptions

Answer

Configure a minimum number of reviewers policy

Answer

Use a build validation policy to check commit messages

Question 10

A developer accidentally committed a sensitive password to a Git repository. The commit has already been pushed to the remote. What is the first step to remediate the situation?

Accepted Answer

Remove the password from the file, amend the commit, and force push. Option B is correct because the password has already been pushed to the remote, meaning it exists in the commit history. Simply deleting the file or reverting the commit does not remove the password from the Git history; anyone with access to the repository can still retrieve it. The proper first step is to remove the password from the file, amend the commit (using `git commit --amend`), and force push (`git push --force`) to overwrite the remote history, effectively erasing the sensitive data from the branch.

Answer

Delete the file from the repository and commit the deletion

Answer

Revert the commit that introduced the password

Answer

Immediately notify the security team and rotate the password

Question 11

Which TWO branch policies can be configured in Azure Repos to enforce code quality?

Accepted Answer

Status check. Status check (A) is correct because Azure Repos allows you to require that a status check passes before a pull request can be completed. This enforces code quality by integrating with external or built-in services (e.g., Azure Pipelines, SonarQube) that run automated tests, linting, or security scans. Build validation (C) is correct because it triggers a build pipeline automatically when a pull request is created, ensuring the code compiles and passes defined quality gates before merging.

Answer

Comment requirements

Answer

Work item linking

Answer

Merge strategy

Question 12

Which TWO metrics should you monitor to evaluate the reliability of a web application according to the DORA metrics?

Accepted Answer

Change Failure Rate. The DORA metrics define four key measures for software delivery performance: Deployment Frequency, Lead Time for Changes, Mean Time to Restore (MTTR), and Change Failure Rate. For evaluating the reliability of a web application, the two most directly relevant metrics are Change Failure Rate (B), which measures the percentage of deployments causing a failure in production, and Mean Time to Restore (MTTR) (C), which measures the time it takes to recover from a failure. These two metrics directly quantify stability and resilience, whereas Deployment Frequency and Lead Time for Changes focus on throughput and speed.

Answer

Lead Time for Changes

Answer

CPU Usage

Answer

Deployment Frequency

Question 13

A company uses Azure DevOps and needs to ensure that all pipelines use approved YAML templates from a central repository. The security team wants to prevent developers from referencing unapproved templates. What is the best way to enforce this?

Accepted Answer

Set the 'Required template' repository setting in the Azure DevOps project to the approved central repository.. Option D is correct because the 'Required template' repository setting in Azure DevOps enforces that all pipelines must use a YAML template from a specified central repository. If a pipeline references a template from any other location, the pipeline will fail at runtime, providing a hard enforcement mechanism that cannot be bypassed by developers. This directly addresses the security team's requirement to prevent unapproved template references.

Answer

Create a branch policy on the repository that requires all pull requests to be approved by security team members.

Answer

Configure a variable group with the approved template repository and require it in all pipelines.

Answer

Use a pipeline decorator to check the template origin and fail the pipeline if unapproved.

Question 14

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 15

A company uses Azure Pipelines to build a .NET Core application. The build takes 45 minutes due to dependency restoration. They want to reduce build time. What is the most effective strategy?

Accepted Answer

Cache the NuGet packages and enable caching in the pipeline. Caching NuGet packages in Azure Pipelines is the most effective strategy because dependency restoration is the primary bottleneck, often downloading hundreds of packages from nuget.org. By caching the ~/.nuget/packages folder, subsequent builds skip the network download entirely, reducing the 45-minute build time to minutes. This directly addresses the root cause—repetitive package restoration—without requiring additional infrastructure or parallelism.

Answer

Use parallel jobs in the pipeline

Answer

Use a self-hosted agent with more CPU

Answer

Enable incremental builds

Question 16

Which THREE of the following are valid methods to securely store and use secrets in Azure DevOps pipelines?

Accepted Answer

Azure Key Vault task in the pipeline. Option A is correct because the Azure Key Vault task in a pipeline allows you to fetch secrets directly from an Azure Key Vault instance during pipeline execution. This task retrieves secret values as pipeline variables, ensuring they are never exposed in logs or YAML files, and it supports both Azure Resource Manager and service principal authentication for secure access.

Answer

Azure App Configuration with Key Vault references

Answer

Storing secrets in a pipeline YAML file with encryption

Question 17

Match each Git branching strategy to its description.

Accepted Answer

Git Flow: Uses develop and master branches with release branches.. Git branching strategies vary in complexity. Git Flow uses long-lived branches (develop, release), GitHub Flow is simple with feature branches to main, GitLab Flow adds environment branches, and trunk-based development centers on frequent commits to main. Common confusions involve swapping descriptions between Git Flow and GitHub Flow.

Answer

Git Flow: Uses only main branch and feature branches.

Answer

GitHub Flow: Uses develop and release branches.

Question 18

Your team uses Azure Boards to track work items. They want to automatically update the state of a work item when a pull request is merged in Azure Repos. What should you configure?

Accepted Answer

Define a branch policy to link work items and set automatic state transition.. Option B is correct because Azure Repos branch policies allow you to require linked work items for pull requests and automatically transition the state of a linked work item (e.g., from 'Active' to 'Resolved') upon merge. This is configured in the branch policy settings under 'Automatically update work items' with a state transition rule, directly integrating Azure Boards with pull request completion.

Answer

Configure a work item template.

Answer

Create a service hook subscription.

Answer

Set pipeline variables in the YAML file.

Question 19

A development team wants to ensure that all code changes are reviewed by at least two senior developers before merging into the main branch. They use Azure Repos. What should they configure?

Accepted Answer

Configure a branch policy requiring a minimum number of reviewers.. Option C is correct because Azure Repos branch policies allow you to enforce a minimum number of reviewers on pull requests. By setting the 'Minimum number of reviewers' policy to 2, the team ensures that at least two senior developers must approve any code change before it can be merged into the main branch. This directly meets the requirement without involving build validation, release pipelines, or external function calls.

Answer

Enable the build validation policy on the branch.

Answer

Set up a release pipeline with gated deployments.

Answer

Add a status check policy using Azure Functions.

Question 20

A development team is using Git for source control. They have a main branch that should always be deployable. Developers work on feature branches and create pull requests to merge into main. Recently, a feature branch with incomplete work was accidentally merged into main, causing build failures. What is the best Git branch strategy to prevent this in the future while maintaining fast feedback?

Accepted Answer

Configure branch protection on main to require status checks (CI build and tests) to pass before merging.. Option B is correct because configuring branch protection on main to require status checks (CI build and tests) to pass before merging directly prevents incomplete or broken code from being merged. This enforces that every pull request must pass automated validation, ensuring main remains deployable while still allowing fast feedback through the CI pipeline.

Answer

Require at least one code reviewer approval for all pull requests into main.

Answer

Adopt a GitFlow-like branching model with a separate release branch for stable code.

Answer

Disable direct pushes to main and enforce all merges through pull requests.

Answer

Require a linear history on main by enabling 'Rebase and merge' for all pull requests.