AZ-400 Configure processes and communications Practice Question
Your team uses Azure Boards to manage work items. They want to automatically update the status of a work item to 'Resolved' when a pull request that contains the work item ID is merged. Which feature should you configure?
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Enable the 'Automatically update work item status' setting in the repository's pull request configuration.
Azure Repos provides a setting in the repository's pull request configuration to automatically update linked work items to a specified state (e.g., 'Resolved') when a pull request is merged. This setting automatically updates work items that are linked via the work item ID in the pull request description. Option B is incorrect because it requires manual effort, which is not automatic. Option C is incorrect because branch policies for linked work items only enforce linking, not automatic status updates. Option D is incorrect because although service hooks can be used to call REST APIs, Azure DevOps already provides a built-in mechanism for this scenario, making it unnecessary to create custom hooks.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Enable the 'Automatically update work item status' setting in the repository's pull request configuration.
Why this is correct
The 'Automatically update work item status' setting in a repository's Pull Request configuration is the native Azure DevOps mechanism that transitions linked work items to their resolved/closed state (e.g., Done) when the pull request is successfully merged. This server-side automation triggers on merge, uses the work item state mapping defined in the project's process configuration, and requires zero custom code or maintenance. For a team wanting automated status updates, this is the built-in, supported approach.
- ✗
Instruct developers to manually update the work item after merging.
Why it's wrong here
Relying on developers to manually update work items after merging introduces human error and inconsistency because there is no enforced trigger linking the merge event to a state transition. Developers may forget, update the wrong state, or close items prematurely, which breaks the traceability audit trail and requires recurring process policing. This is not a technical solution to the automation request; it shifts responsibility onto individuals and contradicts the goal of enforcing workflow without toil.
- ✗
Set up a branch policy that requires linked work items.
Why it's wrong here
The branch policy 'Check for linked work items' (or 'Require linked work items') only validates that a pull request contains at least one approved work item link at creation time, blocking completion if the link is absent. It does not execute any post-merge state change, so the work item remains in its original state even after the PR is completed. This policy enforces an input condition, not an output action; it would guarantee association, but fail to update status automatically.
- ✗
Create a service hook to call Azure DevOps REST API on pull request merge.
Why it's wrong here
A service hook that listens for the 'pull request.merged' event and calls the Azure DevOps REST API to update work items is functionally possible but introduces a custom development overhead: you must implement authentication (e.g., OAuth or PAT), handle retries for transient failures, and deploy/maintain a listener service. This approach duplicates functionality that already exists natively, increases the attack surface, and is far more complex than configuring the built-in automation. Unless there is a custom transformation or an outside-DevOps destination required, it is the anti-pattern here.
Visual reference
Go deeper
Related to this question
Learn chapter
Introduction to DevOps and Azure DevOps
Key term
Feature
A feature is a distinct unit of functionality that delivers value to the user, often managed and tracked throughout the software development lifecycle.
Key term
Branch
A branch is a pointer to a specific commit in a version control system that allows you to work on features or fixes in isolation from the main codebase.
About these practice questions
One of 823 original AZ-400 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This AZ-400 practice question is part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the AZ-400 exam.