Overview
Domain 2 covers how code is stored, reviewed and protected. Microsoft lists two functional groups. The branching group asks you to design a branch strategy across trunk-based development, feature branches and release branches, to build a pull request workflow, and to enforce merge restrictions using Azure Repos branch policies and GitHub branch protection rules.
The repository group is more hands-on: managing large files with Git LFS and git-fat, scaling big repositories with Scalar and cross-repository sharing, setting repository permissions, organizing history with tags, recovering lost work with Git commands, and removing data that should never have been committed. Questions mix Azure Repos and GitHub features, so you need the equivalent setting on each platform rather than one product's menus.
How it's tested
Source control questions give you a team size, release cadence, compliance rule or repository problem and ask for the branching model, policy, Git command or storage option that fits. Many answers differ only in a single setting, such as squash merge versus rebase, so read requirements word by word before choosing.
-
Choose the model
Release cadence and team size are given, and you pick trunk-based, feature branch or release branch strategy.
-
Enforce the gate
A rule such as required reviewers, linked work items or a passing build must be enforced on main in Azure Repos or GitHub.
-
Fix the repository
Large binaries, slow clones, lost commits or a committed secret need the right Git feature or command.
A developer pushed a commit containing a storage key to a shared GitHub repository a week ago, and several merges followed. Reverting the commit removes the key from the latest tree but leaves it in history. The right sequence is to rotate the key immediately, rewrite history with git filter-repo or BFG to remove the file, force-push the cleaned branches, and ask collaborators to re-clone. Rotation comes first because the secret is already exposed.
Functional groups 2
Official functional groups from the Microsoft outline, in outline order.
2.1 Design and implement branching strategies for the source codeTrunk-based, feature and release branches, pull request workflows and merge restrictions.
- What it means
- This group covers designing a branch strategy (trunk-based, feature branch and release branch), designing and implementing a pull request workflow by using branch policies and branch protection rules, and restricting how branches can be merged.
- What to understand
- Trunk-based development keeps short-lived branches merged into main frequently, often behind feature flags, and suits continuous delivery. Feature branches isolate work until review. Release branches stabilize a version while main moves on, and hotfixes are cherry-picked between them. In Azure Repos, branch policies on main can require a minimum number of reviewers, linked work items, resolved comments, build validation, status checks and automatically included reviewers, and can limit merge types to basic merge, squash, rebase and fast-forward, or semi-linear merge. In GitHub, branch protection rules or rulesets require pull request reviews, CODEOWNERS approval, passing status checks, linear history and signed commits.
- How it shows up
- Expect a requirement list for main and a question about which policy or protection setting enforces each item.
- Common confusion
- Thinking a branch policy blocks direct pushes only for some users; once a policy exists, changes to the branch must go through pull requests unless bypass permission is granted.
2.2 Configure and manage repositoriesLarge files, scaling, permissions, tags, recovering data and removing data.
- What it means
- This group covers strategies for large files using Git LFS and git-fat, scaling and optimizing Git repositories with Scalar and cross-repository sharing, configuring repository permissions, organizing with tags, recovering specific data with Git commands, and removing specific data from source control.
- What to understand
- Git LFS replaces large binaries with pointer files and stores content on a separate server; Azure Repos and GitHub both support it. Scalar configures partial clone, sparse checkout, background maintenance and the file system monitor for very large repositories. Cross-repository sharing uses packages or submodules rather than copying code. Annotated tags carry author, date and message and suit releases; lightweight tags are bare pointers. Recovery relies on git reflog to find lost commits, then git checkout, branch or cherry-pick. On shared branches, git revert undoes changes safely, while git reset rewrites history. Removing data uses git filter-repo or BFG followed by a force push, and any exposed secret must be rotated.
- How it shows up
- Expect a symptom such as slow clones, a deleted branch or a leaked credential, with Git commands as answer options.
- Common confusion
- Assuming git revert removes a secret from history; it only adds a new commit, so the secret stays in earlier commits.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
Trunk-based development
Small, frequent merges into a single main branch.
- Remember
- Pairs with feature flags and fast pipelines.
- Tested as
- Strategy selection.
- Trap
- Choosing it for teams that ship one large release a year.
-
Release branch
Branch that stabilizes a version for shipping and patching.
- Remember
- Hotfixes are merged or cherry-picked back to main.
- Tested as
- Multi-version support questions.
- Trap
- Forgetting to port fixes back to main.
-
Build validation policy
Azure Repos policy that runs a pipeline on each pull request.
- Remember
- Can be required or optional and can expire.
- Tested as
- Quality gate questions.
- Trap
- Expecting a CI trigger alone to block merges.
-
Required status checks
GitHub protection setting that needs named checks to pass.
- Remember
- Checks come from Actions or external apps.
- Tested as
- GitHub gate questions.
- Trap
- Selecting a check name that never reports.
-
CODEOWNERS
File that assigns owners who must review changes to paths.
- Remember
- Enforced when protection requires code owner review.
- Tested as
- Review workflow questions.
- Trap
- Placing it where GitHub does not read it.
-
Merge type restrictions
Policy that limits merges to squash, rebase or other types.
- Remember
- Squash keeps main history linear and compact.
- Tested as
- History shape questions.
- Trap
- Mixing squash merge with a need to keep every commit.
-
Git LFS
Stores large binary content outside the Git object database.
- Remember
- Track patterns with git lfs track and commit .gitattributes.
- Tested as
- Large file questions.
- Trap
- Adding LFS after binaries are already in history without migrating.
-
Scalar
Tool that tunes Git for very large repositories.
- Remember
- Enables partial clone, sparse checkout and background maintenance.
- Tested as
- Repo scaling questions.
- Trap
- Confusing it with Git LFS, which handles file size not repo breadth.
-
Annotated tag
Tag object with tagger, date and message.
- Remember
- Preferred for release versions.
- Tested as
- Tagging questions.
- Trap
- Using lightweight tags when audit detail is needed.
-
git reflog
Local log of where HEAD and branches pointed.
- Remember
- Finds commits lost after reset or branch deletion.
- Tested as
- Recovery questions.
- Trap
- Expecting it to exist on the server or another clone.
-
git filter-repo
Rewrites history to remove files or text.
- Remember
- Requires force push and fresh clones afterward.
- Tested as
- Data removal questions.
- Trap
- Skipping secret rotation after the rewrite.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
Branching strategies
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Trunk-based | Short-lived branches merged to main daily | Fast feedback, relies on feature flags | Allowing branches to live for weeks |
| Feature branch | One branch per feature until reviewed | Isolation with pull request review | Long branches causing merge conflicts |
| Release branch | Branch per shipped version | Supports patching older releases | Not porting fixes to main |
Undoing changes in Git
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| git revert | New commit that reverses an earlier one | Safe on shared branches | Thinking it purges history |
| git reset | Moves the branch pointer back | Rewrites local history | Using it on pushed shared branches |
| git filter-repo or BFG | Rewrites all history to drop content | Needed for leaked secrets or huge files | Forgetting the force push and re-clone |
Azure Repos vs GitHub enforcement
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Branch policies | Azure Repos rules on a branch | Reviewers, work item links, build validation, merge types | Looking for CODEOWNERS here instead of automatic reviewers |
| Branch protection rules and rulesets | GitHub rules on branches | Reviews, status checks, linear history, signed commits | Expecting linked work item enforcement natively |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Revert the secret
- What candidates pick
- Run git revert on the commit that added the credential.
- Why it looks right
- Revert is the safe command for shared branches.
- Why it's wrong
- The secret remains in earlier history; rewrite with filter-repo or BFG and rotate the credential.
Clue to watch for A secret or key was committed and pushed.
-
Reset on main
- What candidates pick
- Use git reset --hard and push to undo a bad merge on main.
- Why it looks right
- It makes history look clean.
- Why it's wrong
- Rewriting a shared branch breaks other clones; git revert adds a reversing commit instead.
Clue to watch for Other developers have already pulled the branch.
-
LFS for slow clones
- What candidates pick
- Enable Git LFS because clones of a huge monorepo are slow.
- Why it looks right
- LFS is associated with large repositories.
- Why it's wrong
- LFS helps with large binary files; breadth and history size call for Scalar, partial clone and sparse checkout.
Clue to watch for Many files and folders rather than big binaries.
-
Lightweight release tags
- What candidates pick
- Create lightweight tags for each production release.
- Why it looks right
- They are quick to create.
- Why it's wrong
- Annotated tags record who tagged, when and why, which suits release auditing.
Clue to watch for Auditors need release metadata.
-
Status check never reports
- What candidates pick
- Require a status check named after a workflow file.
- Why it looks right
- The workflow name seems obvious.
- Why it's wrong
- GitHub needs the job or check name that actually reports, or pull requests wait forever.
Clue to watch for Pull requests stuck waiting for status.
-
Squash to keep commits
- What candidates pick
- Enforce squash merge to preserve every developer commit on main.
- Why it looks right
- Squash sounds tidy.
- Why it's wrong
- Squash collapses a pull request into one commit; use rebase or basic merge to keep individual commits.
Clue to watch for Requirement to keep full commit history.
Answer framework
Use these steps to answer a Domain 2 source control scenario.
- Read the release cadence: continuous delivery points to trunk-based with flags, while supported parallel versions point to release branches.
- List each merge requirement and map it to a policy or protection rule, such as reviewers, build validation, status checks or linked items.
- Decide the history shape the team wants and restrict merge types accordingly: squash for a compact main, rebase or merge to keep commits.
- For repository problems, separate large files, which suit Git LFS, from very broad repositories, which suit Scalar or sparse checkout.
- For recovery use reflog with cherry-pick or revert; for purging data, rewrite history, force push and rotate any exposed secret.
Practice question
Want more like this? The AZ-400 practice test has questions for every domain.
Checklist
0 of 12
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Spend most of this domain at the command line. Create a throwaway repository, commit a few changes, then practice reset, revert, cherry-pick and reflog until you can predict what each does to history. Delete a branch and bring it back from the reflog. Commit a fake secret, remove it with git filter-repo, and note that every clone must be refreshed.
Next, configure the same governance twice: once as an Azure Repos branch policy and once as a GitHub branch protection rule or ruleset. Require two reviewers, a passing build and a restricted merge type, and add a CODEOWNERS file in GitHub. Writing down the matching setting names on each platform is the fastest way to handle mixed-tool questions.
Then add Git LFS tracking for a binary type, try git lfs migrate on existing history, and read the Scalar documentation for partial clone and sparse checkout. Plan around eight to ten hours. Keep notes on which command rewrites history, because that distinction decides many answers.
FAQ
How much of AZ-400 is Domain 2, Design and implement a source control strategy?
Microsoft weights it at 10–15% with two functional groups: branching strategies, and configuring and managing repositories.
Does the exam cover both Azure Repos and GitHub?
Yes. The objectives name branch policies, which are Azure Repos features, and branch protection rules, which are GitHub features, so know both.
When should I choose trunk-based development?
When the team wants continuous integration and frequent releases, keeps branches short-lived and can hide unfinished work behind feature flags.
What is the difference between Git LFS and Scalar?
Git LFS moves large binary file content out of the repository. Scalar tunes Git for repositories with huge numbers of files or deep history.
How do I remove a committed password from Git?
Rotate the password first, then rewrite history with git filter-repo or BFG, force-push the branches and have everyone re-clone.
How do I restore a branch I deleted locally?
Run git reflog to find the last commit of the branch, then create a new branch at that commit.
Other DevOps & Containers certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
Test your Domain 2 knowledge
You have covered branch strategies, policies, large repositories and Git recovery. See whether you can apply the right setting or command in exam-style scenarios.
Keep going
- Training Training Built on your Weak areas
- Practice test Questions by domain, with explanations
- Mock exam Full length, timed like the real exam
- Readiness test Find your weakest domain in minutes
- Cheat sheet Key terms and formulas on one page
- Ask the AZ-400 AI tutor Get any concept explained your way