Design and implement a pull request workflow

The two vocabularies

Same intent, different names — and the exam uses both, so read the platform in the question.

What a policy can require

• A minimum number of reviewers
• Linked work items — the traceability chain, enforced
• Comment resolution before completion
• A successful build (build validation)
• Status checks from external services

Automated checks first

Order the workflow so machines run before humans: lint, build and tests should fail before a reviewer spends attention. Human review is the scarcest resource in the pipeline, and spending it on something a linter would have caught is the most expensive kind of waste.

Reviewer count is not quality

Requiring four reviewers produces diffusion of responsibility, not four careful reviews — everyone assumes someone else looked properly. Two is usually the practical maximum, paired with code owners so the right person sees the change rather than merely enough people.

Merge behaviour

Squash produces a tidy linear history and loses individual commits. Merge commits preserve the branch's shape. Neither is universally correct — but pick one and enforce it, because a repository with a mixture is hard to reason about and harder to bisect.

Primary sources

• https://learn.microsoft.com/en-us/azure/devops/repos/git/branch-policies
• https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches