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
Splitting into two repositories leaves the binaries in a Git repository that still clones their full history, so clone times and storage are unchanged for that repo. Separation suits access-control or lifecycle boundaries, not reducing the size of binary history.
- ✗
Use git annex to manage large files with a separate store.
Why it's wrong here
git annex stores file content outside the repository and is not natively supported by Azure Repos, so it cannot satisfy the requirement within that platform. It is tempting because it genuinely versions large files with a separate store, which suits self-hosted Git where annex is installed.
- ✗
Use git submodules to reference the large files from another repository.
Why it's wrong here
Submodules point to a specific commit in a separate repository; the binary objects still reside in that repository's history, so clone time and storage are not reduced. Submodules suit sharing a versioned dependency across projects, not offloading large binaries while retaining history in the same repo.
- ✓
Use Git Large File Storage (LFS) to track large files with pointers.
Why this is correct
Git LFS replaces large binaries with small pointer files in the repository while storing the actual content externally, so clones download only pointers plus needed objects. Version history is retained, satisfying the requirement to cut clone times and storage.
Go deeper
Related to this question
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.
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.
About these practice questions
One of 696 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 →
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: Option A is correct because Git LFS (Large File Storage) replaces large binary files in the repository with small pointer files while storing the actual content on a separate LFS server, so the Git object database no longer accumulates massive blobs and stays small over time. Option E is correct because 'git filter-branch' or the newer 'git filter-repo' rewrites history to purge obsolete files (e.g., large blobs or secrets) from all commits, and after the rewritten history is pushed and garbage collection runs, those objects are permanently removed, shrinking the repository. Option B is not correct because squashing commits only consolidates commit metadata and does not remove the underlying file blobs, so it has negligible effect on repository size. Option C is not correct because shallow clones ('--depth') only limit history fetched into a local clone; they do not reduce the size of the remote repository itself. Option D is not correct because 'git gc' compresses and packs existing loose objects and prunes unreachable ones, which optimizes storage but does not eliminate reachable large files or obsolete content still referenced in history.
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.