AZ-400 source control strategy explained
Design and implement a source control strategy is 10-15% of AZ-400. It tests whether you can choose a branching model, enforce it with branch policies and branch protection rules, and keep a Git repository healthy: large files, repository size, permissions, tags and recovering or removing data. The questions are scenarios with a team size, a release cadence and a problem.
Branching strategies
The outline names three: trunk-based, feature branch and release branch.
| Strategy | How it works | Fits |
|---|---|---|
| Trunk-based | Short-lived branches merge into main several times a day; incomplete work hides behind feature flags | Teams with strong automated tests and continuous delivery |
| Feature branch | One branch per feature or fix, merged through a pull request | Most teams; simple and flexible |
| Release branch | A long-lived branch per supported release, for hotfixes to shipped versions | Products that maintain several versions at once |
The decisive details in a question are usually release cadence (“deploy many times a day” points to trunk-based), the need to support old versions (release branches) and how much automation protects main.
Pull requests, branch policies and protection rules
Azure Repos uses branch policies; GitHub uses branch protection rules (and rulesets). The ideas match:
- Require a minimum number of reviewers and block self-approval.
- Require a successful build or status check before merge (build validation in Azure Repos, required status checks in GitHub).
- Require linked work items or resolved comments.
- Restrict the allowed merge types, for example squash only, to keep history readable.
- Block force pushes and direct pushes to protected branches.
- Require review from code owners (a
CODEOWNERSfile in GitHub).
A frequent trap is mixing the vocabulary: “branch policy” is the Azure DevOps term, “branch protection rule” is GitHub’s.
Managing large files and large repositories
- Git LFS keeps large binary files out of the Git history by storing pointers in the repository and the content on a separate store. It is the standard answer for design files, datasets and binaries.
- git-fat is an older alternative that the outline also names.
- Scalar configures a large repository for performance, using partial clone, sparse checkout and background maintenance. Pair it with the idea of cross-repository sharing, for example submodules or packages, when code is reused.
- If a repository is slow because of its history, the answer is rarely “split it by hand”; look for partial clone, shallow clone, sparse checkout or LFS first.
Repository administration
- Permissions. Control who can read, contribute and administer a repository; in Azure DevOps through security groups and repository permissions, in GitHub through roles such as Read, Write and Admin.
- Tags. A tag marks a commit, usually a release, and is the usual link between a version number and the code.
- Recover data.
git reflogshows whereHEADhas been, so a branch deleted by mistake can be recreated;git revertundoes a commit by adding a new one;git cherry-pickcopies a commit to another branch. - Remove data. If a secret was committed, rewriting history is required. Tools such as
git filter-repoor BFG remove it from every commit, followed by a force push and rotation of the exposed secret. Deleting the file in a new commit does not remove it from history.
Common mistakes
- Rotating nothing after removing a secret. A leaked credential must be revoked, not just hidden.
- Using
git reset --hardon a shared branch whengit revertis the safe choice. - Choosing release branches for a web app with a single production version.
Example questions
Question 1. A SaaS team deploys to production several times a day, has a comprehensive automated test suite and wants to avoid long-lived branches. Unfinished features must not be visible to users. Which approach fits best?
- A. Release branches for every sprint
- B. Trunk-based development with feature flags
- C. Long-lived feature branches merged monthly
- D. One fork per developer, merged quarterly
Show answer
Answer: B
Trunk-based development with short-lived branches, combined with feature flags to hide unfinished work, matches frequent deployment with strong automation. Release branches suit products that support several versions. Long-lived feature branches cause painful merges. Forking per developer does not address the requirement to hide unfinished features.
Want more questions like this? Full AZ-400 practice tests →
Question 2. Designers commit large PSD files to a GitHub repository and clones have become slow. You need to keep the files versioned but reduce repository size impact. What should you use?
- A. Squash merge as the only allowed merge type
- B. A larger GitHub-hosted runner
- C. A CODEOWNERS file for the design folder
- D. Git LFS tracking for the PSD files
Show answer
Answer: D
Git LFS stores large binaries outside the normal Git object history and keeps lightweight pointers in the repository, which keeps clones fast. Squash merging does not shrink existing history of binaries. A larger runner does not change clone size, and CODEOWNERS only assigns reviewers.
Want more questions like this? Full AZ-400 practice tests →
Question 3. A developer committed an API key to the main branch two weeks ago, and the repository is private. What should you do first and next to address the exposure?
- A. Revoke and rotate the key, then remove it from history with a tool such as git filter-repo
- B. Delete the file in a new commit and continue
- C. Make the repository public so that scanners flag it
- D. Do nothing because the repository is private
Show answer
Answer: A
The key must be revoked and replaced because it exists in history and may have been copied; then history should be rewritten to remove it. Deleting the file in a new commit leaves the key in earlier commits. Making the repository public worsens exposure, and relying on the repository being private does not remove the risk from anyone with access or from forks and clones.
Want more questions like this? Full AZ-400 practice tests →
Next
Continue with build and release pipelines, the largest domain.