Tracking Build Failures Automatically with 'Create Work Item on Failure'
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?
⚠ Common exam trap
It's easy for candidates to confuse Azure Repos branch policies (which enforce code review on pull requests) with Azure Boards work item rules (which enforce conditions on work item state transitions), leading candidates to select Option D instead of A.
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 work item rule in the process template to require a code review for the 'Done' transition.
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.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Add a work item rule in the process template to require a code review for the 'Done' transition.
Why this is correct
A process template rule is the correct mechanism in Azure Boards because rules can enforce conditions on state transitions, such as requiring a custom 'Code Review' field to be completed before a work item is allowed to move to 'Done'.
- ✗
Modify the work item type definition to add a custom field for code review status.
Why it's wrong here
Adding a custom field to the work item type definition simply provides a place to record code review status; without a corresponding rule or constraint on the 'Done' transition, it does not enforce that a review actually occurred.
- ✗
Use a tag to mark work items as code-reviewed before moving to 'Done'.
Why it's wrong here
Tags in Azure Boards are purely ad-hoc metadata labels that can be manually added or removed by any user with edit permissions; they carry no conditional logic or validation hooks. Because tags cannot be used in process rules, there is no way to evaluate whether a specific tag exists before permitting a work item state transition, so a missing tag will never block or prevent moving to 'Done'. Moreover, tags are not stored as work item fields that can be reference in rules, making them incapable of enforcing any part of a Definition of Done. While you could search or group by tags, they remain indicative, not prescriptive.
- ✗
Configure branch policies in Azure Repos to require pull request approvals.
Why it's wrong here
Branch policies in Azure Repos enforce pull request approvals on code branches, but they are scoped to the Git repository and do not interact with Azure Boards work item state transitions, so they cannot require a code review before moving a work item to 'Done'.
Go deeper
Related to this question
Learn chapter
Managing Infrastructure as Code Using Azure
Key term
Check
A Check in Azure DevOps is a gating mechanism that evaluates predefined conditions before allowing a pipeline deployment to proceed to a specific environment.
Key term
Azure Boards
Azure Boards is a work tracking and project management service from Microsoft that helps teams plan, track, and discuss work across the software development lifecycle using Kanban boards, backlogs, and dashboards.
About these practice questions
One of 696 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 →
Same concept, more angles
4 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 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 2. 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 3. 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 4. 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.