AZ-400 - Design and Implement a Source Control Strategy (13% of the exam) - Section 2.3

Configure and manage repositories, including large file storage, repository scaling, permissions, tags, and recovery or removal of specific data.

Configure Git Large File Storage and Scalar to keep repositories performant as binary assets and history grow, and apply repository permissions and Git tags to organise and protect content. Use git filter-repo to permanently remove sensitive data or large files from history when recovery or remediation is required.

Git Large File StorageScalarrepository permissionsgit filter-repoGit tags

Practice question for this objective

Free sampleDesign and Implement a Source Control Strategyhard

A team committed a 900-megabyte training dataset into a Git repository many commits ago and later deleted it from the working tree, but every clone still transfers the giant blob because it remains in history. There is no secret in the file; the sole goal is to reclaim repository size by purging that one large path from every commit. Which approach most directly shrinks the repository by removing the blob from all history?

ARun "git filter-repo" with a path filter that excludes the dataset file so it is stripped from every commit, then force-push the rewritten history and have the team re-clone the slimmed repository. Correct
BRun "git gc --aggressive" and "git prune" so the object database is repacked and unreferenced objects are removed, which reclaims the space the large dataset blob occupied across the repository history.
CAdd the dataset path to a "gitignore" entry and commit the change so Git stops tracking the file, which removes the existing large blob from history and reduces the size of subsequent clones.
DCreate a shallow clone with a depth of one and push it as the new default so only the latest commit and its objects remain, discarding the deep history that carried the large dataset blob.

Use git filter-repo with a path filter to remove a large file from all history and reclaim repository size, not just delete it from the tip. A large blob committed long ago stays reachable from every old commit, so ordinary deletion or garbage collection cannot reclaim its space. git filter-repo rebuilds each commit without the target path, producing new hashes that no longer reference the blob; a force-push and re-clone then realise the size reduction across the team.

Why A is correct: The path filter rewrites every commit without the targeted file, which expunges the large blob from all history and is the supported way to reclaim repository size before re-cloning.

Why B is wrong: Aggressive garbage collection only repacks and prunes objects that nothing references, but the dataset blob is still reachable from old commits, so it survives and the repository stays large.

Why C is wrong: A gitignore entry only prevents future tracking of an untracked path and tempts by seeming to remove the file, but it leaves every historical commit and its blob untouched, so clones stay bloated.

Why D is wrong: A shallow clone truncates history locally but cannot be pushed as a complete replacement, and doing so would discard all legitimate history, so it is the wrong tool for surgically purging one path.

See more AZ-400 practice questions, answers explained.

Exam traps in Design and Implement a Source Control Strategy

Answers that look right on this material and are not. Each one is a distractor from a different question in the AZ-400 bank for this domain.

Add the binary patterns to a "gitattributes" file at the repository root and recommit it, so Git retroactively rewrites the matching blobs in earlier commits into Large File Storage pointers on the next push.
Why it is wrong: A gitattributes entry only governs how files are handled from the commit it is added onwards, so it tempts by looking like the LFS switch but never rewrites blobs already sitting in earlier commits.
Enable shallow clones for everyone with a depth of one so each checkout pulls only the latest commit, which keeps the large binary history out of every developer's working copy.
Why it is wrong: A shallow clone reduces history depth but still downloads each large blob present in that single commit, and it cripples branching and history operations, so it does not properly version the binaries.
Run "git revert" against the offending commit so a new commit undoes the change, which removes the secret from the current tree while preserving the original commit for audit purposes.
Why it is wrong: A revert only adds a compensating commit on top, so the connection string still exists in the earlier commit's history and can be read by anyone checking out that commit.

Examworthy is not affiliated with or endorsed by Microsoft. Original, blueprint-aligned practice material only.