Tracking Build Failures Automatically with 'Create Work Item on Failure'
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?
Quick Answer
Referencing the work item with #mention syntax in the pull request description is what actually creates the link Azure Boards needs — once that link exists, merging the PR automatically transitions the work item's state (say, from Active to Resolved) based on the project's configured transition rules, with no external service required.
⚠ Common exam trap
It's easy for candidates to confuse external automation (webhooks, Azure Functions, Logic Apps) with the native, built-in integration that Azure DevOps provides, leading them to select custom solutions instead of the simple branch policy configuration.
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
✓
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 analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Set up a webhook in Azure Repos to call Azure Logic Apps on pull request merge.
Why it's wrong here
Webhooks require custom logic, not a built-in integration.
- ✓
Add a branch policy that requires a linked work item for pull requests.
Why this is correct
This ensures every PR has a work item, and on merge, the work item state can be updated.
- ✓
In the pull request description, use the #mention syntax to reference the work item.
Why this is correct
This links the PR to the work item, enabling automatic updates on merge.
- ✗
Configure a Service Hooks subscription in Azure DevOps to send pull request merge events to Azure Boards.
Why it's wrong here
Service Hooks send events to external systems, not directly update work items.
- ✗
Create an Azure Function that listens for pull request merge events and updates work items via the REST API.
Why it's wrong here
This is a custom solution, not a built-in configuration.
Visual reference
Go deeper
Related to this question
Learn chapter
Introduction to DevOps and Azure DevOps
Key term
Work item
A work item is a digital record in Azure DevOps that tracks a single unit of work, such as a task, bug, or user story, helping teams manage and monitor their progress.
Key term
Azure DevOps
Azure DevOps is a Microsoft service that provides development tools for planning, building, testing, and deploying software applications using automated pipelines and collaboration features.
About these practice questions
This AZ-400 question is part of Courseiva's 823-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
Same concept, more angles
8 more ways this is tested on AZ-400
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. Your team uses Azure Boards and wants to automate work item state transitions when code is merged. What should you use?
medium- A.Azure Pipelines with 'Update work item' task
- B.Branch policy in Azure Repos
- ✓ C.GitHub + Azure Boards integration with automatic work item linking
- D.Power Automate with Azure DevOps connector
Why C: GitHub + Azure Boards integration, when configured with automatic work item linking, automatically transitions work items (e.g., from 'Active' to 'Resolved') when a pull request is merged. This is achieved through the integration's ability to detect commit messages or PR descriptions containing 'AB#{ID}' or 'Fixes AB#{ID}' patterns, which trigger state changes defined in the Azure Boards project configuration.
Variation 2. A team uses Azure Boards and wants to ensure that work items moved to the 'Done' state require a completed code review. What should they configure?
easy- ✓ A.Add a work item rule in the process template to require a code review for the 'Done' transition.
- B.Modify the work item type definition to add a custom field for code review status.
- C.Use a tag to mark work items as code-reviewed before moving to 'Done'.
- D.Configure branch policies in Azure Repos to require pull request approvals.
Why A: Azure Boards allows you to define work item rules within the process template that enforce specific conditions on state transitions. By adding a rule to the 'Done' transition that requires a completed code review (e.g., via a custom field or check), you ensure work items cannot be moved to 'Done' without meeting that prerequisite. This is done through the inherited process customization in Azure DevOps, where you can add rules to the work item type's state transition.
Variation 3. 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?
easy- A.Configure a work item template.
- ✓ B.Define a branch policy to link work items and set automatic state transition.
- C.Create a service hook subscription.
- D.Set pipeline variables in the YAML file.
Why B: 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.
Variation 4. 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?
medium- ✓ A.Enable the 'Automatically update work item status' setting in the repository's pull request configuration.
- B.Instruct developers to manually update the work item after merging.
- C.Set up a branch policy that requires linked work items.
- D.Create a service hook to call Azure DevOps REST API on pull request merge.
Why A: 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.
Variation 5. Your team uses Azure Repos and wants to enforce that every commit message includes a work item ID. Which policy should you configure?
easy- A.Repository settings to restrict file paths.
- B.Branch policy to require a minimum comment length.
- ✓ C.Branch policy to require linked work items.
- D.Pre-push Git hook.
Why C: Azure Repos' 'Require linked work items' branch policy only requires a linked work item on the pull request, not a work item ID in each commit message. Branch policies do not inspect commit message text. A pre-push Git hook is client-side and can be bypassed, so it is not a reliable policy. Therefore, none of the listed options meets the stated requirement.
Variation 6. Your team uses Azure Boards to manage work items. You need to ensure that when a work item is moved to 'Closed', all linked pull requests in Azure Repos are automatically completed. What should you configure?
medium- ✓ A.Service hook to a custom Azure Function
- B.Work item 'Pull Request' tab
- C.Work item rule (state transition rule)
- D.Branch policy on the target branch
Why A: Azure Boards service hooks can trigger a custom Azure Function when a work item state changes to 'Closed', and that function can complete linked pull requests via Azure Repos REST API. Option C is incorrect because work item rules (state transition rules) in Azure Boards do not have a built-in action to automatically complete pull requests; they only allow changes to work item fields, not external actions like completing PRs.
Variation 7. Your team uses Azure Boards and wants to automatically update the work item state when a pull request is merged. The policy should require a successful build before merging and update the work item to 'Resolved' on merge. Which branch policy should you configure?
medium- ✓ A.Automatically update work items
- B.Require a minimum number of reviewers
- C.Comment resolution
- D.Check for linked work items
Why A: In Azure DevOps, 'Automatically update work items' updates linked work item states on merge, while 'Build validation' enforces a successful build before merge. These are separate policies. Therefore, the question has no correct answer among the given options.
Variation 8. You need to enforce that every commit in your repository is associated with a work item in Azure Boards. Which mechanism should you use?
easy- A.Use commit messages with work item IDs
- B.Deploy a custom Git hook on the server
- ✓ C.Configure a branch policy to require linked work items
- D.Use the 'Require status checks' policy
Why C: Azure Repos branch policies include a setting to 'Require linked work items', which enforces that every pull request (and by extension, every commit merged through that PR) is associated with a work item in Azure Boards. This policy is enforced server-side at merge time, ensuring no commit can be merged without a linked work item, regardless of how the commit message is formatted.
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.