Design and implement a source control strategy →mediumMultiple Select

AZ-400 Practice Question: Design and implement a source control strategy

Which THREE practices are recommended for effective source control in a GitHub monorepo? (Choose three.)

⚠ Common exam trap

Watch out — candidates often confuse 'monorepo best practices' with 'single repo simplicity' and incorrectly assume a single build definition is efficient, when in reality path-filtered, modular CI is essential to avoid unnecessary builds and long feedback loops.

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

✓

Use branch protection rules to enforce CI checks

Option B is correct because branch protection rules on a monorepo's shared branches (e.g., main) can require status checks from CI workflows to pass before merging, preventing broken code from entering a repository that many teams depend on. Option D is correct because a CODEOWNERS file maps paths to owners and automatically requests the appropriate reviewers for pull requests, which is essential in a monorepo where different directories belong to different teams. Option E is correct because path filters (e.g., the paths: key in GitHub Actions workflow triggers) ensure that a change in one project only runs the CI workflows relevant to that path, avoiding unnecessary builds across the whole monorepo. Option A is not recommended because large binaries bloat repository history and should instead be handled with Git LFS or external artifact storage, and option C is not recommended because a single build definition for all projects reduces isolation and forces unrelated projects to rebuild together, whereas per-project or path-filtered build definitions are preferred.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
Store large binary files directly in the repository
Why it's wrong here
Git repositories store full history of every blob; adding large binaries permanently inflates repo size, making clones and fetches slow for every team member, and can hit storage limits. Use Git LFS or external artifact storage instead.
✓
Use branch protection rules to enforce CI checks
Why this is correct
Branch protection rules on the main branch require status checks to pass before merging, so every pull request in the monorepo is validated by CI. This enforces the stem's requirement for effective source control practise in a GitHub monorepo.
✗
Use a single build definition for all projects
Why it's wrong here
A single monolithic build definition forces every project to build on every change, creating long pipelines, unrelated failures, and slow feedback; instead, use separate build definitions or multi-job pipelines with path filters to build only what changed.
✓
Use code owners to automatically request reviewers
Why this is correct
A CODEOWNERS file maps paths to teams, so GitHub automatically requests the right reviewers when a pull request touches those paths. This satisfies the stem's requirement for effective source control practise in a large GitHub monorepo.
✓
Use path filters to trigger only relevant CI workflows
Why this is correct
Path filters scope each workflow to the directories it owns, so a change in one project triggers only its relevant pipeline. This satisfies the monorepo requirement by cutting redundant builds and keeping CI feedback fast across many co-located projects.

Go deeper

AZ-400 Practice Question: Design and implement a source control strategy

Why each option matters

Option-by-option breakdown

Related to this question