Courseiva
Design and implement a source control strategyhardMultiple ChoiceObjective-mapped

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

Your company uses Azure DevOps and has a large monorepo with multiple teams. Developers report that Git operations are slow due to the repository size. Which approach should you recommend to improve performance while maintaining a single repository?

⚠ Common exam trap

It's easy for candidates to confuse performance improvements with repository restructuring, assuming that splitting the repo (Option B) is the only way to speed up Git, when Azure DevOps supports native Git features like sparse checkout and shallow fetch that preserve the monorepo architecture.

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

Enable sparse checkout and shallow fetch

Sparse checkout and shallow fetch are designed to improve Git performance in large monorepos by limiting the working tree to specific directories (sparse checkout) and reducing the history depth (shallow fetch). This keeps the repository intact as a single unit while significantly reducing the amount of data transferred and stored locally, directly addressing the slow Git operations without breaking the monorepo structure.

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 Git LFS to store all files

    Why it's wrong here

    Git LFS is intended for large binary files, not every file in a repository. Storing all files in LFS replaces blobs with lightweight pointers, increasing complexity and requiring extra LFS API calls, and it does not reduce the number of commits or objects transferred during clone/fetch for typical text-based code.

  • Split the monorepo into multiple smaller repositories

    Why it's wrong here

    Splitting a monorepo into multiple repositories changes the source-control topology rather than improving Git's clone/fetch efficiency; it introduces cross-repository versioning, dependency management, and pipeline complexity, and would require significant refactoring. For an existing large monorepo, a Git-level solution like sparse checkout and shallow fetch is more appropriate.

  • Add a .gitattributes file with filter directives

    Why it's wrong here

    A .gitattributes file controls file attributes such as line endings, diff drivers, and clean/smudge filters, but it does not change what Git transfers during clone or fetch operations. Filter directives operate after retrieval, so they do not reduce the number of objects or history depth, and therefore do not improve clone/fetch speed.

  • Enable sparse checkout and shallow fetch

    Why this is correct

    Sparse checkout restricts the working tree to only the directories or files you actually need, reducing checkout time and disk usage. Shallow fetch with a depth limit downloads only the most recent commits, drastically reducing the number of objects transferred; combined, these are the standard Git techniques to speed up work with a large monorepo.

About these practice questions

One of 823 original AZ-400 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

JA

Written by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

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.