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

Question 1

A team uses Azure Repos with a Git branching strategy that includes feature branches. They want to ensure that all feature branches are deleted automatically after the pull request is completed. What should they do?

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

Accepted Answer

Enable 'Automatically delete source branch' in the branch policy.. Azure Repos branch policies include an 'Automatically delete source branch' checkbox. When enabled, the source branch (e.g., a feature branch) is automatically deleted once the pull request is completed (merged or abandoned). This enforces cleanup without manual intervention, directly meeting the requirement.

Answer

Enable 'Create a merge commit' option in the branch policy.

Answer

Configure branch retention policy in the pipeline to delete branches after build.

Answer

Create a work item to remind developers to delete branches after merge.

Question 2

An organization uses Azure DevOps and wants to implement a change management process where all changes to the main branch require approval from a change advisory board (CAB). The CAB members are not part of the development team. How should they configure this?

Accepted Answer

Create a new branch policy on main that requires a minimum number of reviewers from a separate CAB group.. Azure DevOps branch policies allow you to enforce a minimum number of reviewers from a specific security group (e.g., a CAB group) on pull requests targeting the main branch. This ensures that every change to main requires explicit approval from CAB members, who are separate from the development team, without relying on manual processes or altering team membership.

Answer

Set branch permissions to restrict push to main and only allow CAB to approve via manual process.

Answer

Use a service hook to notify CAB when a PR is created, and rely on manual approval.

Answer

Add the CAB as members of the development team and require team review.

Question 3

Which TWO actions help improve communication and collaboration in a distributed Azure DevOps team?

Accepted Answer

Maintain a shared wiki with project documentation and decisions.. A shared wiki (e.g., Azure DevOps Wiki) provides a single source of truth for project documentation and decisions, accessible asynchronously—critical for distributed teams. Additionally, scheduling daily stand-up meetings at a time that works for all time zones ensures regular synchronous alignment and promotes collaboration. Multiple chat channels can fragment discussions, long email threads are hard to follow, and avoiding PR comments removes a key asynchronous review/discussion mechanism.

Answer

Use multiple chat channels for each topic to organize discussions.

Answer

Use long email threads for decision-making to ensure full documentation.

Answer

Avoid using pull request comments to reduce noise.

Question 4

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 5

You are the Azure DevOps administrator for a large enterprise with multiple projects using the Scrum process. The organization has recently adopted a new compliance policy requiring that all work items of type 'Epic' must be approved by a compliance officer before they can be moved to the 'Committed' state. The compliance officers are external to the development teams and should not have direct access to modify work items. You need to implement this requirement with minimal administrative overhead. The current process has the following states for Epics: New, Proposed, Committed, In Progress, Done. The desired flow is: from 'Proposed' to 'Committed', a compliance officer must approve the transition. Compliance officers are part of a security group named 'Compliance Officers'. They should be able to approve the transition without having to edit the work item directly. What should you do?

Accepted Answer

In the process template for Epic, add a work item rule on the transition from 'Proposed' to 'Committed' that requires approval from a member of the 'Compliance Officers' group.. Azure DevOps process templates allow you to add work item rules on state transitions. By adding a rule on the 'Proposed' to 'Committed' transition for the Epic work item type that requires approval from a member of the 'Compliance Officers' group, you enforce the compliance policy without granting those officers direct edit permissions. This leverages built-in approval gates within the work item tracking system, minimizing administrative overhead.

Answer

Use a service hook to send an email to the compliance officers when an Epic is moved to 'Proposed', and rely on them to manually approve the transition.

Answer

Modify the Epic work item type to add a field 'Compliance Approval' and set the compliance officer as a required reviewer in the field settings.

Answer

Configure a branch policy on the main branch that requires approval from the 'Compliance Officers' group for pull requests.

Question 6

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?

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 7

Your team uses Azure Boards and has several work item types (Epic, Feature, User Story, Bug, Issue). They want to enforce a rule that bugs can only be linked to Features, not directly to Epics. Which TWO actions should you perform?

Accepted Answer

Customize the Epic work item type to remove the 'Child' link to Bug.. By customizing the Epic work item type to remove the 'Child' link type to Bug, you prevent any Bug from being linked as a child of an Epic. This enforces the rule that Bugs can only be linked to Features. Option E is correct because by customizing the Bug work item type to remove the 'Parent' link type to Epic, you prevent a Bug from having an Epic as its parent, which directly enforces the desired linking restriction.

Answer

Configure the Epic work item type to require a link to a Bug.

Answer

Use a work item rule to set the parent type to Feature when a Bug is created.

Answer

Add a rule to the Bug work item type that prohibits linking to Epics.

Question 8

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 9

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 10

A team uses Azure Boards to manage work items. They want to automatically update the state of a work item when a related pull request is merged in Azure Repos. Which TWO actions should they configure to enable this integration?

Accepted Answer

Add a branch policy that requires a linked work item for pull requests.. A branch policy that requires linked work items for pull requests ensures that every PR is associated with a work item. When the PR is merged, Azure Repos automatically updates the state of the linked work item (e.g., from 'Active' to 'Resolved') based on the default or configured transition rules. This integration is built into Azure DevOps without requiring external services.

Answer

Set up a webhook in Azure Repos to call Azure Logic Apps on pull request merge.

Answer

Configure a Service Hooks subscription in Azure DevOps to send pull request merge events to Azure Boards.

Answer

Create an Azure Function that listens for pull request merge events and updates work items via the REST API.

Question 11

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 12

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 13

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 14

Your team uses Azure DevOps and wants to implement a change management process where all production releases must be approved by a change advisory board (CAB) after the build is complete but before deployment. The approval must be recorded in the pipeline. What is the best approach?

Accepted Answer

Create a release pipeline with a pre-deployment approval gate for the production stage.. A release pipeline with a pre-deployment approval gate for the production stage enforces that a designated approver (or group, such as the CAB) must approve the release before deployment begins. The approval is recorded in the pipeline's audit trail, satisfying the requirement for documented change management. This approach aligns with Azure DevOps release management best practices for gating production deployments.

Answer

Configure a branch policy requiring CAB member approval on pull requests.

Answer

Add a manual intervention task in the YAML pipeline.

Answer

Set up a service hook to send an email to the CAB and wait for a reply.

Question 15

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.