Practice Test 2 | Designing And Implementing Microsoft DevOps Solutions | AZ-400 | Dumps | Mock Test
Your company has a website which is dealing with high quality images and videos. You have multiple designers and developers working on the project. Frequent updates are being made to the source files. It has been notified that there is a dramatic increase in the time to check out, branch, fetch, clone, etc.
You decided to make use of the Git Large File Storage (LFS) extension to manage these large binary files.
Which one of the following Git LFS does not support?
A. File locking which lets developers lock files to prevent others from concurrent updates
B. Authentication using Personal access tokens to Azure DevOps
C. Drag and drop a binary file to Azure Repo.
D. Migrate existing repository data to LFS.
- Option A is incorrect. Git LFS v2.0.0. supports file locking. File locking lets developers lock files that they are updating to prevent users from updating them at the same time. This helps in avoiding merge conflicts. These are very difficult to resolve in large binary files. The git LFS track command includes a –lockable flag which can be used for this purpose.
- Option B is incorrect. The local Git repository can be connected to Azure Repos. It can be authenticated by using personal access tokens. Azure Repos currently does not support SSH in Repos with Git LFS tracked files. Personal access token is the recommended approach.
- Option C is correct. The working principle of Gif LFS is to replace large files with text pointers inside Git when storing file contents on a remote server. A user drags and drops a binary file via the web interface into a Repo which is configured for Git LFS. Then the binary will be committed to the Repo and not the pointers that would be committed via the Git LFS client.
- Option D is incorrect. When converting an existing Git repository to use Git LFS, it ships with a git LFS migrate command that allows such migrations. Also, files end up being committed within your repository when they should have been committed with LFS. This migrate command can be used.
- Reference Link: For more information on managing large binary files, please refer to the below link from Microsoft- https://docs.microsoft.com/en-us/azure/devops/repos/git/manage-large-files?view=azure-devops#strategies-for-working-with-large-binary-source-files
Comments are closed, but trackbacks and pingbacks are open.