Question 87 of 823
AZ-400 Practice Question: Design and implement a source control strategy
Your organization uses GitHub Enterprise and wants to enforce that all repositories have a consistent CODEOWNERS file. Which approach should you use to centrally manage this?
⚠ Common exam trap
The trap is that candidates assume organization-level CODEOWNERS does not exist, or believe rulesets can enforce file existence. In reality, a .github repository with a CODEOWNERS file serves as the organization-wide default, while rulesets are not designed for this.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Create a CODEOWNERS file at the organization level
In GitHub Enterprise, you can create a special repository named `.github` at the organization level. A CODEOWNERS file stored in that repository is applied as a default to all repositories in the organization, providing centralized management. Repository rulesets cannot require that a file exists; they enforce branch/tag rules such as required reviews and status checks, but not file existence.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Use repository rulesets to require that the CODEOWNERS file exists and has a specified pattern
Why it's wrong here
Repository rulesets in GitHub Enterprise can enforce branch protections, including requiring specific files to exist with defined content. By configuring a ruleset that mandates the CODEOWNERS file at the repository root and matches a valid owner syntax, it blocks any push that fails the requirement, providing centralized, enforceable policy across all repositories.
- ✓
Create a CODEOWNERS file at the organization level
Why this is correct
CODEOWNERS is repository-specific; GitHub does not support an organization-level CODEOWNERS file that applies across repositories. Placing it at the organization level would have no effect on individual repository's code review ownership, so each repo must still contain its own file.
- ✗
Use a script to push CODEOWNERS to each repo manually
Why it's wrong here
A manual script to push CODEOWNERS to each repo is a one-time or ad-hoc action that provides no ongoing enforcement. New repositories would be missed, and there is nothing preventing subsequent pushes from removing or altering the file, so it cannot guarantee the requirement is continuously met.
- ✗
Create a GitHub Actions workflow that runs on push to check CODEOWNERS
Why it's wrong here
A GitHub Actions workflow that runs on push only observes the repository after the push has been accepted, so it cannot block or prevent the push itself. It may flag the missing file or post a comment, but it provides no pre-receive enforcement and can be bypassed by direct pushes or workflow misconfigurations, which is why rulesets or pre-receive hooks are necessary.
About these practice questions
Courseiva creates original exam-style practice questions with explanations and wrong-answer analysis. It does not publish real exam questions, exam dumps, or protected exam content. Learn why practice questions differ from exam dumps →
Last reviewed: Jun 25, 2026
This AZ-400 practice question is part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the AZ-400 exam.
Question Discussion
Share a tip, memory trick, or ask about the reasoning behind this question. Do not post real exam questions, leaked content, braindumps, or copyrighted exam material. Comments are moderated and may be removed without notice.
Sign in to join the discussion.