AZ-400 Shallow clone Practice Question
Your team manages a large monorepo in Azure Repos containing multiple projects. Developers frequently complain that cloning the entire repository takes too long and that they only need a subset of the code. The team uses Git LFS for large binary files. The repository currently has 50,000 commits and is 5 GB in size. You want to improve clone performance without sacrificing the ability to contribute to any part of the repo. What should you do?
⚠ Common exam trap
The trap is that candidates may think sparse checkout alone speeds up cloning, but it only affects the working directory after all objects are downloaded. Shallow clone directly reduces the amount of history and data transferred, which is the key factor in clone time.
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
✓
Instruct developers to use a shallow clone with depth 1 to reduce clone time.
Using a shallow clone with depth 1 significantly reduces clone time by fetching only the latest commit history instead of all 50,000 commits. This minimizes the data transferred over the network, which is the primary cause of slow clones. Developers can later deepen the clone if they need more history. Sparse checkout alone does not reduce the data transferred during clone; it only limits what appears in the working directory. Git LFS is already being used for large binaries, so that is not the issue. Splitting the monorepo would require significant restructuring and may complicate cross-project contributions.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Configure sparse checkout so developers can clone only the directories they need.
Why it's wrong here
Sparse checkout configures Git to check out only a subset of files in the working tree, but during the clone operation Git still downloads the entire object database, including all blobs and trees for every commit, because the index and object store are not filtered. The clone transfer size remains unchanged; sparse checkout only saves local disk space and reduces the time needed to populate the working directory. Therefore, it does nothing to improve the network-bound clone time.
- ✓
Instruct developers to use a shallow clone with depth 1 to reduce clone time.
Why this is correct
A shallow clone with `depth 1` retrieves only the latest commit from each branch, omitting the entire commit history and all historical tree and blob objects that are not reachable from that tip. This can shrink the clone payload from many gigabytes to just the snapshot of the latest revision, dramatically cutting clone time. Developers who need older history can later run `git fetch --unshallow` or `git fetch --depth=N` to incrementally download additional commits, and the clone remains a normal repository capable of receiving changes to any part of the monorepo.
- ✗
Move all large binary files to Git LFS to reduce repository size.
Why it's wrong here
Git LFS is already in use in this repo, so the large binary files are already stored outside the pack and referenced by pointer files. Moving additional files to LFS would require a history rewrite to replace existing blobs with pointers, and even then the effect on initial clone is nil because LFS pointers are tiny and the actual blob content is not transferred during clone; it is fetched lazily on checkout. Thus, this action does not reduce the Git pack that dominates clone time and introduces disruptive repository rewriting.
- ✗
Split the monorepo into multiple repositories and use submodules to aggregate them.
Why it's wrong here
Splitting the monorepo and aggregating via submodules increases administrative overhead and breaks atomic cross-project commits, but more importantly it does not reduce total clone time for developers who need more than one project: cloning the superproject alone does not fetch submodule contents, and initializing and updating every submodule requires additional network requests and disk space. In addition, submodule pointers must be carefully synchronized, and a shallow clone of the superproject does not shallow-clone submodules automatically, often causing the same amount of data to be downloaded across multiple repositories.
Go deeper
Related to this question
Learn chapter
Introduction to DevOps and Azure DevOps
Key term
Azure Repos
Azure Repos is a set of version control tools that allow teams to manage their source code, track changes, and collaborate on software projects using Git or Team Foundation Version Control (TFVC) within the Microsoft Azure ecosystem.
Key term
Git
Git is a version control system that tracks changes to files so multiple people can work on the same project without overwriting each other's work.
About these practice questions
This AZ-400 question is part of Courseiva's 823-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
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.