Courseiva
Design and implement a source control strategyhardMultiple ChoiceObjective-mapped

AZ-400 Practice Question: Design and implement a source control strategy

Your company is migrating from TFVC to Git in Azure Repos. The repository contains a large number of binary files (e.g., .dll, .exe) that are frequently updated. You need to minimize repository size and clone time. What should you include in your migration plan?

⚠ Common exam trap

It's easy for candidates to confuse sparse checkout (which only affects the working tree) with a solution for repository size, or assume a shallow clone is sufficient without realizing it does not prevent binary bloat from accumulating in the repository history.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

Use Git LFS to track binary files.

Git LFS (Large File Storage) replaces large binary files in the repository with lightweight text pointers, storing the actual binary content in external storage. This prevents the repository from bloating with frequently updated binaries, reducing clone time and repository size since only the pointers are cloned.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

  • Perform a shallow clone of the last commit only.

    Why it's wrong here

    A shallow clone with --depth 1 only retrieves the latest commit's tree and blobs, reducing local history, but it does not remove large binary files from that snapshot—those objects are still stored and transmitted. Thus, both the central repository size and the clone size remain large, and you lose the full history needed after a TFVC migration.

  • Use Git LFS to track binary files.

    Why this is correct

    Git LFS stores binary files in a separate remote store and replaces them in Git with small text pointers, so cloning fetches only the pointers and downloads actual binaries on demand (via `git lfs fetch` or by checking out the working tree). This keeps the .git directory and clone time small, and Azure Repos fully supports Git LFS for repos, making it the correct solution for large binary files.

  • Use sparse checkout to exclude binary files from the working tree.

    Why it's wrong here

    Sparse checkout only restricts which directories appear in the working tree; it does not change the objects stored in .git, and all blobs, including large binaries, are still downloaded during clone or fetch. Consequently, the repository size on the server and local disk remains unchanged, so it provides no relief from repository bloat.

  • Use TFVC to Git converter with default settings.

    Why it's wrong here

    Default TFVC-to-Git converters (such as git-tfs or the Azure DevOps migration tool) convert the full history and check in every binary file as a regular blob, resulting in a large, unwieldy Git repository. They also fail to automatically integrate Git LFS, so you must explicitly configure LFS and retrofit the migration, making default settings an inefficient approach for repositories with significant binary content.

About these practice questions

This AZ-400 question is part of Courseiva's 823-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

JA

Written by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

This AZ-400 practice question is part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the AZ-400 exam.