AZ-400 Configure processes and communications Practice Question
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?
⚠ Common exam trap
Watch out — candidates often confuse work item rules with branch policies or service hooks, mistakenly thinking that notification-based or code-review mechanisms can enforce work item state transitions.
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
✓
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 analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
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.
Why this is correct
This is the correct solution because Azure DevOps process template rules for work item types can enforce approvals on specific state transitions. Adding a rule to the Epic workflow that requires approval from the 'Compliance Officers' group when moving from 'Proposed' to 'Committed' ensures the transition cannot be completed without that group's authorization, directly enforcing the compliance gate at the work item level.
- ✗
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.
Why it's wrong here
A service hook is asynchronous and only sends a notification (e.g., an email) when the Epic moves to 'Proposed'; it does not block or enforce the subsequent transition to 'Committed'. Reliance on manual approval via email is not a system-enforced rule, so the compliance requirement can be bypassed if the officers do not act or the approver ignores the email.
- ✗
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.
Why it's wrong here
Adding a 'Compliance Approval' field to the Epic work item type does not enforce approval on state transitions—field rules in Azure DevOps cannot designate a 'required reviewer' for a transition. Reviewer fields are informational and do not gate the workflow, so an Epic could still be moved to 'Committed' without the compliance officer actually approving.
- ✗
Configure a branch policy on the main branch that requires approval from the 'Compliance Officers' group for pull requests.
Why it's wrong here
A branch policy on the main branch governs pull requests and code changes to that branch, not work item state transitions. The Epic's 'Proposed' to 'Committed' transition occurs in the work item tracking system, which is independent of Git branch policies, so this would not enforce the required compliance approval for work items.
Go deeper
Related to this question
Learn chapter
Introduction to DevOps and Azure DevOps
Key term
DevOps
DevOps is a set of practices that combines software development (Dev) and IT operations (Ops) to shorten the development lifecycle and deliver high-quality software continuously.
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.
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.