AZ-400 Microsoft DevOps Engineer: Building Secure Delivery Systems with GitHub and Azure DevOps

AZ-400, Designing and Implementing Microsoft DevOps Solutions, is the current exam for the Microsoft Certified: DevOps Engineer Expert credential. Microsoft updated the English exam on July 27, 2026. The role combines development and infrastructure experience with the ability to improve flow, collaboration, source control, build and release automation, security, compliance, instrumentation, and feedback across the software-delivery lifecycle.

The exam is not a checklist of Azure DevOps buttons. Microsoft explicitly expects candidates to work with both GitHub and Azure DevOps solutions and to understand why a delivery system is designed a certain way. A pipeline that compiles code is only one piece. DevOps engineering also includes branching strategy, artifact integrity, infrastructure automation, environment protection, secrets, observability, deployment safety, team communication, and the mechanisms that turn production feedback into the next engineering decision.

As of October 3, 2026, AZ-400 remains current and schedulable. The expert credential requires experience in Azure administration or development, which makes sense because DevOps engineers automate systems other teams have to operate. Within the broader Microsoft certifications portfolio, AZ-400 rewards candidates who can connect tools and process into a delivery system that is fast enough for the business and controlled enough for production.

Flow and collaboration are engineering concerns, not management decoration

DevOps begins with how work moves from idea to production. Large batches, unclear ownership, long-lived handoffs, and hidden queues increase delay and risk. Teams improve flow by making work visible, limiting unnecessary parallel activity, reducing batch size, automating repeatable checks, and establishing feedback loops that reveal problems early.

Boards, issues, pull requests, code review, documentation, and chat integrations are useful only when they support the team’s working model. A process that requires dozens of fields nobody uses can slow delivery without improving control. Conversely, informal delivery with no traceability can make audit, incident response, and root-cause analysis difficult.

Candidates should be able to connect process design to measurable outcomes such as lead time, deployment frequency, change failure rate, mean time to recovery, review latency, or work-in-progress. The goal is not to chase a metric in isolation but to find constraints and test whether an improvement changes system performance.

Source control strategy should make change safe and reviewable

Git is the foundation for modern delivery, but repository structure and branch strategy depend on how teams release. Trunk-based development can reduce merge complexity when automated testing and feature-control practices are strong. Release branches may be appropriate for products that support multiple maintained versions. The important skill is to align branching with deployment and support needs rather than copy a diagram because it is popular.

Pull requests can enforce review, build validation, security scanning, and policy before changes reach protected branches. CODEOWNERS, status checks, branch protection, signed commits where required, and permissions all contribute to trust. The controls should protect important changes without creating unnecessary manual gates for low-risk work.

The GitHub Actions ecosystem is particularly relevant because Microsoft expects DevOps engineers to work across GitHub and Azure DevOps. Candidates should understand workflow triggers, jobs, runners, environments, reusable workflows, secrets, artifacts, and how repository events can drive automation without granting excessive permissions.

Continuous integration is about fast evidence, not merely automatic builds

A useful CI pipeline tells developers quickly whether a change is safe to integrate. Compilation, unit tests, linting, static analysis, dependency checks, secret scanning, container-image scanning, and packaging can all contribute evidence. The pipeline should fail clearly when a quality or security condition is not met and should make the reason easy to diagnose.

Build reproducibility matters. Dependencies should be versioned or controlled, build environments should be predictable, and artifacts should be immutable after creation. Rebuilding a release from a developer’s workstation weeks later is weaker than promoting a tested artifact through environments. Artifact repositories and provenance help teams know exactly what was deployed.

Parallelization and caching can reduce pipeline time, but speed should not hide nondeterminism. A flaky test that passes on retry weakens trust. DevOps engineers need to investigate unstable checks because teams eventually ignore gates that produce too many false failures.

Release strategy should reduce blast radius while preserving speed

Continuous delivery separates the ability to deploy from the decision to expose change broadly. Deployment slots, blue/green patterns, canary releases, feature flags, staged environments, and progressive traffic shifting can reduce risk. The correct method depends on application architecture, data compatibility, rollback constraints, and how quickly health signals become meaningful.

A rollback plan should account for databases and external side effects. Reverting application code is easy only when schema changes and message formats remain compatible. Safer delivery often uses backward-compatible database changes, expand-and-contract migrations, and feature controls that let teams disable behavior without redeploying every component.

Environment protections can require approvals, checks, or manual validation for high-risk stages. Those controls should be based on risk rather than tradition. A routine low-risk deployment with strong automated evidence may need less manual intervention than a privileged infrastructure change affecting identity or network boundaries.

Infrastructure as code turns platform changes into reviewable software

Infrastructure should be versioned, tested, reviewed, and deployed through controlled workflows where practical. Bicep, ARM templates, Terraform, and configuration-management tools allow teams to describe desired state and reduce manual drift. The specific syntax matters less than understanding modules, state, dependencies, secrets, environments, and change planning.

Candidates who want focused validation of Terraform skills can validate them through Terraform Associate 004. In AZ-400, the emphasis is broader: how infrastructure code participates in a delivery system. Plans should be reviewed before apply, privileged credentials should be protected, remote state should be secured, and destructive changes should be visible before production execution.

Reusable modules can accelerate delivery but should have ownership and versioning. A shared module that changes unexpectedly can break many teams. Treating platform components as products—with documentation, tests, release notes, and compatibility expectations—makes enterprise infrastructure automation more sustainable.

DevSecOps integrates security evidence into the same delivery flow

Security is most effective when checks happen close to the change. Static code analysis, dependency scanning, container scanning, secret detection, infrastructure policy, and permissions review can run automatically. High-confidence findings can block progression; lower-confidence findings may create review work without stopping every build.

Secrets should not be copied into pipeline variables casually. Federated identity, managed identities, secure service connections, vault integration, and least-privilege tokens can reduce credential exposure. Build agents and self-hosted runners deserve special attention because a compromised runner may have access to source code, artifacts, secrets, or deployment networks.

Software supply-chain security also includes artifact signing, provenance, dependency trust, and controlled package sources. DevOps engineers should know where code and binaries come from and how a release can be traced back to a reviewed commit and an approved build.

Observability turns production into a feedback source

Instrumentation is one of the areas that distinguishes DevOps from pipeline administration. Applications and platforms should expose metrics, logs, traces, availability checks, and deployment markers so teams can see whether a release improved or degraded the service. Alerts should connect to operational response, not merely populate dashboards.

Release pipelines can use health evidence to stop or roll back progression. A canary that produces elevated errors or latency should not be promoted because the deployment job itself succeeded. This requires meaningful service-level indicators and enough telemetry to compare versions and isolate dependencies.

Post-incident reviews should feed improvement back into code, automation, documentation, or architecture. The objective is learning, not blame. Repeated incidents caused by the same manual step or missing test indicate a system problem that DevOps practices should address.

Prepare by designing complete delivery paths

The strongest preparation is to take a small application from repository to production-like deployment. Protect the main branch, configure CI, create an artifact, scan it, provision infrastructure, deploy to an environment, store secrets safely, collect telemetry, and test a rollback. Then change one assumption—add a second region, require an approval, rotate credentials, or introduce a database migration—and update the pipeline.

The discussion in AZ-400 DevOps practices is most valuable when it reinforces the system view. Tools matter, but the exam is really about using them to create a dependable flow from idea to production and back through feedback.

Delivery-system reliability deserves the same engineering attention as application reliability. Hosted and self-hosted runners, package registries, artifact stores, service connections, branch policies, and deployment environments can become critical dependencies. Teams should know how builds continue during an outage, which credentials can be rotated quickly, and how to recover pipeline configuration from versioned definitions rather than reconstructing it manually.

DevOps engineers should also manage platform change as a product. Shared pipeline templates and reusable workflows need versioning, compatibility expectations, release notes, and a controlled upgrade path. A centrally edited template that silently changes hundreds of repositories may be efficient until it breaks every deployment at once. Reuse is valuable when consumers can understand and adopt change deliberately.

Performance of the delivery process matters as well. Long queues and slow builds encourage developers to batch changes or bypass checks. Measuring queue time, test duration, cache effectiveness, flaky-test rate, and deployment latency can reveal where engineering effort will improve both developer experience and release safety.

Dependency management is another delivery-system concern. Teams should know which packages are direct dependencies, which are transitive, how updates are reviewed, and how vulnerable or abandoned components are replaced. Automated update tooling can reduce lag, but changes still need tests and release evidence. The objective is a supply chain that can evolve without silently introducing unreviewed production risk.

AZ-400 candidates should be able to explain why a control exists, what risk it reduces, and how it affects delivery speed. A mature DevOps system does not choose between speed and safety as opposites. It uses automation, small changes, evidence, and observability to improve both.