AZ-400 Practice Question: Design and implement a source control strategy
Which TWO actions help reduce the size of a Git repository over time?
⚠ Common exam trap
Many candidates confuse 'reducing repository size' with 'improving performance' or 'reducing clone time', leading them to select shallow clones or commit squashing as valid answers, when in fact only actions that remove or externalize file content (like LFS or history rewriting) actually shrink the repository size.
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 LFS for large binary files.
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.
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 for large binary files.
Why this is correct
Git LFS reduces repository size by replacing large binary files with lightweight text pointers in the commit graph, while the actual file content is stored on a separate LFS server. During clone or fetch, only these pointers are transferred, so the Git object database never contains the bulky binary blobs. This keeps the repository lean and prevents the historical growth that would otherwise occur with frequently updated binary assets.
- ✗
Squash commits before pushing to the remote.
Why it's wrong here
Squashing combines multiple commits into one, but all file versions from the original commits remain in the object database until garbage collected; it does not actually delete historical blobs, so the repository size is not meaningfully reduced.
- ✗
Perform shallow clones when cloning the repository.
Why it's wrong here
A shallow clone limits local history depth, but the remote repository still holds all blobs and commits; it only reduces the local clone's size, not the size of the repository being shared or pushed to.
- ✗
Regularly run 'git gc' to compress objects.
Why it's wrong here
'git gc' packs loose objects and prunes unreachable ones, but it does not drop blobs that are reachable from any commit; since all historical file versions are reachable, gc only compresses them and does not reduce the overall logical repository size.
- ✓
Use 'git filter-branch' or 'git filter-repo' to remove obsolete files from history.
Why this is correct
Using `git filter-branch` or `git filter-repo` rewrites the entire commit history to permanently remove specified files from every commit, making those blobs unreachable from any ref. After a forced push and garbage collection, the obsolete objects are pruned, which actually shrinks the repository size by eliminating the data from the object database itself. This is a one-way, history-rewriting operation suitable for removing accidentally committed large binaries or secrets.
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
Branch
A branch is a pointer to a specific commit in a version control system that allows you to work on features or fixes in isolation from the main codebase.
About these practice questions
This AZ-400 question is part of Courseiva's 696-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.