AZ-400 Design and implement source control Practice Question
You are a DevOps consultant for a financial services company that is migrating from TFVC to Git. The existing TFVC repository has several branches: main, dev, feature branches, and release branches. The history is linear with no branching. The company requires that all future Git commits follow a strict naming convention: 'type(scope): description' (e.g., 'feat(api): add new endpoint'). They also want to prevent direct commits to the main branch; all changes must go through pull requests with at least one reviewer. Additionally, they want to ensure that each commit message is validated before it is merged. The team is small (5 developers) and they want a simple setup without complex tooling. Which approach should you recommend?
⚠ Common exam trap
Candidates often confuse client-side hooks (option C) with server-side enforcement, not realizing that client-side hooks are optional and easily bypassed, whereas Azure Repos branch policies (option D) provide mandatory, centralized enforcement without requiring custom server-side hook infrastructure.
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 branch policies on the main branch: require a minimum of one reviewer, and add a status check that runs a script to validate the commit message format
Azure Repos branch policies allow you to enforce pull request requirements (e.g., minimum number of reviewers) and require a status check that runs a custom script to validate commit message format. This ensures all commits merged into main comply with the naming convention and review policy without complex tooling, fitting the small team's need for a simple, server-side enforcement mechanism.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Create a build pipeline that validates commit messages and fails the build if invalid
Why it's wrong here
A build pipeline validates commit messages only after code is pushed, but the requirement demands validation *before* a merge occurs, meaning invalid commits could already exist in the pull request branch. This approach is tempting because it automates enforcement without additional tooling, and would be correct in a scenario where post-push validation is acceptable, such as a CI pipeline that blocks merging only after a failed build.
- ✗
Use a server-side pre-receive hook in the Git repository
Why it's wrong here
Azure DevOps Services Git hosting does not expose server-side pre-receive or update hooks; these hooks are only available on self-managed Git servers where you have direct filesystem access to the repository. Because Azure Repos is a managed cloud service, you cannot install or execute arbitrary scripts on the server as part of the push process. Therefore, this option is invalid for enforcing commit-message validation in Azure DevOps.
- ✗
Install a client-side pre-commit hook on each developer's machine to validate messages
Why it's wrong here
A client-side pre-commit hook runs only on a developer's local repository and can be trivially bypassed by using git commit --no-verify, so it cannot provide enforceable validation. Additionally, hooks are not propagated automatically through git clone; each developer must manually copy and maintain the hook script, which is error-prone and inconsistent across the team. Since the requirement mandates that invalid commit messages must be blocked before a merge, this decentralized approach cannot guarantee compliance and is therefore insufficient.
- ✓
Configure branch policies on the main branch: require a minimum of one reviewer, and add a status check that runs a script to validate the commit message format
Why this is correct
Branch policies in Azure Repos provide server-side enforcement: requiring a minimum number of reviewers and adding a build validation status check that runs a script to validate commit message format ensures that every pull request to main must pass both human review and automated message validation before merging, which fully satisfies the requirement.
Go deeper
Related to this question
Learn chapter
Introduction to DevOps and Azure DevOps
Key term
Repository
A repository is a central storage location where software packages, code, or configuration files are kept, managed, and distributed for use by IT systems.
Key term
Azure Repos
Azure Repos is a set of version control tools that allow teams to manage their source code, track changes, and collaborate on software projects using Git or Team Foundation Version Control (TFVC) within the Microsoft Azure ecosystem.
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.