ExamworthyExamworthy
Open the appStart free

AZ-400 - Design and Implement a Source Control Strategy - 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.

More in this domain

Back to all Design and Implement a Source Control Strategy objectives, or the AZ-400 cert hub.

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