Committing a 3-GB ZIP of VM Images to Git with Git LFS and Azure Blob Versioning

Configure and manage repositories

Answer Correct answer: B, E — Git LFS keeps a pointer in each commit so the 3-GB ZIP stays versioned and commit-linked, and Azure Blob versioning retains the stored content.

You use Git for source control. You need to commit a 3-GB ZIP file that contains virtual machines used for testing. The solution must meet the following requirements: • The file must be versioned. • The file must be associated with the corresponding code commits. Which two actions should you include in the solution? Each correct answer presents part of the solution. NOTE: Each correct selection is worth one point.

Install the git-fat extension and associate the extension to ZIP files.
Install the Git LFS extension and associate the extension to ZIP files. Correct Answer
Install the git-stash extension and associate the extension to ZIP files.
Use GZip to compress the file before committing the file.
Store files in Azure Storage and enable blob versions. Correct Answer

Community Votes

50%

30%

20%

50% of anonymous learners picked answer BE. Votes are pick records left by other test-takers — they are not the verified answer.

Community Insight

Git LFS replaces the large binary content in the repository with a pointer and stores the actual content in a separate LFS backend, which keeps the file versioned and tied to the commit that introduced it. Azure Blob versioning supplies independent version retention for the stored content itself.

A 3-GB ZIP file containing virtual machine images for testing must be committed to Git, and the solution must both version the file and associate it with the corresponding code commits. A ZIP is a large binary blob, so ordinary Git tracking of the raw content is impractical and must be offloaded while keeping the commit association intact.

Using GZip to compress the file before committing. Compression reduces bytes on disk but the blob is still committed into the Git object database, so it does not solve the repository bloat problem and it corrupts the VM images since ZIP is already compressed.

Community Discussion (8 comments)

Rafi786_khan 👍 11

Answer: B & E Explanation: Git LFS (Large File Storage): This extension is specifically designed for handling large files within a Git repository. It stores the file contents in a separate backend (e.g., GitHub LFS servers), while only storing a pointer to the file within the Git repository itself. This significantly reduces the repository size and improves versioning performance. Associating the ZIP file extension with Git LFS ensures automatic handling of large files. Azure Storage with Blob Versions: This approach stores the actual 3GB ZIP file in Azure Storage, not the Git repository. By enabling blob versions, you maintain version history for the file, allowing you to revert to previous versions if needed. This solution keeps the Git repository lightweight while maintaining version control for the large file.

dddddddddddww12 👍 2 Selected: AB

The git-fat extension is a tool for managing large files in Git repositories by offloading their content to an external storage system while keeping lightweight references in the Git repository. This allows Git to manage large files more efficiently without bloating the repository size.

UrbanRellik 👍 2 Selected: BE

B to handle the large file E to handle the storage and versioning.

FeriAZ 👍 2 Selected: BE

1. Install the Git LFS (Large File Storage) extension and associate the extension to ZIP files. Git LFS is designed specifically for handling large files in Git repositories. It stores the large file content (the 3-GB ZIP in this case) outside the main Git repository, typically on a server. Git LFS keeps track of the file using a pointer within the repository, ensuring versioning and association with the corresponding code commits. 2. Use GZip to compress the file before adding it to Git LFS. While not strictly necessary for Git LFS functionality, compressing the ZIP file with GZip can further reduce its size before storing it externally. This can optimize storage space and potentially reduce upload/download times.

mcabrito 👍 3 Selected: BD

I believe the BD option is the right choice because at the beginning of the question, it states: 'You use Git for source control.' So, to me, it doesn't make sense to send the file to Azure Storage since it has no relation to Git whatsoever. I understand that it's an option for versioning the file, but in my opinion, this option doesn't align with the context of the question. Therefore, if this question appears on my exam, I will select options BD.

TheMCT 👍 1 Selected: BE

B & E, correct answer

Tuki93 👍 1

https://learn.microsoft.com/en-us/azure/devops/repos/git/manage-large-files?view=azure-devops

Rkmylambton 👍 4

It is not mentioned where we are going to save file. Github LFS Server or Azure Storage. I think B and D can be option.

Comments & Corrections

No comments yet — spotted an error or have a note? Share it below.

Expert Analysis

Why the Answer Is Correct

Two requirements must both be satisfied: the 3-GB ZIP must be versioned, and it must be associated with the corresponding code commits. Git LFS is purpose-built for large files in Git: it stores the file content in a separate LFS backend and keeps only a lightweight pointer in the repository, and because the pointer lives in the commit, every commit that references the file records a specific version of it, which satisfies the commit association requirement. Storing the files in Azure Storage with blob versions enabled provides the second layer, retaining versioned copies of the stored content independently of Git. The vote was 50 for B and E. Rafi786_khan gave the fullest explanation of the Git LFS pointer mechanism, and FeriAZ and UrbanRellik both split the two requirements across the two actions, with Git LFS handling versioning inside Git and blob versioning handling retention in storage.

Why the Other Options Are Wrong

Installing the git-fat extension (A) was chosen by 20 voters, but git-fat is a third-party extension that predates Git LFS and is not the tool the exam treats as the standard large-file solution; Git LFS is the officially supported and documented mechanism, and Tuki93 linked the Microsoft manage-large-files documentation in support of that. Using GZip to compress the file before committing (D) is the most tempting mistake because ZIP content is already compressed, so GZip yields almost no size reduction, and critically the blob is still written into the Git object database, so the repository remains bloated and the requirement is not met. Storing files in Azure Storage alone without Git LFS (E) satisfies versioning through blob versions but leaves the file unassociated with the commits, which is why both selections are required rather than either one alone.

Community Comment Notes

The community favored B and E at 50 votes, with D at 30 and A at 20, so this was a genuine three-way contest. Rafi786_khan with eleven likes was decisive, explaining that Git LFS stores content separately while keeping a pointer in the repository, which preserves versioning and commit association. The dissent is substantive rather than noise: Rkmylambton argued for B and D since the question never specifies a storage location, and mcabrito argued for B and D on the grounds that the question opens by saying you use Git for source control, so sending the file to Azure Storage seems out of context. Those two readings are reasonable, but neither satisfies the explicit versioning requirement the way blob versioning does.

Official Reference

https://learn.microsoft.com/en-us/azure/devops/repos/git/manage-large-files?view=azure-devops

Related Analysis

Practice All AZ-400 Questions

Access 100 questions with complete answers and detailed explanations.

View Full AZ-400 Practice Test →

← Back to AZ-400 Study Guide