Microsoft AZ-400: Building Delivery Systems that Hold Up

AZ-400 assesses DevOps engineering as a system of delivery rather than a collection of commands. Its July 27, 2026 skills outline places more than half the emphasis on build and release pipelines, with source control, processes and communications, security and compliance, and instrumentation completing the scope. The candidate should be able to trace a change from a request through review, build, test, artifact, deployment, observation and recovery. A successful pipeline is not the one that deploys fastest in a demonstration; it is the one that delivers trustworthy changes repeatedly without making incidents impossible to diagnose.

Make work and responsibility visible before automation

DevOps begins with the flow of work between people. Teams need agreed definitions of ready, done and releasable work, as well as a practical approach to branching, review and incident ownership. Work item links to commits and deployments help establish why a change happened. A large number of dashboards cannot compensate for missing agreement about who can approve production releases or how urgent fixes are handled. Process should reduce coordination friction without turning every small update into weeks of meetings.

Imagine a service with two product teams sharing one deployment environment. One team merges a configuration change while the other is testing a performance fix. If the release history cannot identify which changes entered production together, incident analysis becomes guesswork. Choose the necessary approvals and traceability based on risk. DevOps priorities focus on the end-to-end delivery flow, and source control and delivery pipelines become more useful once the underlying ownership and review rules are explicit rather than assumed.

Source control strategy is an operational design

Git repositories, branch policies, pull requests, code ownership and secrets scanning influence the quality and speed of change. Long-lived branches can accumulate integration conflicts and delay feedback, while trunk-based workflows need strong automated tests and feature controls. The appropriate choice depends on team maturity, release obligations and how frequently code must be integrated. Protect mainline branches with meaningful review and automated checks. An approval from someone who did not examine the diff should not be treated as equivalent to technical assurance.

A team updating an API and its database schema needs a method for testing compatibility across versions. Source control tells who changed the contract; CI determines whether consumers still work. Require tests that catch schema incompatibilities before a deployment begins. Keep environment-specific configuration and credentials out of the repository, but version the declarations that can safely describe infrastructure. The purpose is not to make every developer follow the same ceremony. It is to prevent an opaque release history in which mistakes are easy to introduce and expensive to reverse.

Continuous integration should build an identifiable artifact

A CI pipeline should restore pinned dependencies, compile the application, run appropriate tests, evaluate security findings and create a traceable output. Build once and promote the same artifact through environments when feasible, rather than rebuilding different binaries for each stage. This reduces uncertainty about what was tested. Cache dependencies for efficiency but account for corruption and stale versions. Test reporting should distinguish a genuinely failed check from a flaky test that masks instability through endless retries.

Suppose a project generates a container image for an API. Attach the source revision, build settings and scan results to the image; protect signing and publishing credentials; and ensure promotion targets that immutable image digest. If a vulnerability alert arrives after deployment, engineers should identify affected environments without guessing which tag points to which content. Reproducible builds and artifact provenance turn an emergency patch from detective work into controlled response. Azure Pipelines and GitHub Actions both support automation, but the candidate needs to understand the release contracts behind a YAML file.

Deployment techniques must match the failure cost

Continuous delivery includes deployment approvals, environment protections, infrastructure configuration and rollback. Blue-green, canary and rolling deployments provide different traffic and capacity tradeoffs. A canary is meaningful only if monitoring can compare the candidate version against an appropriate baseline. A deployment slot may simplify web application rollout, but external data stores and message consumers can still create incompatibility. Treat release strategy as part of application design instead of an afterthought assigned to the operations team.

For a service processing payment messages, redeploying an older binary after a database migration may fail if the schema changed incompatibly. Plan expand-and-contract migrations and versioned messages before release. Decide how to stop traffic, drain workers or reverse feature flags without losing in-flight work. A release is complete when the business transaction works end to end, not when the deployment task reports a green checkmark. The AZ-400 pipeline practices are best understood through failure recovery rather than diagrams alone.

Infrastructure as code should capture intended state

Bicep, templates and related tooling can establish repeatable environments, but declarations need review and ownership. An IaC change can expose a resource, remove a network rule or alter capacity across every deployment target. Treat templates like application code: review changes, test against representative environments and identify the permissions the automation requires. Drift detection helps distinguish an authorized emergency modification from a forgotten exception. Resource naming and tagging aid discovery but do not enforce safe architecture.

Consider deploying an app with a private database endpoint. The release pipeline may have permission to create the database, yet the application cannot connect because private DNS is absent from one environment. A responsible deployment verifies connectivity and identity assumptions, not simply that the resource manager completed its operations. Azure infrastructure administration supplies important platform context; AZ-400 extends it into the controls governing how those resources change safely through code and approved release workflows.

Security and compliance require continuous evidence

A secure pipeline prevents unauthorized changes and captures evidence that the organization needs to assess them. Integrate dependency and code scanning, secret detection, artifact provenance, environment protections and policy checks appropriate to the application's sensitivity. One scan cannot guarantee security; findings need ownership, severity decisions and documented exceptions. A release process should block critical classes of risk while allowing controlled resolution of noncritical issues, rather than overwhelming teams with alerts that everybody ignores.

A regulated finance team may need to demonstrate separation of duties for a production release. Design approvals that cannot be bypassed by the same identity that authored the change. Protect service connections and limit deployment permissions to required scopes. Avoid storing production secrets as plain pipeline variables or reproducing customer data in build logs. Embedding DevSecOps and observability in delivery makes prevention and incident evidence part of each release, reducing unauthorized changes while preserving traceability when investigations are needed.

Instrument changes so failures can be explained

Observability is the feedback loop of delivery. An automated release needs service health, errors, latency, dependency behavior and business signals to show whether users benefited or suffered. Azure Monitor, Application Insights and other telemetry tools can provide data, but meaningful service level indicators and error budgets guide decisions. A release that lowers infrastructure CPU while increasing abandoned purchases is not an improvement. Correlate telemetry with deployment identifiers so teams can distinguish version-related failures from ordinary demand patterns.

For a customer API, measure successful requests and end-to-end transaction completion, then compare after a staged rollout. If a dependency becomes slow, tracing should reveal the bottleneck rather than merely showing a rising overall response time. Define alert thresholds, ownership and rollback conditions before release. If the team relies on ad hoc observation for every deployment, it has not built a reliable delivery system. Automated monitoring should accelerate judgment, not conceal the uncertainty behind a single health badge.

One effective test of the delivery architecture is a production hotfix during a simultaneous platform incident. The team should be able to identify whether the observed fault is caused by the new application version, an expired deployment identity, a failing region or a dependent data service. Decide whether to pause all releases, issue a tightly scoped repair or use an existing rollback target. Emergency processes may shorten certain approvals, but they must preserve traceability and a post-incident review. Measure time to detect and restore service, the quality of diagnostic evidence, and how many unintended changes occurred during recovery. If the incident response requires copying an untested binary directly onto a production server, the organization's normal delivery path has failed to accommodate a predictable operational situation.

Use a release incident as an exam preparation laboratory

Construct a small application with source control, tests, a container or package artifact, infrastructure declarations and a staging-to-production pipeline. Introduce a realistic defect: a breaking API change, leaked dependency, lost secret permission, incorrect routing rule or a performance regression after deployment. Follow the evidence through pull requests, build logs, deployment history, infrastructure settings and application traces. Decide what can be rolled back immediately and what needs a separate data recovery or consumer migration plan.

Study the official AZ-400 domains in their published proportions, but do not mistake proportions for permission to ignore smaller topics. The pipeline domain is largest because integration, release and recovery touch every other area. AZ-305 focuses on the architecture being delivered, while AZ-400 is about the controlled machinery that delivers and changes it. A good candidate can explain why one failed release happened, how the process would detect a recurrence, and why the chosen improvement is proportionate to the risk.