Microsoft AZ-400: Source Control with GitHub and Azure Repos

The Microsoft AZ-400 exam remains current on October 6, 2026 under Microsoft’s July 27 English blueprint. Source control is only 10–15% of the measured skills, but it sits underneath almost every DevOps workflow: pull requests, branching, code review, build triggers, artifact versioning, release traceability, security controls, and the feedback loop between development and operations.

This article focuses on source-control decisions across GitHub and Azure Repos without turning into a Git command reference. The important skill is designing collaboration and traceability so delivery pipelines can operate safely at scale.

Choose a repository model from team and product boundaries

Repository strategy should reflect product ownership, deployment boundaries, shared components, compliance needs, and the cost of coordinating changes. Monorepo and multirepo patterns can both work when the boundaries are explicit. Model a product with an application, infrastructure code, reusable libraries, and database changes. Decide which artifacts belong together and which should evolve independently.

A useful source-control design explains ownership and release coupling rather than following one fashionable repository pattern.

Repository design should account for code ownership boundaries. A monorepo can simplify coordinated changes but may increase review noise and permission complexity; multiple repositories can isolate ownership but make cross-repository changes harder to coordinate. The right choice depends on how teams build, release, and govern the product.

Repository ownership should be reviewed when teams reorganize. A protection rule, code-owner file, or automation identity that still points to an old team can quietly weaken review and support even when the repository itself remains active.

Design branches around integration risk

Trunk-based development, short-lived branches, release branches, and hotfix branches create different integration and operational tradeoffs. Take a team shipping daily and a regulated product shipping on controlled release windows. Compare how branch lifetime, validation, merge policy, and emergency fixes should differ.

Long-lived branches can defer integration risk; overly strict branching can also slow feedback. The right model matches change cadence and control requirements.

Emergency change handling deserves explicit design. Production incidents may require a rapid fix, but bypassing review and validation completely can turn one incident into another. Define how a hotfix branch or emergency pull request is created, which controls can be shortened, which checks must remain, who approves the exception, and how the normal branch is reconciled afterward. A mature source-control process has a safe fast path rather than relying on informal administrator privilege.

Emergency changes need a controlled fast path. A hotfix may shorten normal review, but it should still preserve required validation, explicit approval, traceability, and later reconciliation with the main branch. Informal administrator bypass is not a sustainable incident strategy.

Branch protection should be tested against bypass scenarios. Administrator overrides, force pushes, emergency changes, and automation identities can all weaken the review model if they are not controlled and audited. A policy is only as strong as the paths that can avoid it.

Make pull requests part of the quality system

Pull requests are not just a merge button. Reviewers, status checks, required builds, code owners, security analysis, conversation resolution, and protected branches turn code review into an enforceable delivery control. Write a branch policy for a high-risk service and another for a low-risk internal tool. Decide which checks are mandatory and which would add delay without enough risk reduction.

Policy should protect quality and traceability while keeping the feedback loop short.

Pull-request design should also consider review quality, not only review count. Code owners, required conversations, automated checks, and targeted reviewers can improve coverage, while too many mandatory reviewers can create rubber-stamp approval and slow flow. The policy should reflect risk and ownership rather than a universal number.

Use repository history as operational evidence. Tags, release branches, merge commits, and pull-request metadata can help explain which code reached production and when. A clear versioning strategy reduces ambiguity during rollback, incident analysis, and support.

Keep GitHub and Azure Repos concepts portable

GitHub and Azure Repos expose different interfaces and policy features, but the underlying decisions are similar: repository permissions, branch protection, pull requests, checks, service integrations, and auditability. Describe one governance requirement without naming a platform, then map it to GitHub and Azure Repos separately.

That exercise prevents product UI knowledge from replacing DevOps reasoning.

Use source control to drive delivery

Source control should feed an auditable delivery path. CI/CD pipeline architecture for Microsoft AZ-400 connects branch or tag events, validation, artifact creation, approvals, and deployment traceability so a production release can be traced back to reviewed source.

A release should be traceable back to a reviewed source state, not to an opaque manual upload.

Auditability matters beyond compliance. When a production regression appears, teams should be able to trace the deployed artifact to a commit, the commit to a pull request, the pull request to review and validation evidence, and the change to the person or automation that approved it. Practice following that chain backward. If any link depends on tribal knowledge or a manual file copy outside source control, the delivery system has a traceability gap.

Auditability is valuable even without a compliance requirement. After a regression, the team should be able to trace the deployed artifact to a commit, pull request, validation result, and approval. Missing links in that chain usually indicate manual state or process debt that should be removed.

Secure secrets and identities outside the repository

Credentials, signing keys, connection strings, tokens, and production configuration should not be treated as ordinary source files. Review a pipeline repository and identify which values belong in secret stores, environment settings, managed identities, or pipeline-secured variables instead of Git history.

Removing a secret later does not erase its history, so prevention and rotation planning matter.

Large binaries, generated output, package artifacts, and build products do not always belong in normal Git history. Decide which material should live in a package feed, artifact repository, container registry, or release asset so source history remains focused on reviewed inputs that can reproduce the build.

Source-control hygiene also affects security. Accidentally committed secrets, generated credentials, large binaries, and unreviewed workflow changes can persist in history or alter the delivery path. Preventive scanning and disciplined repository contents reduce risk before CI/CD even begins.

Use GitHub Actions and Azure Pipelines deliberately

Workflow tooling should preserve the same source-control guarantees. GitHub Actions for Azure delivery shows how runners, environments, reusable workflows, approvals, and Azure authentication can extend repository events into a controlled deployment process.

The exam-level decision is less about brand loyalty and more about which integration model matches the organization’s collaboration and delivery platform.

Repository events should be trustworthy pipeline triggers. If a protected branch can be updated through an unreviewed automation path or a workflow file can be changed without equivalent review, the delivery system may bypass its own controls. Treat pipeline definitions and reusable workflow code as security-sensitive source.

Treat merge conflicts and failed checks as feedback

Conflict frequency, flaky validation, repeated policy bypasses, and slow reviews are signals about architecture and team workflow. Track where conflicts occur and whether they come from shared files, long branch lifetime, unclear ownership, or generated artifacts that should not be merged manually.

Source-control problems can reveal coupling and process debt that a new branch rule alone will not solve.

Practice source-control scenarios, not command trivia

Common AZ-400 preparation mistakes are helpful when they expose an over-focus on Git commands instead of repository ownership, branch policy, review, traceability, and delivery behavior. Source-control readiness should explain why the workflow is safe, not merely how to execute it.

AZ-400 readiness means you can connect source control to quality, security, automation, and delivery flow.

For the source-control capstone, take one production change from commit through pull request, validation, artifact creation, deployment, and incident traceability. Then change the repository ownership or emergency-release requirement and redesign only the controls that genuinely need to change. The result should show that branch policy, review, permissions, and delivery triggers are derived from collaboration risk rather than from a memorized Git workflow.

Repository governance should also account for permissions and service ownership. A developer who can push directly to a protected production branch, an automation identity with broad repository access, or an abandoned repository with no owner all create delivery risk. Build a simple access matrix showing who can read, contribute, administer, approve, and bypass controls. Then review it against the product’s actual support model. Source control becomes much more useful when authorization and ownership are designed with the collaboration workflow instead of added later.

Large repositories introduce performance and coordination questions that are worth understanding conceptually. Generated files, large binaries, package artifacts, and frequently changing shared configuration can create noisy history or slow clones without improving traceability. Decide which outputs belong in an artifact repository, package feed, release asset, or generated build step instead of normal Git history. The decision is not about purism; it is about keeping source history focused on the material developers actually review and reproduce.

Repository permissions deserve the same design attention as branch policy. Define who can read, contribute, administer, approve, or bypass protections and whether automation identities have broader access than they need. An abandoned repository or unowned service identity can undermine otherwise strong review rules.