AZ-400 Practice Test 31 — 15 Questions

Question 1

You are designing a multi-stage YAML pipeline for a .NET Core application. The pipeline must build, test, and deploy to a staging environment. You want to ensure that the deployment stage only runs if the build and test stages succeed, and that the staging deployment uses the exact same bits that were built. Which strategy should you use?

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

Accepted Answer

Create separate stages for build, test, and deploy. Use the 'dependsOn' keyword and publish artifact in build stage, download in deploy stage.. Using separate stages with 'dependsOn' ensures the deployment stage only runs after successful build and test stages. Publishing the build artifact in the build stage and downloading it in the deploy stage guarantees that the exact same compiled bits are used for deployment, maintaining consistency across environments.

Answer

Set up a release pipeline that uses the same build artifact and requires manual approval.

Answer

Use a build trigger on the staging branch to deploy after each commit, ignoring test results.

Answer

Define the pipeline with a single stage and use a condition to skip test on failure.

Question 2

Your organization is adopting Azure DevOps to manage a new project for a client. The client requires that all work items be linked to Git commits and pull requests. Additionally, they want a dashboard that shows the team's velocity and work item trends. You are responsible for setting up the project and configuring the necessary integrations. The team uses a Scrum process with Sprints. You have already created the project and imported the work items. What should you do next to meet the client's requirements?

Accepted Answer

Configure branch policies on the main branch to require linking work items. Set up the repository to automatically link commits to work items. Then create an Analytics view in Azure Boards to track velocity and work item trends.. Configuring branch policies on the main branch to require linking work items ensures that all pull requests are linked to work items, and enabling automatic linking of commits to work items covers commits. Creating an Analytics view in Azure Boards provides the necessary velocity and work item trend dashboards. Option A is incorrect because Azure Functions are unnecessary—Azure DevOps provides built-in linking and Analytics. Option C is incorrect because manual linking is inefficient and error-prone, and Power BI is not required. Option D is incorrect because it does not enforce linking on commits/PRs and does not address the dashboard requirement.

Answer

Create a custom tool using Azure Functions to parse commit messages and link work items. Use the built-in Charts feature in Azure Boards to create velocity charts.

Answer

Instruct developers to manually add work item IDs in commit messages and pull request descriptions. Create a custom dashboard using Power BI connected to Azure Boards.

Answer

Enable the setting 'Automatically link work items' in the repository settings. Configure a service hook to post commit details to a Teams channel for visibility.

Question 3

Refer to the exhibit. You receive a secret scanning alert for an Azure DevOps PAT in a GitHub repository. The push_protection_bypass is false. What does this mean and what action should you take?

Accepted Answer

The secret was blocked from being pushed; you should revoke the PAT and investigate the incident.. When `push_protection_bypass` is `false`, it means the secret was blocked from being pushed by GitHub's push protection feature. The alert indicates the secret was detected and prevented from entering the repository, so the correct action is to revoke the compromised PAT and investigate the incident to prevent future occurrences. Option D correctly identifies that the secret was blocked and prescribes the appropriate remediation steps.

Answer

The secret was pushed but push protection was bypassed; you need to revoke the PAT and use git filter-branch to remove it from history.

Answer

The secret was pushed successfully; you need to rotate the PAT and audit the commit history.

Answer

The secret was pushed and push protection was not bypassed; you need to open a support ticket with GitHub to remove the secret.

Question 4

Which THREE factors should you consider when designing a strategy for managing secrets in Azure Pipelines? (Choose three.)

Accepted Answer

Use Azure Key Vault to store secrets.. Azure Key Vault is the recommended service for securely storing and managing secrets, keys, and certificates. By integrating Key Vault with Azure Pipelines, you can avoid exposing sensitive information in YAML files or pipeline logs. This approach ensures secrets are never hardcoded and are dynamically retrieved at runtime.

Answer

Hardcode secrets in the pipeline YAML for simplicity.

Answer

Store secrets as plain text variables in YAML pipelines.

Question 5

Your organization uses Microsoft Entra ID for identity and Azure DevOps for source control. You need to enforce that all code changes to the main branch require a pull request with at least two approvals and no failing checks. What should you configure?

Accepted Answer

Set up a branch policy on the main branch in Azure Repos. Azure Repos branch policies allow you to enforce required pull requests, minimum number of reviewers (e.g., two approvals), and status checks (e.g., no failing checks) on the main branch. This ensures that all code changes to the protected branch comply with the defined quality and security gates before merging.

Answer

Configure a Conditional Access policy in Microsoft Entra ID

Answer

Add an environment protection rule in Azure Pipelines

Answer

Use a service hook to notify reviewers when a push occurs

Question 6

You are configuring a build pipeline for a JavaScript application. You want to run linting, unit tests, and build steps only when changes are pushed to the 'develop' branch. Which trigger should you configure?

Accepted Answer

Enable CI trigger with a branch filter for 'develop'.. Enabling a CI trigger with a branch filter for 'develop' ensures that the pipeline automatically runs linting, unit tests, and build steps only when changes are pushed to the 'develop' branch. This matches the requirement precisely, as CI triggers respond to push events, and the branch filter restricts execution to the specified branch.

Answer

Enable pull request trigger.

Answer

Enable scheduled trigger.

Answer

Enable continuous integration (CI) trigger without branch filters.

Question 7

Your team uses Azure Pipelines with a YAML-based build pipeline. The pipeline builds a .NET application and runs unit tests. Recently, the unit tests are failing intermittently due to flaky tests. You need to ensure that the pipeline fails only if the same test fails in two consecutive runs. Which feature should you configure?

Accepted Answer

Configure the 'retry failed tests' setting in the pipeline's test tab.. The correct feature is the 'Retry failed tests' setting in the pipeline's test tab. This allows you to configure the number of times a failed test is automatically retried. If the test passes on retry, the pipeline is marked as succeeded with warnings, effectively requiring two consecutive failures for the pipeline to fail. Option A is incorrect because GitHub Actions workflows are not relevant to Azure Pipelines. Option B is for rerunning failed stages, not individual tests. Option C reruns failed jobs, not tests.

Answer

Implement a GitHub Actions workflow with 're-run' trigger.

Answer

Use the 'Re-run failed stages' option in the pipeline run.

Answer

Enable 'Automatically rerun failed jobs' in the pipeline settings.

Question 8

Your pipeline uses a multi-stage YAML file. You want to conditionally run a stage only if the build originates from the 'main' branch. Which syntax should you use?

Accepted Answer

condition: eq(variables['Build.SourceBranch'], 'refs/heads/main'). The `condition` directive in a YAML pipeline stage evaluates expressions using Azure Pipelines syntax. The `eq()` function compares two values, and `Build.SourceBranch` for the 'main' branch returns `refs/heads/main`, not just `main`. This exact match ensures the stage runs only when the build originates from the 'main' branch.

Answer

condition: variables['Build.SourceBranch'] == 'main'

Answer

condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))

Answer

condition: eq(variables['Build.SourceBranch'], 'main')

Question 9

You are a DevOps consultant for a financial services company that is migrating from TFVC to Git. The existing TFVC repository has several branches: main, dev, feature branches, and release branches. The history is linear with no branching. The company requires that all future Git commits follow a strict naming convention: 'type(scope): description' (e.g., 'feat(api): add new endpoint'). They also want to prevent direct commits to the main branch; all changes must go through pull requests with at least one reviewer. Additionally, they want to ensure that each commit message is validated before it is merged. The team is small (5 developers) and they want a simple setup without complex tooling. Which approach should you recommend?

Accepted Answer

Configure branch policies on the main branch: require a minimum of one reviewer, and add a status check that runs a script to validate the commit message format. Azure Repos branch policies allow you to enforce pull request requirements (e.g., minimum number of reviewers) and require a status check that runs a custom script to validate commit message format. This ensures all commits merged into main comply with the naming convention and review policy without complex tooling, fitting the small team's need for a simple, server-side enforcement mechanism.

Answer

Create a build pipeline that validates commit messages and fails the build if invalid

Answer

Use a server-side pre-receive hook in the Git repository

Answer

Install a client-side pre-commit hook on each developer's machine to validate messages

Question 10

An organization uses Azure Repos with multiple Git repositories. They want to enforce that all commits to the main branch are signed using GPG keys. Which combination of actions is required to enforce commit signing?

Accepted Answer

Configure branch policy to require signed commits and have developers configure Git to sign commits with their GPG key.. Azure Repos supports a branch policy that requires commits to be signed, and developers must configure Git to sign commits with their GPG key using `git config --global user.signingkey` and `git commit -S`. This ensures that only signed commits are accepted into the main branch, enforcing non-repudiation and integrity.

Answer

Configure branch policy to require signed commits and have developers add their SSH public key to Azure Repos.

Answer

Configure repository settings to require a personal access token (PAT) for each commit.

Answer

Use Azure Key Vault to store signing keys and configure Azure Repos to automatically sign commits.

Question 11

You are designing a YAML pipeline that builds a .NET application and publishes it as a NuGet package to Azure Artifacts. Which three tasks should you include in the build stage?

Accepted Answer

DotNetCoreCLI@2 with command 'build'. The DotNetCoreCLI@2 task with the 'build' command compiles the .NET application source code into intermediate language (IL) assemblies. This is a mandatory step after restoring dependencies and before packing the project into a NuGet package. Without a successful build, the subsequent pack and push operations would fail.

Answer

NuGetCommand@2 with command 'install'

Answer

DotNetCoreCLI@2 with command 'push'

Question 12

Match each Azure DevOps extension type to its example.

Accepted Answer

Build task: NuGet Tool Installer. In this matching exercise, the correct pairs are: Build task → NuGet Tool Installer, Dashboard widget → Sprint Burndown, and Service hook → Notify Slack on build completion. The distractors incorrectly assign Sprint Burndown as a build task and NuGet Tool Installer as a dashboard widget, testing your ability to distinguish between extension types based on their purpose. Build tasks execute during pipeline runs, dashboard widgets display information on dashboards, and service hooks trigger external actions on events.

Answer

Build task: Sprint Burndown

Answer

Dashboard widget: NuGet Tool Installer

Question 13

Your Azure Pipelines build is failing with the error: '##[error]No agent found in pool 'Default' that satisfies the specified demands: Agent.Version -gtVersion 2.200.0'. The pool 'Default' contains agents of various versions. What is the most likely cause?

Accepted Answer

The 'Default' agent pool has no agents with version greater than 2.200.0.. The error message explicitly states that no agent in the 'Default' pool satisfies the demand 'Agent.Version -gtVersion 2.200.0'. Since the pool contains agents of various versions, the most likely cause is that none of those agents have a version greater than 2.200.0. This demand is set in the pipeline YAML or classic editor to ensure the agent meets a minimum version requirement.

Answer

The pipeline YAML has a syntax error in the 'demands' section.

Answer

The pipeline is configured to run on an agentless job.

Answer

The 'demands' keyword is not supported in Azure Pipelines.

Question 14

Your company uses Azure DevOps for CI/CD. You have a YAML build pipeline that builds a .NET Core application and publishes artifacts. The build runs on a Microsoft-hosted agent. Recently, the build started failing with the error 'The process cannot access the file because it is being used by another process.' This occurs intermittently during the 'dotnet build' step. The pipeline uses multiple jobs that run in parallel. You suspect that one job is interfering with another because they share the same workspace on the agent. You need to ensure that each job runs in its own isolated workspace. What should you do?

Accepted Answer

Set 'clean: all' on the checkout step in each job.. Setting 'clean: all' on the checkout step ensures that the workspace is cleaned before each job runs, preventing file conflicts caused by shared workspace on the agent. Option A is wrong because 'demands' are for selecting agents with specific capabilities, not for workspace isolation. Option B is wrong because 'workspace: clean' is not a valid setting at the pipeline root; workspace cleaning is configured per checkout step. Option C is wrong because a multi-job configuration with a matrix is used for parallelizing builds across different configurations, not for isolating workspaces.

Answer

Add a 'demands' section to the job to ensure each job runs on a different agent.

Answer

Set 'workspace: clean' in the pipeline root.

Answer

Use a 'multi-job' configuration with a matrix to run each job in separate folders.

Question 15

You are managing a pipeline that deploys a microservices application to multiple Azure Kubernetes Service (AKS) clusters in different regions. You want to implement a progressive exposure strategy where the deployment first goes to a small cluster (canary), then to a medium cluster, and finally to all clusters. The deployment should be automated but with the ability to halt if errors occur. What should you use?

Accepted Answer

Use deployment gates with evaluation of health metrics (e.g., error rate) before proceeding to the next stage.. Deployment gates in Azure Pipelines allow you to automatically evaluate health metrics (such as error rate, CPU usage, or custom metrics from Application Insights) before promoting a release to the next stage. This enables a progressive exposure strategy (canary → medium → all clusters) with automated rollback or halt if the metrics breach thresholds, without requiring manual intervention.

Answer

Use manual approval gates between stages.

Answer

Configure a rolling deployment strategy on each cluster.

Answer

Use a manual validation step in the pipeline.