AZ-400 Practice Test 22 — 15 Questions

Question 1

Your Azure Pipelines build fails intermittently due to transient network errors when downloading NuGet packages. You want to implement retry logic. What is the best approach?

Accepted Answer

Add a PowerShell task that wraps the NuGet restore in a retry loop. Adding a PowerShell task that wraps the NuGet restore command in a retry loop directly addresses transient network failures by reattempting the download. This approach is lightweight, customizable (e.g., using `Start-Sleep` between retries), and does not require changing pipeline architecture or relying on external infrastructure.

Answer

Increase the number of parallel jobs to average out failures

Answer

Use a deployment group to deploy the build to a staging environment

Answer

Configure a build retention policy to automatically retry failed builds

Question 2

Which THREE steps are essential when customizing an Azure DevOps process?

Accepted Answer

Add custom fields to work item types.. Customizing work item types by adding custom fields is a fundamental step in tailoring Azure DevOps processes to capture project-specific data. This is done through the inherited process model, which allows you to extend system processes without modifying the base definitions, ensuring upgrades and maintenance remain supported.

Answer

Use Hosted XML process model to customize.

Answer

Directly modify the 'Agile' system process.

Question 3

Your build pipeline uses a self-hosted agent in your on-premises network. The agent pool is configured to use the 'latest' agent version. Recently, a new version of the Azure Pipelines agent was released, and your builds started failing because the new agent requires .NET 6.0, which is not installed on the agent machine. What is the best way to prevent this issue in the future?

Accepted Answer

Configure the agent pool to use a specific agent version (e.g., '2.210.0') and test new versions in a separate pool before updating.. It decouples your production pipeline from automatic agent updates. By pinning the agent pool to a known-working version (e.g., '2.210.0'), you can validate new agent releases in a separate test pool before rolling them out. This prevents breaking changes—like a new .NET dependency—from impacting your builds without prior testing.

Answer

Switch to using Microsoft-hosted agents instead of self-hosted.

Answer

Disable automatic agent updates on the self-hosted agents.

Answer

Install .NET 6.0 on the agent machine to meet the new requirement.

Question 4

You are designing a build pipeline that uses a combination of tasks. The pipeline must compile code, run unit tests, and then publish code coverage results. The tasks are: Visual Studio Build, Visual Studio Test, and Publish Code Coverage Results. Which task should be performed first?

Accepted Answer

Visual Studio Build. The correct order of tasks is: first Visual Studio Build to compile code, then Visual Studio Test to run unit tests, and finally Publish Code Coverage Results. Since the question asks for the first task in the sequence, the correct answer is Visual Studio Build (Option A).

Answer

Visual Studio Test

Answer

Publish Code Coverage Results

Question 5

Your development team uses GitHub for source control. You want to automatically run a set of tests every time a pull request is opened against the main branch. What should you configure?

Accepted Answer

Create a GitHub Actions workflow triggered by pull_request events to main. GitHub Actions natively supports the `pull_request` event trigger, which can be configured to run workflows automatically when a pull request is opened against a specific branch (e.g., `main`). This allows you to define a YAML-based workflow in the `.github/workflows` directory that executes tests on every PR event, providing immediate feedback to developers without requiring external services or manual API calls.

Answer

Use the GitHub API to trigger tests when a PR is opened

Answer

Set up a webhook to trigger an external CI system

Answer

Configure a branch protection rule to require status checks

Question 6

You need to automatically run a security scan on every pull request in GitHub. The scan should block the PR if critical vulnerabilities are found. Which GitHub feature should you use?

Accepted Answer

GitHub Code Scanning with a CodeQL workflow. GitHub Code Scanning with a CodeQL workflow is the correct choice because it allows you to define a custom security analysis that runs on every pull request. By configuring the workflow to fail on critical-severity alerts, the pull request is automatically blocked, preventing vulnerable code from being merged. This integrates directly with GitHub's checks API to enforce the scan result as a required status check.

Answer

Dependabot version updates

Answer

Secret scanning

Answer

Branch protection rules with required status checks

Question 7

Your organization uses GitHub Flow with branch protections. Developers must link every pull request to an issue using a closing keyword (e.g., 'Fixes #123'). You need to enforce this linking automatically. What should you do?

Accepted Answer

Create a GitHub Actions workflow that validates the PR description contains a closing keyword.. A GitHub Actions workflow can be configured to run on pull request events and parse the PR description for a closing keyword pattern (e.g., regex matching 'Fixes #\d+'). If the keyword is missing, the workflow can fail the check, blocking the merge via branch protection rules that require status checks to pass. This directly enforces the linking requirement without relying on human compliance or third-party tools.

Answer

Configure an issue template with a closing keyword prompt.

Answer

Add a branch protection rule requiring a linked issue.

Answer

Use a required status check from a third-party app.

Question 8

Your Azure Pipelines release pipeline deploys to multiple stages. You need to implement a manual approval gate that requires two specific users to approve before deployment proceeds to production. The approval should expire after 8 hours. Which configuration should you use?

Accepted Answer

Pre-deployment conditions: Add approvers (user1, user2) with 'All' policy and set timeout to 480 minutes. It configures a pre-deployment approval gate requiring both user1 and user2 to approve (the 'All' policy) before the production stage proceeds, and sets the timeout to 480 minutes (8 hours) to expire the approval request. This matches the requirement for two specific users to approve and an 8-hour expiration.

Answer

Pre-deployment conditions: Add approvers (user1, user2) with 'Any one' policy

Answer

Pre-deployment conditions: Add approvers (user1, user2) with 'All' policy and set 'Allow deployment without approval' to true

Answer

Post-deployment conditions: Add approvers (team) with 'All' policy

Question 9

Your organization uses Microsoft Entra ID and Azure DevOps. You need to ensure that only users from specific Entra ID groups can create new Azure DevOps organizations. What should you configure?

Accepted Answer

Assign the Azure DevOps Administrator role to the security group. The Azure DevOps Administrator role in Microsoft Entra ID is specifically designed to manage Azure DevOps service-level settings, including the ability to restrict who can create new Azure DevOps organizations. By assigning this role to a security group, only members of that group can create new organizations, which directly meets the requirement.

Answer

Assign the Global Administrator role to the security group

Answer

Configure Conditional Access policies to block non-group members

Answer

Use Azure DevOps security policies to restrict organization creation

Question 10

You are reviewing an Azure Policy definition that denies pipeline creation if the pipeline template path is not '/pipeline-templates/my-template.yml'. What does this policy do?

Accepted Answer

Denies any pipeline that does not use a specific YAML template.. This Azure Policy definition uses a 'deny' effect with a condition that checks whether the pipeline references a specific YAML template. If the pipeline does not reference that template, the policy denies the pipeline creation or update. Option D is correct because the policy explicitly denies any pipeline that does not use the specified YAML template, enforcing compliance by blocking non-compliant pipelines.

Answer

Denies pipelines that use an outdated template version.

Answer

Allows only pipelines that use a specific YAML template.

Answer

Allows only pipelines in the pipeline-templates folder.

Question 11

Your team uses Azure Boards to manage work items. You need to ensure that when a work item is moved to 'Closed', all linked pull requests in Azure Repos are automatically completed. What should you configure?

Accepted Answer

Service hook to a custom Azure Function. Azure Boards service hooks can trigger a custom Azure Function when a work item state changes to 'Closed', and that function can complete linked pull requests via Azure Repos REST API. Option C is incorrect because work item rules (state transition rules) in Azure Boards do not have a built-in action to automatically complete pull requests; they only allow changes to work item fields, not external actions like completing PRs.

Answer

Work item 'Pull Request' tab

Answer

Work item rule (state transition rule)

Answer

Branch policy on the target branch

Question 12

You are designing a compliance plan for Azure DevOps. The compliance officer requires that all changes to build pipelines are audited and cannot be reverted without approval. What should you implement?

Accepted Answer

Store pipeline YAML in a repository with branch policies. Storing pipeline YAML in a repository with branch policies ensures that every change to the pipeline definition goes through a pull request (PR) process, which is auditable and requires approval before merging. Once merged, the change is recorded in the Git history, and reverting it requires another PR with approval, meeting the compliance requirement that changes cannot be reverted without approval.

Answer

Enable Azure DevOps audit logs

Answer

Use release approval gates

Answer

Set pipeline retention policies

Question 13

Your build pipeline uses a YAML template to define steps. You want to pass a parameter to the template to conditionally run a task. What syntax should you use in the template?

Accepted Answer

parameters:. The 'parameters' key in a YAML template is used to define parameters that can be passed to the template, allowing conditional execution based on the parameter value. Option B is incorrect: 'arguments' is not a standard YAML key for passing parameters to templates; it is used for specifying script arguments. Option C is incorrect: 'inputs' is used for task inputs within a step, not for template parameters. Option D is incorrect: 'variables' are used to define pipeline variables, not for passing parameters to templates.

Answer

arguments:

Answer

inputs:

Answer

variables:

Question 14

Your team uses Azure Pipelines to deploy a Docker container to Azure Kubernetes Service (AKS). The pipeline builds a Docker image, pushes it to Azure Container Registry (ACR), and then runs a deployment to AKS. You want to ensure that the deployment uses the exact image that was built in the same pipeline run. Which approach should you use?

Accepted Answer

Generate a unique tag (e.g., Build.BuildId) and pass it to both the Docker build and Kubernetes manifest via variable substitution.. Using a unique tag like Build.BuildId ensures that the exact image built in the pipeline is referenced in the Kubernetes manifest. This prevents deployment from accidentally using a stale or overwritten image, as the tag is unique per run and passed consistently via variable substitution from the Docker build to the deployment YAML.

Answer

Use two separate pipelines: one for build/push, one for deploy, and share the image tag via a variable group.

Answer

Use a single task for build and push, and rely on ACR's internal pull-through cache.

Answer

Tag the image as 'latest' and reference it in the Kubernetes manifest.

Question 15

Your organization is adopting GitHub Actions for CI/CD. You need to enforce that all workflows must pass required status checks before merging pull requests to the main branch. The repository is in an organization. What should you configure?

Accepted Answer

Create a branch protection rule for the main branch with required status checks.. Branch protection rules in GitHub allow you to enforce required status checks on pull requests before merging. By configuring a branch protection rule for the main branch, you can specify that certain GitHub Actions workflow runs must pass (e.g., CI checks) before a pull request can be merged. This directly enforces the policy that all workflows must pass required status checks.

Answer

Add an environment protection rule requiring approval from specific reviewers.

Answer

Set the workflow to have 'contents: write' permission.

Answer

Define a CODEOWNERS file that requires team review for main branch changes.