AZ-400 Practice Test 28 — 15 Questions

Question 1

You are configuring a release pipeline that deploys to multiple environments. You want to automate the deployment to the staging environment only if the build succeeds, and then require manual approval before deploying to production. Which strategy should you use?

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

Define an environment with approvals required for the production stage.. Azure Pipelines allows you to define environments with explicit approval checks. By adding a manual approval gate on the production environment stage, the pipeline will automatically deploy to staging after a successful build, but pause before production until an authorized user approves the release. This directly meets the requirement for automated staging deployment and manual production approval.

Answer

Use deployment gates in the production stage to check for manual intervention.

Answer

Use a classic release pipeline with pre-deployment approvals.

Answer

Configure a branch policy on the main branch to require approval for pull requests.

Question 2

Which TWO features of GitHub Actions can be used to enforce code quality standards before merging?

Accepted Answer

Branch protection rules with required status checks. Branch protection rules with required status checks (C) enforce that pull requests must pass specific GitHub Actions workflows (e.g., linting, testing, security scans) before merging. Status checks (D) are the actual workflow runs that report pass/fail to the pull request; when required, they block merging until all checks succeed. Together, they ensure code quality gates are met automatically.

Answer

Environments

Answer

Secrets

Answer

Repository variables

Question 3

Your team uses GitHub Actions to build a Docker image and push it to Azure Container Registry (ACR). The workflow fails with the error 'unauthorized: authentication required'. The workflow uses the 'azure/docker-login@v1' action. What is the most likely cause?

Accepted Answer

The service principal used for authentication lacks the AcrPush role on the ACR.. The 'azure/docker-login@v1' action authenticates Docker with Azure Container Registry using a service principal. If the service principal lacks the AcrPush role, Docker login succeeds but the subsequent push fails with 'unauthorized: authentication required' because the identity does not have permission to push images. The error occurs at push time, not login time, which is a key diagnostic clue.

Answer

The 'azure/docker-login@v1' action does not support ACR.

Answer

The Dockerfile is not in the repository root.

Answer

The workflow uses the registry admin credentials, which are disabled.

Question 4

Your company uses GitHub Advanced Security. You need to ensure that all code in the main branch is free of high-severity secrets before deployment. What is the most efficient way to enforce this?

Accepted Answer

Enable secret scanning push protection. Secret scanning push protection (option B) is the most efficient way to enforce that no high-severity secrets reach the main branch because it blocks the push at the Git level before the commit is accepted. This prevents secrets from ever entering the repository, eliminating the need for post-hoc detection or manual review. Other options either rely on reactive detection or do not address secrets in code.

Answer

Require manual review of all pull requests for secrets

Answer

Configure Dependabot to flag secrets in dependencies

Answer

Enable code scanning alerts for secrets

Question 5

Your company uses GitHub Enterprise and wants to implement a secret scanning policy to detect and block secrets (e.g., API keys) in code pushes. The policy must allow exceptions for test repositories that use fake secrets. What is the recommended approach?

Accepted Answer

Configure secret scanning with custom patterns and use the 'secret_scanning_push_protection' setting with an allow-list for test repositories.. GitHub Enterprise's secret scanning push protection can be configured with custom patterns and an allow-list (via the `secret_scanning_push_protection` setting in the repository's security settings or through the API). This allows you to block pushes containing secrets across all repositories while explicitly exempting test repositories that use fake secrets, meeting the requirement for exceptions without manual intervention.

Answer

Use a pre-commit hook to detect secrets and allow developers to bypass it.

Answer

Implement a GitHub Actions workflow that scans for secrets and fails the push.

Answer

Enable secret scanning for all repositories, then manually disable it for test repositories.

Question 6

Your release pipeline uses deployment groups to deploy to Windows servers. You need to securely pass credentials to a script that runs on target machines. What is the recommended approach?

Accepted Answer

Use Azure Key Vault task to fetch secrets during deployment. The Azure Key Vault task securely retrieves secrets (e.g., passwords) from an Azure Key Vault during deployment, avoiding hardcoded or exposed credentials. This integrates with Azure Pipelines to pass secrets to scripts without storing them in the pipeline or on target machines, adhering to least-privilege and secure secret management practices.

Answer

Hardcode credentials in the script and encrypt the script file

Answer

Store credentials as pipeline variables and reference them

Answer

Use environment variables on the target machines

Question 7

Your organization uses Azure Pipelines and wants to implement a continuous feedback loop by collecting user analytics from the production environment and automatically creating work items in Azure Boards for critical issues. You need to design a solution that integrates monitoring data with the pipeline. What should you do?

Accepted Answer

Set up Azure Monitor alerts based on Application Insights data, and configure the alerts to invoke a webhook that calls the Azure Boards REST API to create a work item.. Azure Monitor alerts based on Application Insights data can trigger a webhook that calls the Azure Boards REST API to automatically create a work item. This integrates monitoring data with the pipeline to establish a continuous feedback loop. Option A is incorrect because Power BI visualization and email alerts do not automate work item creation. Option C is incorrect because release pipeline logs are not for collecting user analytics; Application Insights is needed. Option D is incorrect because manually reviewing dashboards is not automated.

Answer

Use Power BI to visualize Application Insights data and set up data-driven alerts that send emails to the team.

Answer

Configure the release pipeline to output logs to Azure Monitor and use Log Analytics to create work items.

Answer

Use Azure Application Insights to collect user analytics, and manually review dashboards to create work items.

Question 8

Your Azure DevOps repository contains a large binary file that is slowing down clone operations. Which Git feature should you use to reduce the clone time?

Accepted Answer

Git LFS (Large File Storage). Git LFS (Large File Storage) is the correct solution because it replaces large binary files in the repository with lightweight text pointers, storing the actual binary content in external remote storage. This prevents the large file from being downloaded during every clone, significantly reducing clone time and repository size on disk.

Answer

Shallow clone

Answer

Depth parameter in clone command

Answer

Sparse checkout

Question 9

Refer to the exhibit. A developer runs the pipeline on a branch called 'feature/abc'. What will happen?

Accepted Answer

Only the Build stage will execute.. The 'Deploy' stage has a condition that checks if the source branch is 'refs/heads/main'. Since the branch is 'feature/abc', the condition evaluates to false, so the Deploy stage will be skipped. The Build stage runs regardless.

Answer

The pipeline will fail with a syntax error.

Answer

Both stages will execute.

Answer

The Deploy stage will run but skip the steps.

Question 10

Which TWO tasks can be used to run unit tests in an Azure Pipeline?

Accepted Answer

DotNetCoreCLI@2. The DotNetCoreCLI@2 task can run unit tests for .NET Core and .NET 5+ projects by invoking the 'dotnet test' command, which discovers and executes tests in the specified project files. The VSTest@2 task runs unit tests using the Visual Studio Test Runner, supporting a wide range of test frameworks (MSTest, xUnit, NUnit) and can run tests from assemblies or test containers. Both tasks are designed specifically for executing unit tests within an Azure Pipeline, making them the correct choices.

Answer

NuGetCommand@2

Answer

PublishBuildArtifacts@1

Answer

CopyFiles@2

Question 11

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 12

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 13

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 14

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 15

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