AZ-400 Question 77
Select 2Your organization is developing a media application that requires storing multiple large video and image files in a Git repository hosted on Azure Repos. Over time, the repository size has grown significantly, causing performance issues and long clone times. You need to implement a strategy that ensures future large files are handled appropriately while also reducing the repository� existing footprint. Which two strategies should you implement?
- A
Use Git LFS to track and store large files, so the repository references pointers instead of the actual binaries.
- B
Add a .gitignore entry for large files to prevent any file above 100 MB from being committed.
- C
Rewrite repository history (for example, by using git filter-branch or git filter-repo) to remove previously committed large files, then push the cleaned repository.
- D
Push large files to an external file server or shared folder, but keep symbolic links pointing to those files in the repository.
- E
Compress large files manually before committing them to the repository.
Show answer and explanation
Correct answers: A, C
Explanation
Using Git LFS (Option 1) is a best practice for large file management in Git-based workflows and is well-documented in both Microsoft and GitHub documentation. Rewriting your repository� history (Option 3) is also critical to remove large files that have already been committed, thereby reducing overall repo size. These two strategies combined ensure your repository remains efficient and manageable for a DevOps environment. For additional details, consult the Git LFS documentation (https://git-lfs.github.com/) and official Microsoft guidance on managing large files in Azure Repos.
- A. Correct.
Option 1 is correct. By using Git Large File Storage (LFS), you can keep the actual large file content in a specialized storage while only pointers are tracked in your repository. This helps maintain a smaller repository size and faster clone times.
- B. Incorrect.
Option 2 is incorrect. While .gitignore might prevent committing new large files, it does not handle the existing large files in your repo or the need to maintain version control on them. Ignoring files also means you lose them entirely in repo history going forward, which is not always desired.
- C. Correct.
Option 3 is correct. Rewriting the repository history to remove previously committed large files can significantly reduce the size of your repository. This step is often done along with enabling Git LFS for handling future commits of large files, ensuring you do not reintroduce them into the main repo.
- D. Incorrect.
Option 4 is incorrect. Simply pushing large files to an external file server and referencing them via links might solve the storage issue but does not maintain an integrated version control workflow, which is often crucial for DevOps processes that require traceability and continuous integration. Additionally, it complicates collaboration, as references can break if the external server path changes.
- E. Incorrect.
Option 5 is incorrect. Compressing files manually before committing can help reduce size somewhat, but it doesn't address the drift in version control or repository bloat over time�especially for media assets that will be updated frequently. Git LFS or a history rewrite is more effective and maintainable.