AZ-400 Design and implement source control Practice Question
Which TWO actions should you take to ensure that your Git repository in Azure Repos remains performant as it grows?
⚠ Common exam trap
Test-takers frequently think storing binaries directly in the repo is acceptable for performance, or that reducing commit frequency improves performance, when in fact these actions degrade performance or violate source control best practices.
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 shallow clones in CI/CD pipelines.
Shallow clones fetch only the most recent commit history rather than the entire repository history, which significantly reduces the amount of data transferred and stored during CI/CD pipeline runs. This keeps pipeline execution fast and avoids performance degradation as the repository grows. Azure Repos and Azure Pipelines support shallow clone options via the `--depth` parameter in Git commands or through pipeline YAML settings.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Use shallow clones in CI/CD pipelines.
Why this is correct
Use `git clone --depth 1` or shallow fetch in CI/CD pipelines to retrieve only the most recent commit(s), drastically reducing clone time and disk usage since full history is rarely needed for build and test operations.
- ✗
Store large binary files directly in the repository.
Why it's wrong here
Committing large binary files directly into the repository bloats the .git directory because every version is stored as a full blob, forcing all clones and CI/CD jobs to download those heavy objects and permanently slowing repository operations.
- ✓
Use Git LFS for large binary files.
Why this is correct
Git LFS stores the actual binary content in remote LFS storage and commits only a tiny text pointer in the repository, keeping the main Git history lean while still allowing CI/CD to fetch required large files on demand.
- ✗
Keep all branches indefinitely to preserve history.
Why it's wrong here
Keeping every branch indefinitely preserves all commits and objects reachable from those refs, causing repository size and clone times to grow over time; deleting merged or obsolete branches keeps the object graph compact and improves performance.
- ✗
Encourage developers to commit all changes in a single commit per day.
Why it's wrong here
Forcing developers to commit all changes in one daily commit blurs the mapping between individual changes and features or fixes, making `git bisect` and reverts inefficient and obscuring the cause of regressions; small, focused commits are essential for maintainable history.
Go deeper
Related to this question
Learn chapter
Introduction to DevOps and Azure DevOps
Key term
Azure Repos
Azure Repos is a set of version control tools that allow teams to manage their source code, track changes, and collaborate on software projects using Git or Team Foundation Version Control (TFVC) within the Microsoft Azure ecosystem.
Key term
Azure Pipelines
Azure Pipelines is a cloud-based CI/CD service from Microsoft that automatically builds, tests, and deploys code to any platform or cloud.
About these practice questions
One of 823 original AZ-400 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
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.