AZ-400 Question 78
Select 2Your organization� application repository has grown significantly in size due to large media files stored within it. Developers complain about extremely long times to clone or fetch the repository. You have been asked to design and implement a strategy to manage these large files while preserving version history. You are considering Git Large File Storage (LFS) or git-fat as possible solutions. Which two actions should you recommend to achieve this goal?
- A
Create a .gitattributes file to specify and track the large file types handled by Git LFS or git-fat.
- B
Include large files directly in the main repository without any specialized handling to simplify branch workflows.
- C
Use an external storage or artifact store integrated with Git LFS or git-fat for the large files, referencing them in the repository with pointer files.
- D
Rely solely on shallow clones to reduce repository size without altering how large files are stored.
- E
Compress large binary files manually before each commit and store them directly in the repository.
Show answer and explanation
Correct answers: A, C
Explanation
Git LFS and git-fat are solutions designed to handle large files more efficiently by storing them outside the main Git history in a dedicated storage location, while only pointers to those files remain in the repository. Creating a .gitattributes file ensures the correct file types are automatically tracked by Git LFS or git-fat. Integrating these tools with an external artifact store avoids bloating the repository and improves performance for developers. For further details, refer to the official Git LFS documentation at https://git-lfs.github.com and git-fat documentation at https://github.com/jedbrown/git-fat.
- A. Correct.
Option 1 is CORRECT because both Git LFS and git-fat rely on configuration via .gitattributes to identify and track large files by extension or pattern. This approach helps offload large file storage from the main repo history.
- B. Incorrect.
Option 2 is INCORRECT because storing large files directly in the main repository bloat the repo and slow down clone/pull operations. Specialized handling is needed for efficient storage.
- C. Correct.
Option 3 is CORRECT because using an external store (for example, in Azure DevOps Artifacts or another external binary storage) in combination with Git LFS or git-fat allows large files to be accessed via pointers without inflating the repository size.
- D. Incorrect.
Option 4 is INCORRECT because shallow clones only reduce the cloned commit history and do not solve the fundamental issue of large binary files being tracked in Git. Large files would still need to be downloaded eventually.
- E. Incorrect.
Option 5 is INCORRECT because manual compression is error-prone and does not integrate seamlessly with Git workflows. It also complicates version tracking of large binaries and is not a recommended practice for a scalable DevOps solution.