AZ-400 - Design and Implement a Source Control Strategy (13% of the exam) - Section 2.2

Design and implement a pull request workflow and merge restrictions using branch policies and branch protection rules.

Design a pull request workflow that enforces code quality through branch policies in Azure Repos and branch protection rules in GitHub, including required reviewers, status checks, and merge restrictions. Distinguish the capabilities of each platform so you can configure the right guard for the repository host in use.

branch policiesbranch protection rulespull request workflowrequired reviewersstatus checks

Practice question for this objective

Free sampleDesign and Implement a Source Control Strategymedium

An organisation is migrating one team's repository from "Azure Repos" to "GitHub" but wants to keep an equivalent merge gate: pull requests into the protected branch must collect required reviews and pass required checks. Which capability provides the same enforcement that branch policies gave them in Azure Repos?

  • AAzure Pipelines environment approvals, which pause a deployment until a named approver signs off and therefore hold each pull request until the required reviews and checks are satisfied.
  • BA repository ruleset scoped to tags, which applies required reviews and checks to tag creation and therefore enforces the same gate when a pull request is merged into the protected branch.
  • CGitHub Actions workflow permissions set to read and write, which let the build workflow approve its own pull requests once the required reviews and checks have completed successfully.
  • DGitHub branch protection rules, or repository rulesets, on the protected branch that require pull request reviews and required status checks before a merge is permitted. Correct
Recognise GitHub branch protection rules and rulesets as the equivalent of Azure Repos branch policies for gating pull request merges. Azure Repos enforces pull request gates with branch policies, while GitHub uses branch protection rules or the newer repository rulesets on the protected branch. Both enforce required reviewer approvals and required status checks before a merge, providing the same merge restriction model across the two platforms.

Why A is wrong: Environment approvals gate deployments to an environment, not pull request merges; the wording is tempting because it mentions approvers, but it operates after merge during release, not on the pull request.

Why B is wrong: Rulesets can target tags, which sounds plausible, but a tag-scoped ruleset governs tag operations rather than branch merges, so it would not gate pull requests into the protected branch.

Why C is wrong: Workflow permissions control what the workflow token can do in a run; it is tempting because it touches Actions, but it does not enforce any merge gate and a workflow cannot satisfy required human reviews.

Why D is correct: Branch protection rules and rulesets are the GitHub equivalent of Azure Repos branch policies, enforcing required reviews and required status checks on merges into the protected branch.

See more AZ-400 practice questions, answers explained.

Exam traps in Design and Implement a Source Control Strategy

Answers that look right on this material and are not. Each one is a distractor from a different question in the AZ-400 bank for this domain.

  • Enable an Azure Repos build validation policy that points at the GitHub Actions workflow, so the policy queues the workflow and blocks completion until it reports success.

    Why it is wrong: Build validation policies belong to Azure Repos, not GitHub; the wording is tempting because it gates on a build, but it cannot be applied to a GitHub repository or its Actions workflow.

  • Enable the require a minimum number of reviewers policy and instruct reviewers to reject any pull request whose author has not manually squashed the source branch before requesting completion.

    Why it is wrong: Minimum reviewers gates on approval count and is tempting because reviewers could police the merge type, but it relies on human discipline and cannot technically restrict which completion merge type the author selects.

  • Enable the require status checks to pass before merging option and select the continuous integration check, since re-running the build on each push forces reviewers to look at the new commits again.

    Why it is wrong: Required status checks re-run the build on new commits and are tempting because they react to a push, but they gate on a build result and never invalidate a human approval, so a stale review still counts.

Examworthy is not affiliated with or endorsed by Microsoft. Original, blueprint-aligned practice material only.