Routing Main Branch Changes Through Security Review with CODEOWNERS and Branch Protection
You have a GitHub repository. You need to ensure that all changes to code are validated by your company’s security department before the main branch is deployed. Which two actions can you perform? Each correct answer presents a complete solution. NOTE: Each correct selection is worth one point.
Community Votes
66% of anonymous learners picked answer DE. Votes are pick records left by other test-takers — they are not the verified answer.
Community Insight
A CODEOWNERS file designates the security department as an owner for the code, and a branch protection rule on main makes code owner approval mandatory, so the two together convert department review into a gate that blocks the merge.
Every change to code must be validated by the security department before the main branch is deployed. The mechanism must both assign the security department as the required reviewers and make that review a hard precondition for merging into main.
Requiring signed commits, which establishes authorship integrity but not departmental review, so a properly signed change could merge without any security department involvement. Protecting the feature branches also fails, because the requirement is specifically about what happens on the main branch.
Community Discussion (4 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
The requirement has two halves that only work together. The CODEOWNERS file identifies the security department as the owners of the code, which is what routes review requests for changes to that department. The branch protection rule on the main branch makes approval by those code owners a required condition for merging, which is what turns departmental review into a gate rather than a suggestion. Since the requirement is that changes are validated before main is deployed, the protection has to be on main. The vote was 57 for D and E and 29 for A and E, and Junak supplied the decisive documentation link showing how CODEOWNERS and branch protection interact.Why the Other Options Are Wrong
Creating a branch protection rule for the feature branches (B) protects the wrong branch, because the requirement is about validation before the main branch is deployed. Feature branch protection controls what happens to contributions before they merge into the feature branch and has no bearing on merges into main. Requiring signed commits (A) is the strongest option for the 29 voters who chose it alongside E, and fuchsm999's objection to it is the correct one: signed commits establish that the change came from a verified author, but they say nothing about whether the security department reviewed the change, so a validly signed change could reach main unreviewed. Creating a LICENSE file (C) has no bearing on review routing or merge gating at all.Community Comment Notes
The community favored D and E at 57 votes against 29 for A and E, and the split is a genuine judgment about what signed commits contribute. fuchsm999, the highest-liked commenter, made the decisive argument against option A by stating that signed commits only matter for who can approve, which is the distinction the question turns on. Junak supplied the authoritative support by linking the GitHub documentation page on CODEOWNERS under branch protection, which documents exactly the pairing of a code owners file with a protection rule. The consensus position is that CODEOWNERS designates the reviewer and branch protection makes the review mandatory, so neither half works alone.Official Reference
Related Analysis
Practice All AZ-400 Questions
Access 100 questions with complete answers and detailed explanations.
View Full AZ-400 Practice Test →