AZ-400 Practice Question: Design and implement a source control strategy
Your Azure DevOps repository contains a large binary file that is slowing down clone operations. Which Git feature should you use to reduce the clone time?
⚠ Common exam trap
Candidates often confuse shallow clones or sparse checkouts as solutions for large files, when in fact those features address history depth or working tree scope, not the fundamental problem of large binary objects being stored and transferred in the repository.
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
✓
Git LFS (Large File Storage)
Git LFS (Large File Storage) is the correct solution because it replaces large binary files in the repository with lightweight text pointers, storing the actual binary content in external remote storage. This prevents the large file from being downloaded during every clone, significantly reducing clone time and repository size on disk.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Shallow clone
Why it's wrong here
Shallow clone limits the number of commits in history (e.g., --depth 1), reducing clone time and metadata, but it does not affect how Git stores the working tree files themselves. The large binary file remains fully materialized in the repository, so the file size problem persists.
- ✓
Git LFS (Large File Storage)
Why this is correct
Git LFS replaces large binary files with text pointers in the Git repository, storing the actual file content in a separate remote LFS store. On clone/checkout, pointers are swapped for the real files, which keeps the Git database small and prevents repository bloat.
- ✗
Depth parameter in clone command
Why it's wrong here
The --depth option on git clone is essentially a shallow clone, truncating commit history depth to speed up cloning and reduce download size of commit objects. However, it does nothing to reduce the size of a large binary file that already resides in the current commit's tree, so the file still occupies the same amount of disk space.
- ✗
Sparse checkout
Why it's wrong here
Sparse checkout lets you check out only specific folders or files from the repository, limiting the working directory contents, but the large binary file still exists in the Git object database and is downloaded as part of the clone. Thus it doesn't reduce the repository's overall size or the storage impact of that binary file.
Go deeper
Related to this question
Learn chapter
Introduction to DevOps and Azure DevOps
Key term
Azure DevOps
Azure DevOps is a Microsoft service that provides development tools for planning, building, testing, and deploying software applications using automated pipelines and collaboration features.
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
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 →
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.