Microsoft AZ-400: Source Control and Delivery Pipelines

Source control and delivery pipelines solve related but different problems. A repository provides an accountable history of intended changes. A pipeline evaluates and promotes selected changes into artifacts and environments. When these systems are designed independently, teams may find themselves deploying unreviewed code, rebuilding different artifacts for each environment, or losing the link between a production incident and the change that caused it. A reliable delivery system connects every stage with evidence that can be inspected and reproduced.

The Microsoft AZ-400 certification exam places major emphasis on source-control strategies, build and release pipelines, deployment patterns, and infrastructure as code. This article works through those areas in technical depth. It complements the older hands-on AZ-400 preparation material by concentrating on how architectural choices affect auditability, merge safety, build trust, and production recovery.

Choose branching rules for how the team delivers

Trunk-based development keeps integration frequent and encourages small, reviewable changes. Feature branches can isolate work until a pull request is ready, while release branches may help support multiple maintained versions. None of these approaches guarantees quality on its own. A team that works for months on a feature branch may face difficult integration regardless of how tidy the repository appears. A team that merges directly into the main branch without sufficient tests can create equally serious instability.

Consider the organization's release rhythm and product responsibilities. A cloud service deployed several times each day may benefit from short-lived branches and feature flags. A packaged product supporting separate customer versions may need a formal release branch and backport strategy. Define who may merge, which checks are required, and how emergency fixes are handled. Branch policies or protections should enforce meaningful controls: peer review, passing tests, restrictions on force pushes, and permission separation where risk warrants it.

Review quality matters more than an approval counter. A pull request should show a manageable change, clear intent, relevant tests, and any migration or rollback implications. Very large changes are difficult to evaluate, particularly when code and infrastructure are altered together. Encourage developers to separate refactoring from behavioral changes and to make dependencies visible. A reviewer should be able to understand what could go wrong rather than merely confirm that the changed files compile.

Protect repositories and the integrity of history

Repository administration includes permission management, protection against secret exposure, large-file strategy, tags, and recovery. A personal access token with broad privileges can undermine otherwise strong branch protection if it is stored in an unsafe place. Grant the least privilege required to developers, automation accounts, and external collaborators. Periodically review permissions after staffing or project changes, and choose appropriate authentication mechanisms for tools integrating with GitHub or Azure DevOps.

Sensitive data in source control requires particular care. Removing a password from the latest commit does not necessarily erase it from repository history or copies already fetched. Incident response may require credential rotation and a deliberate history remediation strategy, with careful coordination because rewriting Git history affects collaborators. Preventive scanning and employee training are often less disruptive than emergency cleanup. Teach teams to use secure secret stores and configuration injection rather than committing production credentials “temporarily.”

Large binaries, generated files, and build artifacts also deserve structure. Git is well suited to versioning source; storing enormous frequently changing binaries directly can make cloning and history inspection unwieldy. Large-file extensions or package registries may be more appropriate depending on use. Tags and artifact versions should communicate releases consistently. A release identifier needs to point to a known source state and build output, not an arbitrary folder renamed at deployment time.

Make the pipeline produce verifiable artifacts

A build pipeline should identify the exact source revision, toolchain or execution environment, dependency versions, and resulting artifact. Runners or agents need the network access and tools required for the job, but not broad permanent authority over production. A hosted runner may reduce infrastructure maintenance, while a self-hosted agent can meet unusual networking or tooling requirements. The trade-off includes security patching, isolation, concurrency, cost, and the possibility that another job contaminates its workspace.

YAML definitions make the delivery process reviewable alongside source code. Use reusable templates and shared tasks where they reduce drift, but keep the call chain understandable. A heavily abstracted set of templates that only one engineer can maintain may undermine resilience. Pipeline triggers should distinguish changes requiring a full application build from documentation changes or dependency updates. A thoughtful execution graph can run independent checks in parallel while preserving required ordering for build, test, signing, and publication.

Artifacts should be immutable or otherwise strongly identified once approved. Suppose staging tests a container image, but production rebuilds from the same commit after a dependency repository has changed. The production artifact may differ from the tested image. Promoting the actual verified artifact, with recorded digest or equivalent identity, closes this gap. Container images, application packages, and infrastructure modules each need appropriate versioning and retention so investigators can reconstruct a release later.

Design tests as layered release evidence

Fast unit tests belong early because they give developers timely feedback. Integration tests reveal behavior between services, contract tests catch interface mismatches, and end-to-end tests probe user-facing flows. Load and resiliency testing may be necessary for high-traffic or critical workloads. Security checks can assess source code, dependencies, secrets, containers, and infrastructure definitions. A mature pipeline uses the right test at the right point rather than run every conceivable check on every minor change.

Test failures require thoughtful handling. A flaky test that sometimes passes after repeated retries can create false confidence. Investigate nondeterminism, missing environmental isolation, time dependence, and test-data assumptions. Quarantining a defective test may be appropriate temporarily, but it should have an owner and deadline. Otherwise the pipeline gradually turns into a collection of warnings that teams learn to ignore. A green status is meaningful only when the underlying checks are trusted.

Release gates should reflect risk. A nonproduction preview environment might be created automatically for review, while a database migration affecting financial records may require additional verification. The approver should see which artifact is being promoted, which tests ran, and which production resource will change. Approval dialogs detached from the actual evidence encourage rubber-stamping. Automated checks and human decisions work best when each addresses a risk the other cannot resolve alone.

Deploy applications and databases without losing reversibility

Applications may be deployed as containers, packages, scripts, or platform-managed resources. Different deployment patterns manage exposure differently. Rolling updates gradually replace instances; blue-green arrangements switch between environments; canary or ring deployments limit the initial audience. Feature flags can prevent newly deployed code from exposing unfinished behavior. Select a pattern after considering state, traffic routing, session behavior, available monitoring, and how rapidly a rollback can actually restore service.

Database evolution often determines whether rollback is safe. If a new version removes a column that older application instances still read, a rapid application rollback can fail. Prefer compatible migration sequences when possible: add the new schema, deploy code that understands both forms, migrate data, and retire the old field after consumers have moved. Such changes may require several releases. Plan the sequence rather than treating the database as an incidental command at the end of the deployment job.

A high-priority fix can be complicated by concurrent feature releases. The team needs a controlled hotfix route that builds the corrected source, tests it appropriately, and records how the fix merges back into maintained branches. Untracked manual patches on production machines break the traceability chain. A good emergency path is fast because it is rehearsed and selective, not because it ignores the safeguards that normally protect users.

Include infrastructure definitions in delivery planning

Infrastructure as code brings network, identity, compute, and configuration changes into a reviewable process. Bicep and ARM templates can define Azure resources, while other tools or configuration approaches may manage specific environments. These definitions should be versioned, validated, and subject to security review. A pipeline that creates a resource successfully is not proof that its permission model or network exposure is acceptable.

Avoid assuming that a test environment is identical to production simply because both were built from one template. Parameters, secrets, capacity, external dependencies, and region-specific services can differ. Validate environment differences explicitly, and guard against configuration drift caused by manual production changes. Deployment definitions should record both desired state and the constraints under which changes may be applied. A template should not be allowed to remove a critical production resource merely because a variable was left blank.

The operational question is always whether the team can repeat the deployment reliably. A design dependent on an undocumented certificate upload or manual firewall exception is not fully automated. Include required dependencies and validations, and rehearse rebuilding a representative environment from declared configuration. Reproducibility is an engineering property demonstrated by execution, not a label attached to a repository.

Connect releases to outcomes and recovery

After deployment, verify both application health and business outcomes. A completed pipeline can coincide with failing customer authentication, increased latency, or a stalled background queue. Release annotations in monitoring systems help correlate operational changes with service behavior. Record which artifact is live in each environment and which changes are enabled behind flags. If a canary performs poorly, the team needs an unambiguous way to stop expansion and return to an acceptable state.

A useful AZ-400 rehearsal is to describe the path of one change from issue to commit, pull request, build, artifact, tests, promotion, production observation, and rollback. For every transition, identify the controlling policy and evidence. Then simulate a compromised runner, a flaky integration test, and a failed database migration. The quality of a source-control and pipeline strategy is measured by how safely it handles those real disruptions, not by how attractive its automation diagram appears.