Source control and GitHub/Azure Repos for Microsoft AZ-400 DevOps Engineer: Concepts, Scenarios, and Study Priorities

 

Source control in AZ-400 is not a test of whether you know enough Git commands to survive a merge conflict. The current Microsoft blueprint treats source control as a strategy problem: how an organization structures repositories, controls change, protects important branches, handles pull requests, manages permissions, recovers from mistakes, shares code, and preserves security while still enabling delivery. Git is the mechanism, but governance and flow are the real subject.

The current source-control domain is about 10-15 percent of AZ-400. That percentage can tempt candidates to under-study it, especially because build and release pipelines dominate the blueprint. That is a mistake. Source control is the trust boundary where changes enter the delivery system. Weak repository controls can invalidate strong pipelines because the pipeline faithfully builds whatever the repository allows.

Microsoft also expects current candidates to have experience implementing both GitHub and Azure DevOps solutions. ExamSnap’s Azure DevOps and AZ-400 path deep dive provides broader pathway context; this article stays focused on repository strategy, controls, and scenario reasoning. A good study plan therefore learns the principle first and then recognizes how GitHub and Azure Repos express it.

Start with the job of source control: preserve change history and govern collaboration

At the most basic level, distributed version control gives teams a shared history of content changes. In a DevOps system, that history becomes evidence. It records what changed, who changed it, why a change was proposed, how it was reviewed, which checks ran, and what revision became an artifact or deployment.

That evidence supports more than software development. Infrastructure as code, pipeline definitions, policy files, documentation, database changes, configuration, and security rules can all be versioned. The repository becomes part of the operational control plane.

A source-control strategy must therefore answer several questions. Where should code live? Who can read and write it? How are changes proposed? What must happen before important branches accept change? How is ownership represented? How are versions identified? How is sensitive material prevented or removed? How are mistakes reversed without destroying useful history?

If your study begins and ends with clone, commit, push, and merge, you are studying only the transport layer.

Repository structure should reflect ownership, coupling, and deployment boundaries

One repository or many repositories is not an ideological decision. It is an architecture choice.

A monorepo can make cross-component changes atomic. Shared tooling, consistent policies, and unified search may be easier. But repository size, permission boundaries, trigger efficiency, and ownership can become more complex. A change to one directory should not necessarily rebuild every service. CODEOWNERS or path-based controls may become important.

Multiple repositories can align with independently owned or deployed services. They can reduce permission scope and simplify per-service pipelines. But cross-repository changes become harder to coordinate. Shared libraries need versioning. Compatibility becomes an explicit dependency-management problem.

For AZ-400 scenarios, look for signals. If teams must release independently and have different access boundaries, separate repositories may help. If changes frequently span tightly coupled components and need atomic review, a monorepo may reduce coordination cost. If one repository contains sensitive infrastructure code, permissions may argue for separation even if the application is related.

The correct answer is the structure that supports flow and governance under the stated constraints.

Branching strategy should match release behavior

Branches are not valuable because they create more places to work. They are valuable when they isolate change for a justified reason.

Trunk-based approaches emphasize small, frequent integration into a main line. They reduce long-lived divergence and can support high-frequency delivery when automated testing and feature controls are strong. GitHub Flow similarly uses short-lived branches and pull requests around a deployable default branch.

Release branches can be useful when a version must be supported independently from ongoing development. They can also create maintenance cost because fixes may need to move across branches and branches can drift.

Feature branches are common, but long-lived feature branches can delay integration and produce painful merges. Feature flags can reduce the need to keep incomplete work separated for long periods by allowing code to be integrated but not exposed.

A strong candidate can explain the relationship among branch lifetime, integration frequency, release cadence, risk, and support. The question is never simply “which branching strategy is best?” It is “which strategy creates the least necessary coordination cost while meeting release and control needs?”

Pull requests are decision points, not just merge buttons

A pull request creates a structured point where people and automation can evaluate change before it reaches a protected branch. It can connect discussion, reviewers, work items, tests, static analysis, security checks, and ownership rules.

The quality of a pull-request process depends on what evidence is required. Requiring two reviewers does not automatically improve quality if reviewers lack context or approvals are rubber stamps. A required automated test can be stronger than a ceremonial approval for a deterministic condition. A security-sensitive directory may justify specialized ownership that ordinary application code does not.

In GitHub, pull-request governance can involve rulesets or branch protection, required status checks, required reviews, CODEOWNERS, signed commits or other controls depending on policy. In Azure Repos, branch policies can require minimum reviewers, linked work items, comment resolution, build validation, and other conditions.

Study the control objective, not the checkbox. For every required condition, ask what risk it reduces.

GitHub rulesets and branch protection express governance centrally

GitHub provides mechanisms for protecting branches and tags and for applying repository rules. Candidates should understand the purpose of controls such as requiring pull requests, requiring approvals, requiring status checks, restricting force pushes or deletions, and defining who can bypass rules.

The bypass question matters. A control that every administrator can casually ignore is weaker than it appears. Organizations need an exception path for emergencies, but emergency power should be narrow, auditable, and rarely used.

CODEOWNERS can automatically request review from defined owners for paths. This is useful when a repository contains areas such as security policy, infrastructure, billing logic, or regulated configuration that require specialized review.

Do not confuse ownership with authorization. CODEOWNERS can influence review requirements, but repository permissions and branch rules determine what actions users can perform. The exam may test multiple layers of control at once.

Azure Repos branch policies solve similar problems with Azure DevOps semantics

Azure Repos expresses many of the same governance goals through branch policies. Minimum reviewers can enforce peer review. Build validation can require a successful pipeline. Work-item linking can preserve traceability. Comment-resolution policy can prevent unresolved discussions from being ignored. Path filters can target policies more narrowly.

A candidate should recognize that the exact names differ from GitHub but the architecture is similar: protect an important branch and require evidence before accepting change.

Permissions remain important. Branch policies do not replace repository security. Users or groups may have rights that allow bypassing policy or force pushing. Understand the interaction between permissions and policy rather than memorizing one screen.

A useful lab is to configure equivalent intent in both platforms: no direct push to main, one review, a required validation build, and specialized review for a sensitive path. The implementation differs, but the design reasoning transfers.

Required status checks connect CI with repository governance

A pull request is much stronger when automated validation is part of merge eligibility. Required status checks can ensure that tests, linting, builds, security scans, or policy validation have succeeded.

But “require all checks” is not a complete design. Checks should be reliable, relevant, and reasonably fast. A flaky test can block the entire delivery flow. A check that takes an hour may be inappropriate for every low-risk change. A security scan with high false positives can train teams to bypass it.

The right approach is layered. Fast deterministic validation belongs early. More expensive or environment-dependent testing may happen after merge or in a later stage, depending on risk. High-severity security findings may block; lower-severity findings may create tracked remediation.

Repository governance should therefore be designed with pipeline behavior. This is one reason AZ-400 domains should not be studied in isolation.

Permissions should follow least privilege and stable ownership

Source-control permissions define who can read code, contribute, create branches, approve, administer, or bypass safeguards. The easiest configuration is broad access. The safest-looking configuration is extremely restrictive. The useful configuration is the least privilege that supports the team’s operating model.

Prefer group-based permissions over one-off grants where possible because role membership is easier to review. Separate ordinary contribution from repository administration. Treat bypass permissions as sensitive. Review external collaborator or service-account access.

Automation identities also matter. A pipeline may need read access to source but should not automatically receive permission to rewrite protected branches. A bot that creates pull requests may need different rights from one that merges them.

When a scenario mentions a developer who can bypass reviews, do not assume the answer is “add another reviewer.” The real issue may be authorization at the repository or branch level.

CODEOWNERS and ownership models should mirror real responsibility

Ownership files are useful only if the named people or teams genuinely understand and accept responsibility for the code. Adding a security team as owner of every file can create a review bottleneck without improving decisions.

Use ownership boundaries where specialized knowledge or accountability exists. Infrastructure definitions may belong to a platform team. Cryptographic code may require security review. A service directory may belong to a product team.

Then design for absence. What happens if the only owner is unavailable? Can an alternate group approve? Are ownership rules updated when teams change? Governance that depends on stale team structures will eventually fail.

For study, distinguish “review requested from owner” from “merge requires approval from an owner.” The enforcement detail matters.

Merge methods affect history and troubleshooting

Merge commits, squash merges, and rebase-based merges create different history shapes.

A merge commit preserves the branch topology and individual commits. A squash merge condenses a pull request into a single commit, which can simplify history but lose granular commit boundaries. Rebase-based approaches produce a linear history by replaying commits.

There is no universal exam answer. Choose based on audit needs, team workflow, rollback patterns, and desired history. The important point is to understand consequences.

A team that relies on individual commits for bisecting may value granular history. A team that treats the pull request as the atomic unit may prefer squash merges. A regulated environment may care more about linked review evidence than about a visually linear graph.

Be able to explain how the merge method affects later diagnosis and reversibility.

Revert and reset solve different problems

Recovery questions often separate candidates who understand shared history from those who only know command syntax.

`git revert` creates a new commit that reverses the effect of an earlier commit. It preserves published history and is usually safer on shared branches.

`git reset` moves a branch reference and can rewrite the apparent history, especially when followed by a force push. It can be appropriate in local or controlled situations, but rewriting shared protected history can disrupt collaborators and audit evidence.

The key exam logic is not “revert good, reset bad.” It is whether history is already shared and whether rewriting it is acceptable under policy. On an important branch, creating an explicit reversal is often the safer operational choice.

Practice recovery in a disposable repository so the distinction becomes concrete.

Tags and releases turn commits into identifiable versions

Tags can mark meaningful points in repository history such as releases. They help connect source state to artifacts and deployments.

A good release process records which commit produced which artifact and which version reached each environment. Annotated or signed tags can add context or assurance depending on organizational policy. GitHub Releases or Azure DevOps release metadata can add distribution and notes around a version.

The key is traceability. If production reports version 2.3.7, can you identify the exact source, pipeline run, artifact, and review evidence behind it?

Avoid treating a tag as proof that an artifact is trustworthy. Tags are pointers. Trust comes from the controlled process that created and consumed them.

Large files require a strategy because Git is optimized for source history

Binary assets, datasets, design files, and other large content can make repositories heavy because Git retains history. Git Large File Storage or alternative artifact/storage systems can address some cases.

The design question is whether the file belongs in source control at all. Generated binaries should usually be build artifacts rather than committed outputs. Large models or datasets may need dedicated versioned storage. Some source assets legitimately require large-file support.

Candidates should understand the operational cost: cloning, storage, bandwidth, access control, and history growth. Choose a storage mechanism based on whether the file needs source-style versioning, build provenance, or artifact distribution.

Sensitive data in Git requires immediate credential response, not just history cleanup

If a real secret is committed, deleting the file or rewriting history does not guarantee safety. The secret may have been cloned, cached, logged, mirrored, or exposed to automation.

The first priority is to revoke or rotate the credential. Then investigate exposure and clean history if appropriate. Add preventive controls such as secret scanning, pre-commit checks, protected workflows, safer identity architecture, and developer education.

This scenario combines source control with security. It also illustrates why long-lived credentials are dangerous: once exposed, they remain usable until revoked or expired.

Never practice with real secrets. Use a harmless placeholder and rehearse the response sequence.

Git history rewriting needs coordination

Sometimes history rewriting is justified: removing sensitive material, shrinking repository history, correcting a serious mistake, or cleaning generated files. But it is disruptive in shared repositories.

A rewrite changes commit identifiers. Existing clones may reintroduce removed history if users push incorrectly. Open pull requests can become difficult to reconcile. Tags and automation references may need adjustment.

Plan a coordinated maintenance window, communicate clearly, protect the rewritten repository, and require clean re-cloning where necessary. For secrets, remember that history rewriting is not a substitute for credential revocation.

For AZ-400, the important reasoning is blast radius. Powerful Git operations can solve a local problem while creating a distributed coordination problem.

Submodules, packages, and shared code require explicit dependency thinking

Teams often need to share code across repositories. Options include packages, submodules, subtree patterns, monorepos, or service interfaces. Each has trade-offs.

Publishing shared libraries as versioned packages makes dependencies explicit and allows consumers to upgrade deliberately. Submodules can pin another repository at a specific commit but add workflow complexity. A monorepo can make changes atomic but expands repository scope.

Choose based on coupling. If two components must change together frequently, separate versioned packages may create constant coordination. If a shared library must serve many independent teams, package versioning may be cleaner.

The exam may not ask you to advocate one mechanism universally. It may describe dependency and release constraints and ask for the design that reduces risk.

Forking and external contribution change the trust model

Public or partner-facing repositories may accept contributions from forks. That changes how automation should handle secrets and privileged workflows.

Untrusted pull requests should not receive production credentials. A workflow that executes contributor-controlled code with privileged tokens can create a serious supply-chain risk. Platforms provide different event models and permission settings to help separate validation of untrusted code from trusted release workflows.

This is a valuable scenario to study because it combines repository events, pipeline identity, and least privilege. Ask what code is trusted, what token permissions exist, and whether secrets are exposed to the job.

Source-control security is inseparable from CI security.

Scenario: a team wants direct pushes to main because reviews are slow

The symptom is slow delivery. Removing pull requests may reduce waiting but also remove review, automated validation, ownership checks, and traceability.

A better analysis measures why reviews are slow. Are too many reviewers required? Is ownership unclear? Are changes too large? Do required checks take too long? Are reviewers interrupted because teams do not share working hours? Is the branch strategy creating huge diffs?

The corrective design may include smaller pull requests, clearer ownership, one required qualified reviewer instead of several ceremonial approvals, faster validation, or automated merge when checks complete.

The lesson: do not destroy a control to solve a flow problem until you understand the bottleneck.

Scenario: a repository administrator bypasses policy for an urgent hotfix

An emergency path can be legitimate, but it should not become invisible technical debt.

A mature response records the reason, limits who can bypass, requires post-change review if pre-change review was impossible, and makes sure automated validation still runs as soon as feasible. The organization should also ask whether deployment architecture supports safer emergency changes, such as feature flags or rollback.

If bypass becomes routine, the policy or delivery system is poorly designed.

This scenario tests governance judgment: exceptions need control too.

Scenario: a monorepo builds every service on every commit

The repository has ten services, but a documentation update triggers all builds. Pipeline duration grows and developers complain.

The solution may use path-aware triggers, dependency graphs, caching, or build orchestration that determines affected components. But be careful: shared library changes may require rebuilding many services even if their directories did not change.

A simple path filter can be wrong if dependencies are implicit. The right design knows the dependency structure and combines efficiency with correctness.

This is a cross-domain scenario: repository structure, pipeline triggers, and dependency management interact.

Study priority 1: translate every source-control objective into a scenario

Do not create a flashcard that says “branch policy = protect branch.” Create a scenario: a production branch must reject changes unless tests pass and a domain owner approves sensitive configuration. Then identify the GitHub and Azure Repos mechanisms that implement the requirement.

Do the same for tags, permissions, recovery, large files, repository structure, and code sharing.

Scenario-first study reduces memorization and prepares you for wording that does not name the feature directly.

Study priority 2: build equivalent governance in GitHub and Azure Repos

Use one simple requirement set and implement it twice. Protect main. Require a pull request. Require one review. Require successful validation. Add specialized review for a sensitive path. Restrict direct force-push behavior.

Document the differences in terminology and configuration. You do not need perfect feature parity. You need to recognize how each platform expresses the same control objectives.

This is especially valuable because the current Microsoft audience profile expects experience across both solutions.

Study priority 3: practice failure and recovery

Create a merge conflict. Revert a bad shared commit. Compare reset locally. Move a tag in a disposable repository and repair it. Commit a fake secret and rehearse the security response. Break a required status check and diagnose why the branch is blocked.

Every controlled failure teaches more than another successful merge.

Then use AZ-400 practice questions to see whether the concepts transfer into exam-style choices. If a source-control question feels ambiguous, return to the lab and test the competing designs.

Final source-control readiness checklist

You are approaching readiness when you can design a repository model based on ownership and deployment boundaries, choose a branching strategy based on release behavior, and explain pull-request controls in terms of risk.

You can implement meaningful governance in both GitHub and Azure Repos. You understand the difference between permissions and policies, ownership and enforcement, revert and reset, tags and artifacts, and source repositories and package distribution.

You can also handle failure: a leaked credential, bad merge, broken tag, overbroad bypass permission, or slow monorepo build does not send you searching randomly through menus. You reason from the control objective and the evidence.

That is the level of source-control understanding AZ-400 rewards. Git commands remain necessary, but they are only the mechanics inside a larger system of collaboration, trust, and delivery.

Merge queues and serialized integration solve a specific concurrency problem

On a busy protected branch, several pull requests may each pass validation against the same base revision and then conflict when merged in sequence. A merge queue or equivalent integration mechanism can validate the combined state before final merge.

The objective is not “use a queue because the repository is important.” It is to protect the target branch from integration races while preserving throughput. If the team has low concurrency, ordinary required checks may be sufficient. If many changes merge quickly and tests are expensive, queue design, batching, and failure handling matter.

For study, recognize the difference between review quality and integration validity. A pull request can be well reviewed and still fail when combined with another change.

Signed commits and protected tags can add assurance, but only inside a trust model

Cryptographic signatures can help prove that a commit or tag was produced by a key associated with a trusted identity. They do not prove the code is safe, reviewed, or tested.

If an organization requires signed commits or tags, ask how keys are managed, what happens when a key is revoked, and how verification is enforced. A signature that nobody checks adds little operational value.

Similarly, protecting release tags prevents casual deletion or movement, but the build and release process still needs provenance. Security controls are additive, not magical.

Repository backup and disaster recovery should include more than source files

Distributed Git means many clones may contain repository history, but a practical recovery plan should consider pull requests, issues, branch rules, repository permissions, webhooks, packages, Actions or pipeline configuration, and other platform metadata.

A disaster-recovery design asks what must be restored for development and delivery to resume. Source content alone may not recreate governance.

This is useful architecture thinking even if the exam does not ask for a full backup product: repository platforms are services with configuration state, identities, and integrations.

Supply-chain dependencies cross the repository boundary

A repository can be perfectly protected and still build compromised software if its dependencies, package sources, or actions are untrusted.

Study package-source controls, version pinning, dependency scanning, provenance, and the risk of referencing mutable external automation. A GitHub Action referenced only by a moving tag has a different trust property from a version pinned to an immutable commit. A package feed that any developer can publish to has a different supply-chain risk from one with controlled publishers.

Source control strategy therefore reaches into CI trust. The repository records instructions; the build system executes a wider dependency graph.

A decision table for branching questions

When comparing strategies, ask five things: how often do teams integrate; how independently are versions released; how long must old versions be supported; how strong is automated validation; and how expensive is merge divergence?

Frequent integration, high automation, and one continuously delivered version generally favor short-lived branches. Long-lived supported releases may justify release branches. Incomplete features do not automatically require long-lived branches if feature flags can separate deployment from exposure.

This table is more reliable than memorizing labels because it maps the branch model to operational requirements.

Repository strategy should follow ownership and change boundaries

The choice between a monorepo and multiple repositories is not a slogan. Start with the change boundaries of the system. If several components must change atomically, share a release cadence, and are governed by the same ownership model, a monorepo can simplify coordinated changes. If components have independent lifecycles, sharply different permissions, regulatory boundaries, or separate product ownership, multiple repositories can provide cleaner isolation. The trade-off is operational: a monorepo may require sophisticated path-based builds and ownership rules, while many repositories can increase dependency coordination and version-management work.

For exam scenarios, look for the constraint that makes repository structure matter. A requirement to restrict a sensitive infrastructure directory does not automatically require another repository; path ownership and permissions may be sufficient depending on the control model. Conversely, a true security or administrative boundary may justify separation even if it creates coordination overhead.

Branch protection is only as strong as the identities around it

A policy requiring reviews and status checks can still be undermined by overly broad bypass permissions, service accounts with excessive rights, or automation that writes directly to protected branches. When assessing a source-control design, include human users, bots, apps, and build identities in the permission model.

Practice tracing one change from author to merge. Who can open the pull request? Who can approve it? Can the author satisfy their own required review? Which status checks are trusted? Which identity reports them? Who may bypass the rule during an incident, and is that action auditable? This reasoning connects source control to least privilege and compliance rather than treating branch policy as an isolated feature.

Recovery planning belongs in source-control design

Source control is a recovery system as well as a collaboration system. Rehearse how you would recover from an accidental force push, a bad merge, a leaked secret, a deleted branch, and an incorrect tag. The response differs by failure. Reverting a bad functional change is not the same as removing a secret from history, and rewriting history can itself disrupt clones, forks, and open pull requests.

A strong answer distinguishes restoring the desired code state from erasing sensitive historical data. It also considers downstream artifacts and credentials. If a secret was committed, history cleanup does not make the credential safe again; rotate or revoke the secret and investigate where it may have propagated. That cross-domain reasoning is exactly why source-control questions can overlap with security and pipeline design on AZ-400.