Branch protection, pull requests and code owners
Branch policies are how a team makes the main branch safe. The exam asks which control, in which product, achieves a given rule.
Azure Repos branch policies
Set policies on a branch such as main in Project settings or the branch menu. The main ones:
- Require a minimum number of reviewers, with options to block self-approval and to reset votes when new changes are pushed.
- Check for linked work items, which forces traceability.
- Check for comment resolution, so open comments block completion.
- Limit merge types: basic merge, squash, rebase and fast-forward, or semi-linear merge.
- Build validation: runs a pipeline on every pull request and blocks completion until it succeeds.
- Automatically included reviewers: path-based reviewers, for example a security group for
/infra. - Status checks: external services can post a pass or fail.
Policies apply to a branch or a branch pattern. Admins can bypass them only if they hold the Bypass policies permission.
GitHub branch protection
GitHub uses a branch protection rule (or the newer rulesets) on a branch name pattern. Typical settings:
| Setting | Effect |
|---|---|
| Require a pull request before merging | No direct pushes |
| Require approvals | Number of reviewers |
| Require review from Code Owners | Matches the CODEOWNERS file |
| Require status checks | Workflow or app checks must pass |
| Require signed commits | Only verified signatures |
| Require linear history | Blocks merge commits |
CODEOWNERS
A CODEOWNERS file lives in the repository root, .github/ or docs/. Each line maps a path to users or teams:
/src/auth/ @contoso/security-team
*.tf @contoso/platformOn its own the file only requests reviews. It becomes mandatory when the branch protection rule requires code owner review. Protect the branch you deploy from (main), not the feature branches.
Choosing a branching model
- Trunk-based: short-lived branches, merge to main often, feature flags for unfinished work. Best fit for continuous delivery.
- GitFlow: long-lived develop and release branches. Heavier, used when releases are scheduled.
- Release flow (Microsoft): topic branches into main, release branches cut from main for hotfixes.
Exam traps
- A CODEOWNERS file alone does not block merges; the protection rule must require code owner review.
- Putting the protection rule on feature branches instead of main.
- Using a release gate when the question wants a pre-merge check. Build validation is pre-merge; gates are in release.
- Assuming squash keeps every commit. It produces one.
- Forgetting that Azure Repos uses policies and GitHub uses protection rules, and the names are not interchangeable.
Practice questions
Choose an answer, then review the explanation to check your understanding.
1. Every change to main in a GitHub repository must be reviewed by the security team before merge. What enforces this?
Show answer
Answer: A.CODEOWNERS names the reviewers, and the branch protection rule on main makes their approval mandatory.
2. In Azure Repos, a build must succeed before a pull request can complete. What do you configure?
Show answer
Answer: B.Build validation is a branch policy that queues a pipeline for each pull request and blocks completion until it passes.
3. Your team wants a linear history on main with one commit per pull request. Which merge type do you allow?
Show answer
Answer: B.Squash merge collapses the branch into one commit. Rebase and fast-forward also keep history linear but retain each commit.
4. You need to stop developers from approving their own pull request in Azure Repos. Which policy setting do you use?
Show answer
Answer: B.The minimum reviewers policy has the option Allow requestors to approve their own changes. Turn it off.