4 of the 8 questions we have for this objective, shown with the answer and the reasoning.
Design and implement branching strategies for the source code
Litware Insurance uses a third-party license compliance service that is not an Azure Pipelines build. When a pull request is opened against main in the Azure Repos repository policy-engine, the service scans the changes and posts its result to the pull request through the Azure DevOps REST API under the status name license-scan with the genre compliance. Pull requests must not be completed until that status reports succeeded.
Which branch policy should you configure on main?
- AA build validation policy that queues the license-scan pipelineBuild validation requires an Azure Pipelines pipeline; the compliance service runs outside Azure Pipelines and reports through the status API.
- BA status check policy (Require approval from additional services) for compliance/license-scan set to RequiredA status check policy blocks pull request completion until an external service posts a succeeded status with the matching genre and name.
- CAn automatically included reviewers policy that adds the compliance service account as a required reviewerA reviewer policy expects an approval vote from an identity, not a status posted by a scanning service, so it does not gate on the scan result.
- DA service hook subscription that triggers the compliance service when a pull request is createdA service hook can notify the service, but it does not block completion; a policy is still needed to enforce the result.
Why: Azure Repos supports two kinds of automated merge gates: build validation for Azure Pipelines runs and status checks for anything else. External tools post a pull request status with a genre and name, and the status check policy references that genre/name pair. Setting the policy to Required means the pull request cannot complete until the latest status is succeeded. A service hook is often used alongside the policy to tell the external service that a pull request changed, but the hook alone enforces nothing.
Design and implement branching strategies for the source code
Relecloud protects main in the Azure Repos repository booking-engine with branch policies that require two reviewers and a successful build validation run. During a production incident, members of the Release Managers group must be able to complete an emergency hotfix pull request without waiting for the required reviewers. All changes, including emergency ones, must still go through a pull request so they are recorded and reviewed afterward, and the exception must follow least privilege.
What should you do?
- AGrant the Release Managers group Allow for Bypass policies when pushing on the main branchBypass policies when pushing lets members push directly to main without a pull request, which violates the requirement that every change goes through a pull request.
- BAdd the Release Managers group to the Project Administrators groupProject Administrators membership grants broad project-wide rights far beyond the need, which violates least privilege.
- CGrant the Release Managers group Allow for Bypass policies when completing pull requests on the main branchThis permission lets members override unmet policies at pull request completion, while the change still flows through a recorded pull request, and scoping it to main limits the exception.
- DChange the minimum reviewers policy to Optional during incidents and set it back afterwardToggling the policy removes protection for every contributor during the incident and depends on someone remembering to restore it.
Why: Azure Repos separates two bypass permissions: one for completing pull requests and one for pushing. Bypass policies when completing pull requests enables the override experience at completion, where the user explicitly selects Override branch policies and enable merge and enters a reason, so the pull request remains the audit trail. Bypass policies when pushing skips the pull request entirely, which is why it is the trap in this scenario. Granting the permission at the branch level to a dedicated group is more precise and safer than elevating the group to an administrator role or weakening the policy for everyone.
Design and implement branching strategies for the source code
Proseware Inc has 40 repositories in a GitHub Enterprise Cloud organization whose names start with svc-. On the default branch of each of them, every commit must be signed and the history must be linear. The rules must apply to everyone, including organization owners and repository administrators. Minimizing administrative effort is the deciding factor, and new svc- repositories must be covered automatically.
What should you configure?
- AA classic branch protection rule on the default branch of each repository with Require signed commits, Require linear history, and Do not allow bypassing the above settingsClassic branch protection is configured per repository, so 40 rules must be created and every new repository needs its own rule, which fails the minimal-effort and automatic-coverage requirements.
- BAn organization ruleset in Evaluate mode that targets repositories matching svc-* and requires signed commits and linear historyEvaluate mode only reports what would have been blocked; it does not enforce the rules.
- CAn organization push ruleset that restricts file paths in svc-* repositoriesPush rulesets restrict file paths, extensions, and sizes in pushes; they do not require signed commits or linear history on a branch.
- DAn organization branch ruleset with Active enforcement that targets repositories matching svc-* and the default branch, enables Require signed commits and Require linear history, and has an empty bypass listAn organization ruleset applies to every current and future repository matching the name pattern, Active enforcement blocks violations, and an empty bypass list means owners and admins are also bound.
Why: Rulesets are the preferred GitHub mechanism for new merge restrictions because one organization-level ruleset can target many repositories by name pattern. Unlike classic branch protection, rulesets only allow bypass for actors explicitly added to the bypass list, so leaving it empty enforces the rules for administrators too. Enforcement status matters: Evaluate is for testing impact and does not block. Require signed commits and Require linear history are both available as branch rules in a ruleset.
Design and implement branching strategies for the source code
Adatum Software hosts a repository named mobile-sdk in a GitHub Enterprise Cloud organization. The security team at @adatum/appsec must approve every pull request into main that changes anything under crypto/, and the platform team at @adatum/platform must approve changes to .github/workflows/. No ruleset or branch protection exists yet for the repository, and the team wants the current recommended GitHub feature for new setups.
What should you implement?
- AAdd the two teams as required reviewers in a pull request template file in .github/PULL_REQUEST_TEMPLATE.mdA pull request template only pre-fills the description text; it cannot request or require reviews from any team.
- BCreate a CODEOWNERS file that maps crypto/ to @adatum/appsec and .github/workflows/ to @adatum/platform, and create a branch ruleset on main that requires a pull request with Require review from Code Owners enabledCODEOWNERS maps paths to owning teams and automatically requests their review, and the ruleset's code owner review requirement makes that approval mandatory before merging into main.
- CCreate a CODEOWNERS file that maps the paths to the two teams without any ruleset or branch protectionWithout a rule that requires code owner review, CODEOWNERS only requests reviews; the pull request can still be merged without the owners' approval.
- DCreate a push ruleset that blocks pushes changing crypto/ and .github/workflows/A push ruleset blocks matching file changes outright; it does not provide an approval path for the owning teams.
Why: In GitHub, path-based ownership is split into two parts: the CODEOWNERS file says who owns which paths, and a rule says whether their approval is required. Rulesets are the recommended way to add that rule for new configurations because they can be layered, viewed by anyone with read access, and scoped across many branches or repositories. Enabling Require review from Code Owners on a pull request rule turns the automatic review request into a merge gate. Push rulesets restrict file paths, sizes, and extensions in pushes, which is a different control.