Question 238 of 823
Reducing Repository Size with Git LFS While Keeping Full Version History
Your team uses Azure Repos and has a repository with a large number of binary files (e.g., images, compiled libraries) that bloat the repository size. You want to reduce clone times and storage usage while still maintaining version history for those files. Which approach should you recommend?
Quick Answer
Git LFS is the standard fix for a repo bloated with binaries: it replaces large files with lightweight text pointers in the actual Git history while storing the real file content in a separate LFS store, keeping clones fast and repo size small without losing any version history for those files — and it integrates natively with Azure Repos.
⚠ Common exam trap
Test-takers frequently confuse git submodules or repo splitting as valid solutions for large files, but they fail to realize that those approaches do not actually reduce clone times or storage usage for the binary files themselves—they only reorganize the problem.
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 Git Large File Storage (LFS) to track large files with pointers.
Git LFS (Large File Storage) replaces large binary files in the repository with text pointers, while storing the actual file content in a separate remote store. This keeps the repository lightweight for cloning and fetching, but still preserves the full version history of the binary files because each pointer references a specific version in the LFS store. It integrates natively with Azure Repos and requires minimal workflow changes.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Split the repository into two: one for code and one for binaries.
Why it's wrong here
This is a valid approach but not as seamless as Git LFS.
- ✗
Use git annex to manage large files with a separate store.
Why it's wrong here
git annex is not natively supported in Azure Repos.
- ✗
Use git submodules to reference the large files from another repository.
Why it's wrong here
Submodules do not reduce the main repo size.
- ✓
Use Git Large File Storage (LFS) to track large files with pointers.
Why this is correct
Git LFS is supported and reduces clone size.
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 →
Same concept, more angles
4 more ways this is tested on AZ-400
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. Your company is migrating from TFVC to Git in Azure Repos. The repository contains a large number of binary files (e.g., .dll, .exe) that are frequently updated. You need to minimize repository size and clone time. What should you include in your migration plan?
hard- A.Perform a shallow clone of the last commit only.
- ✓ B.Use Git LFS to track binary files.
- C.Use sparse checkout to exclude binary files from the working tree.
- D.Use TFVC to Git converter with default settings.
Why B: Git LFS (Large File Storage) replaces large binary files in the repository with lightweight text pointers, storing the actual binary content in external storage. This prevents the repository from bloating with frequently updated binaries, reducing clone time and repository size since only the pointers are cloned.
Variation 2. Which TWO benefits does using Git LFS (Large File Storage) provide? (Select TWO.)
medium- A.Automatically compresses all files in the repository
- ✓ B.Prevents large files from being stored in the Git history
- C.Replaces .gitignore for excluding large files
- D.Speeds up diff operations for binary files
- ✓ E.Reduces the size of Git repositories by storing large files as pointers
Why B: Git LFS (Large File Storage) prevents large files from being stored directly in the Git repository history (option B). Instead, it stores a small pointer file in the repo while the actual large file content is stored externally, which reduces the size of the Git repository (option E). Options A, C, and D are incorrect because LFS does not automatically compress all files, replace .gitignore, or speed up diff operations for binary files.
Variation 3. Which TWO options are benefits of using Git LFS (Large File Storage) in a team environment? (Select TWO.)
medium- ✓ A.Prevents large files from being stored in the Git history
- B.Automatically detects and tracks all binary files in the repository
- ✓ C.Reduces the size of Git repository clones and fetches for team members
- D.Works only with GitHub and Azure Repos
- E.Eliminates the need for Git when working with large binary files
Why A: Git LFS replaces large files in the repository with text pointer files, while the actual file content is stored in a separate remote store. This prevents the large files from bloating the Git history, which would otherwise permanently increase repository size for all clones and fetches.
Variation 4. Which TWO actions help reduce the size of a Git repository over time?
medium- ✓ A.Use Git LFS for large binary files.
- B.Squash commits before pushing to the remote.
- C.Perform shallow clones when cloning the repository.
- D.Regularly run 'git gc' to compress objects.
- ✓ E.Use 'git filter-branch' or 'git filter-repo' to remove obsolete files from history.
Why A: Git LFS (Large File Storage) replaces large binary files with text pointers in the repository, storing the actual binary content in an external server. This prevents the repository from bloating with large files that are stored in full in every commit, significantly reducing the repository size over time. Similarly, using 'git filter-branch' or 'git filter-repo' allows you to rewrite history to permanently remove obsolete files or sensitive data from previous commits, so those objects are no longer stored in the repository's history. Both actions directly reduce the total size of the repository by eliminating or externalizing file content, unlike shallow clones or commit squashing, which do not reduce the remote repository size, and 'git gc', which only compresses objects without removing reachable content.
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.