Courseiva
Design and implement a source control strategyeasyMultiple ChoiceObjective-mapped

AZ-400 Practice Question: Design and implement a source control strategy

You need to enforce that every commit in your repository is associated with a work item in Azure Boards. Which mechanism should you use?

⚠ Common exam trap

Many exam-takers confuse a voluntary convention (commit message IDs) with an enforced policy, or they incorrectly assume that custom Git hooks are available in Azure Repos as they are in self-hosted Git servers.

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

Configure a branch policy to require linked work items

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.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

  • Use commit messages with work item IDs

    Why it's wrong here

    Commit messages containing work item IDs are purely advisory; Azure DevOps does not parse or validate them as part of any branch or PR policy, so developers can omit or mistype them and the commit still succeeds. This approach relies on manual discipline and provides no server-side enforcement that every commit is associated with a work item.

  • Deploy a custom Git hook on the server

    Why it's wrong here

    Azure DevOps Git repositories do not support server-side Git hooks, so a custom hook would have to run client-side, where it can be bypassed or never installed by other developers. Even if you attempted a pre-receive hook on an on-premises server, it would be overly complex, require custom maintenance, and would not integrate cleanly with the Azure DevOps branch policy framework.

  • Configure a branch policy to require linked work items

    Why this is correct

    Configuring a branch policy to require linked work items is the native, server-enforced solution: when a pull request is created, the policy checks that at least one work item is linked, and the merge is blocked until that requirement is satisfied. This directly ensures every commit merged into the branch is traceable to a work item, and it is the only option that is both enforced and work-item-specific.

  • Use the 'Require status checks' policy

    Why it's wrong here

    The 'Require status checks' branch policy forces other systems, such as build pipelines or external CI services, to report a successful status before a merge, but it has no awareness of work item linkage. It is a generic validation gate that cannot verify whether a specific work item ID is linked to the PR or commit, so it does not meet the requirement.

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 →

How Courseiva writes practice questions · Editorial policy

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.