AZ-400 Configure processes and communications Practice Test 4 — 15 Questions

Question 1

A company recently migrated its CI/CD pipelines from Jenkins to Azure Pipelines. The development team is experiencing frequent build failures due to conflicting changes when multiple developers push code simultaneously. The team wants to maintain a linear history and avoid merge commits. Which strategy should you recommend?

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

Accepted Answer

Use Team Foundation Version Control (TFVC) with exclusive checkout enabled.. Team Foundation Version Control (TFVC) with exclusive checkout enforces a lock on a file when a developer checks it out, preventing simultaneous edits. This eliminates conflicting changes that cause build failures when multiple developers push code concurrently, and since TFVC does not use merge commits, it maintains a linear history. The scenario explicitly requires avoiding merge commits and resolving conflicts from simultaneous pushes, which TFVC’s exclusive checkout directly addresses.

Answer

Switch to Git with a central repository and require merge commits.

Answer

Enforce a rebase strategy for all pull requests in the branch policy.

Answer

Configure Azure Repos to use squash merge when completing pull requests.

Question 2

You are the DevOps lead for a financial services company. The company uses Azure DevOps Services with a single project containing multiple teams. The compliance team requires that all production deployments be approved by a change advisory board (CAB) member. Additionally, any deployment that changes a configuration value stored in Azure App Configuration must be audited. You have set up a release pipeline with a manual approval gate and a pre-deployment condition that runs a PowerShell script to validate configuration changes. However, the compliance team reports that some deployments bypassed the approval gate. Upon investigation, you find that developers with 'Edit release pipeline' permissions can modify the pipeline and remove the approval gate. You need to ensure that the approval gate cannot be bypassed by developers. You also need to ensure that any change to a configuration key is logged to Azure Monitor. What should you do?

Accepted Answer

Create a protected variable group that stores the approval gate configuration and set the pipeline to use it. Restrict edit permissions on the release pipeline to a security group that does not include developers. For configuration changes, use an Azure Resource Manager template with a deployment script that sends logs to Azure Monitor.. It addresses both requirements: restricting pipeline edit permissions to a security group that excludes developers prevents them from removing the approval gate, and using an ARM template with a deployment script that sends logs to Azure Monitor ensures configuration changes are audited. Protected variable groups secure sensitive configuration, but the key is permission separation and audit logging via ARM deployment scripts.

Answer

Create a new service connection with limited permissions and require that all pipeline runs use it. Use an Azure Policy to audit configuration changes.

Answer

Configure environment-level approvals in the release pipeline and use Azure Policy to enforce that all deployments go through the environment. Use diagnostic settings on App Configuration to stream logs to Azure Monitor.

Answer

Implement a branch policy on the release pipeline's YAML file in the repository to require approval for changes. Use a webhook to send configuration change events to Azure Monitor.

Question 3

A development team is transitioning from a centralized version control system to Git in Azure Repos. The team lead wants to ensure that the branch structure supports both feature development and hotfix releases, with the ability to stabilize a release candidate before final deployment. Which branch strategy should the team implement?

Accepted Answer

Use Git Flow with feature, develop, release, and main branches.. Git Flow is the correct choice because it explicitly supports feature development, release stabilization, and hotfix releases through its structured branch hierarchy. The release branch allows the team to stabilize a release candidate before merging to main, while hotfix branches can be created from main for urgent fixes. This aligns perfectly with the requirement for both feature development and hotfix releases with release candidate stabilization.

Answer

Use trunk-based development with short-lived feature branches that merge directly to main.

Answer

Use a forking workflow where each developer forks the repository and creates pull requests.

Answer

Use GitHub Flow with feature branches and pull requests directly to main.

Question 4

You see the above YAML pipeline trigger configuration in an Azure Pipeline. The repository uses Git Flow with branches: feature/new-feature, develop, release/v1.0, and main. A developer pushes a commit to the branch feature/new-feature. Which action will trigger the pipeline?

Accepted Answer

No trigger will start.. The YAML trigger configuration (shown) explicitly lists the branches that trigger CI. Since feature/new-feature is not included in the branch filter, a push to that branch does not start a CI run. PR triggers are separate and require an actual PR to be created, not a push.

Answer

A CI trigger will start because the branch name starts with 'feature/'.

Answer

A PR trigger will start because the branch name contains 'feature'.

Answer

A CI trigger will start for all branches because batch is set to true.

Question 5

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.. 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 6

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.. 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 7

Drag and drop the steps to configure a service hook for build completion notifications to Microsoft Teams into the correct order.

Accepted Answer

First, navigate to Project Settings and select Service Hooks. Then, create a new subscription choosing the Build completed event and Microsoft Teams as the service. Finally, configure the webhook URL and test the subscription.. To configure a service hook for build completion notifications to Microsoft Teams, you must first access the Service Hooks page in Project Settings. Then, you create a new subscription and select the Build completed event and Microsoft Teams as the service. Finally, you provide the webhook URL and test the subscription to ensure it works.

Answer

First, create a new subscription choosing the Build completed event and Microsoft Teams. Then, navigate to Project Settings and select Service Hooks. Finally, configure the webhook URL and test the subscription.

Answer

First, configure the webhook URL and test the subscription. Then, navigate to Project Settings and select Service Hooks. Finally, create a new subscription for the Build completed event.

Answer

First, choose Microsoft Teams as the service and paste the webhook URL. Then, navigate to Project Settings and select Service Hooks. Finally, create a new subscription for the Build completed event.

Question 8

Drag and drop the steps to set up a self-hosted Azure DevOps agent on a Windows VM into the correct order.

Accepted Answer

First create a PAT, then download the agent, then run config.cmd to configure and register, then start the agent as a service.. The correct order to set up a self-hosted Azure DevOps agent on a Windows VM is: create a Personal Access Token (PAT) first, then download the agent package, then run config.cmd to configure and register the agent with Azure DevOps, and finally start the agent as a service. Option A reflects this sequence correctly. Other options either place download before PAT creation or start the agent before configuration, which would fail.

Answer

First download the agent, then create a PAT, then run config.cmd, then start the agent as a service.

Answer

First create a PAT, then run config.cmd, then download the agent, then start the agent as a service.

Answer

First create a PAT, then download the agent, then start the agent as a service, then run config.cmd.

Question 9

Match each Azure DevOps service to its primary function.

Accepted Answer

Azure Boards: Agile project management and work tracking. The correct matches are: Azure Boards for agile planning, Azure Repos for version control, Azure Pipelines for CI/CD, and Azure Artifacts for package management. Common confusions include swapping Boards with Repos or Pipelines.

Answer

Azure Boards: Source code version control

Answer

Azure Pipelines: Agile project management

Question 10

Match each Azure Test Plans concept to its definition.

Accepted Answer

Test Plan: A container for test suites and test cases that specifies test settings and test configurations.. In Azure Test Plans, a Test Plan is a container for test suites and test cases with settings. A Test Suite groups test cases. A Test Case has steps and expected results. A Test Run is an execution of test cases. A Test Point is a test case with a specific configuration.

Answer

Test Suite: A set of steps and expected results to validate a feature.

Answer

Test Case: A collection of test cases grouped together for execution.

Question 11

Your team uses GitHub Issues to track work. You want to enforce that all new issues include a specific set of labels based on the issue type (bug, feature, task). What is the most efficient way to achieve this?

Accepted Answer

Create YAML-based issue forms in the .github/ISSUE_TEMPLATE folder.. GitHub issue forms, defined as YAML files in the .github/ISSUE_TEMPLATE folder, allow you to create structured templates that can enforce required fields, including mandatory label assignments. When a user submits an issue via a form, the labels specified in the template are automatically applied, ensuring consistency without manual intervention or additional automation.

Answer

Configure branch protection rules to require label assignments.

Answer

Use a CODEOWNERS file to auto-assign labels.

Answer

Set up a repository ruleset to restrict label modifications.

Question 12

Your team follows trunk-based development. The main branch should always be deployable. Which two practices must you implement? (Choose two.)

Accepted Answer

Use feature flags to manage incomplete work.. In trunk-based development, the main branch must always be deployable. Feature flags (B) allow incomplete or work-in-progress code to be merged into the main branch without affecting production behavior, because the new functionality is toggled off until ready. Keeping branches short-lived (C) (typically less than a day) minimizes merge conflicts and ensures that changes are integrated quickly, reducing the risk of long-lived divergence that could break the main branch.

Answer

Require manual approval for every pull request.

Answer

Create release branches for each deployment.

Answer

Use long-lived feature branches for each feature.

Question 13

You are designing a communication strategy for a large Azure DevOps migration. The team is distributed across multiple time zones. Which approach best supports asynchronous collaboration?

Accepted Answer

Maintain a wiki in Azure DevOps with status and decisions.. Maintaining a wiki in Azure DevOps provides a persistent, searchable, and asynchronous record of status and decisions, which is ideal for distributed teams across time zones. Option A is wrong because Slack huddles are real-time and require synchronous participation. Option C is wrong because email threads can be hard to search and lack integration with Azure DevOps. Option D is wrong because daily standup meetings at a fixed time require synchronous attendance. Option E is wrong because recording meetings is passive and not easily searchable; the information is not structured for quick reference.

Answer

Use Slack huddles for quick sync-ups.

Answer

Use email threads for status updates.

Answer

Schedule daily standup meetings at a fixed time.

Answer

Record all team meetings and share links.

Question 14

Refer to the exhibit. The JSON above shows a branch policy configuration for the main branch in Azure Repos. A developer pushes a third commit to an existing pull request after two reviewers have already approved. What happens?

Accepted Answer

The existing approvals remain valid because dismiss_stale_reviews is false.. In Azure Repos, the 'Block on last push' policy (require_last_push_approval) only revokes an approval from the user who made the most recent push, preventing them from approving their own changes. It does not invalidate approvals from other reviewers. The setting that resets all approvals when new commits are pushed is 'Reset code reviewer votes when there are new changes' (dismiss_stale_reviews). Since dismiss_stale_reviews is false in the given configuration, the two existing approvals remain valid when the developer pushes a third commit.

Answer

The pull request is automatically merged because allowed merge types include squash.

Answer

The approvals are dismissed because require_last_push_approval is true.

Answer

The pull request is blocked because the merge type is not allowed.

Question 15

Your organization uses GitHub Copilot for pull request summaries. However, some developers report that the summaries are inaccurate. What should you do to improve the quality of Copilot-generated pull request summaries?

Accepted Answer

Ask developers to write clear, structured PR titles and descriptions.. GitHub Copilot for pull request summaries relies on the PR title and description as primary input to generate accurate summaries. Clear, structured titles and descriptions provide better context for the AI model, reducing ambiguity and improving summary quality. Detailed commit messages (Option A) are not directly used by Copilot for PR summaries, as it focuses on the PR-level metadata.

Answer

Encourage developers to write more detailed commit messages.

Answer

Disable Copilot for pull requests and use manual summaries.

Answer

Provide a link to a documentation wiki in the PR description.