AZ-400: Secure Delivery, Automation and DevOps on Azure

Microsoft AZ-400, Designing and Implementing Microsoft DevOps Solutions, tests the ability to create a delivery system that turns reliable source-code changes into secure, observable production outcomes. The exam is part of the Microsoft Certified: DevOps Engineer Expert pathway. Microsoft's published English-language study guide was updated July 27, 2026. Compared with a purely administrative examination such as AZ-104, AZ-400 connects software engineering, infrastructure operations, automation, security and team feedback into a shared delivery responsibility. Knowing where a pipeline setting appears in a console matters less than understanding which failure that setting prevents.

Imagine a service team that can produce a working application on a developer laptop but routinely breaks production releases. Builds depend on local packages, deployment credentials are copied between engineers, and the team notices failures only when customers complain. Adding a pipeline is not by itself a DevOps solution. The team must control source changes, establish repeatable builds, limit privileges, validate deployments and learn from observed behavior. AZ-400 examines how those practices fit together using Azure, Azure DevOps, GitHub and appropriate supporting services. The best preparation is to reason from a delivery problem to a testable system of controls, not to memorize a particular vendor interface.

Design the delivery workflow around measurable outcomes

A delivery process begins with shared ownership of the path from proposed change to operational result. Product requests, development work, security findings, testing evidence, releases and incidents should not live in disconnected systems that conceal why a change was made. Work items and pull requests can establish traceability: an operator who investigates a failed deployment should be able to identify the relevant commit, artifact, approval and configuration change. Traceability is especially useful when an emergency correction must be compared against a recent planned release.

Metrics require careful interpretation. Deployment frequency and change lead time can reveal delivery delays; change failure rate and time to restore service can reveal whether faster releases are creating instability. A high deployment count is not success if releases repeatedly break a critical transaction. Likewise, low incident volume may reflect weak detection instead of reliable software. Teams should combine delivery measures with service-level indicators such as request errors, latency and business-process completion, and review the results without using individual engineers as the object of blame.

A mature workflow also handles different risk profiles. A documentation correction might deploy automatically after basic validation, while a change to authentication or data migration may require additional reviewers, integration tests or a controlled release window. Specify those rules ahead of time rather than asking a senior engineer to improvise approvals during an outage. The goal is to make ordinary safe changes routine and unusual dangerous changes visible.

Establish source control, branching and change review

Git is not merely a repository for files. It captures the history and review boundaries needed to understand how code entered a deployed artifact. Choose a branch strategy compatible with release frequency and team size. Short-lived branches and frequent integration can reduce difficult merges, but they depend on effective automated checks and mechanisms for leaving incomplete features disabled. Long-lived release branches may be justified for maintained versions, although they increase the work of tracking security fixes across branches.

Pull requests should evaluate meaningful risks: logic changes, database compatibility, dependency versions, secret exposure and security boundaries. Protected branches can require review and successful checks. Required status checks help prevent accidental merges when automated tests are failing; they should be mapped to the correct workflow and cannot substitute for test quality. Configure repository permissions so ordinary contributors do not bypass controls casually and automation tokens have only the privileges they require. Signing, commit traceability and protected environments may add assurance where supply-chain risk warrants it.

Repository structure also affects deployment. An application repository may contain build recipes, infrastructure definitions and deployment templates, but placing every production secret beside code is an obvious control failure. Reusable workflows can centralize common build or security steps; reusable GitHub Actions require versioning and change ownership because a shared workflow update can change many application pipelines at once. Treat actions, tasks and third-party dependencies as software that can introduce risk, not as inherently trustworthy pipeline decorations.

Create reproducible builds and trustworthy pipeline artifacts

A build is reproducible when authorized environments can produce and identify the same intended output from the same input and build configuration. Pin dependency versions where appropriate, use controlled package feeds and establish build agents with known toolchains. Hidden developer-machine state makes production failures hard to diagnose. Pipelines should produce immutable, versioned artifacts that progress through testing and production instead of rebuilding different binaries independently for each environment.

GitHub Actions and Azure Pipelines provide different orchestration and integration patterns, but both require decisions about triggers, agents, caching, identity, test gates, approvals and audit evidence. A successful command exit status is a narrow signal. Integration tests need realistic service dependencies, and release confidence may require static analysis, vulnerability scanning, package provenance and application-level smoke tests. Test results should be associated with the exact artifact that reaches production so investigation does not rely on memory or informal assurances.

Containerized applications introduce an additional boundary between an image build and a running workload. Registry permissions, image tags and digest pinning influence which image is actually deployed. An image scanned at build time can become outdated as new vulnerabilities are disclosed; production inventory and recurring risk review remain necessary. Container CI/CD with Azure Container Registry is relevant when managing artifact promotion, authentication and controlled deployment to container platforms. Keep signing keys and service credentials out of untrusted build contexts, and avoid assuming a successful image push proves the deployed container can reach its required runtime services.

Automate infrastructure without exposing privileged access

Infrastructure as code can make environments more predictable because resources and their configuration are declared, reviewed and deployed under version control. Templates should be parameterized for real environmental differences without turning every resource into an opaque forest of variables. Infrastructure automation must respect existing state: an unintended resource replacement or networking change can create more business impact than a defective application release. Review planned changes, understand dependency order, and consider locks, policy assignments and state-management requirements before an apply operation.

Bicep and Terraform express desired infrastructure using different workflows and state models. The choice should follow the supported platforms, operational skills and governance requirements rather than a belief that a single tool removes configuration risk. A safe pipeline can create an ephemeral environment for functional tests while production resources require a separately authorized deployment identity. Template validation, policy checks and a human-readable plan can catch classes of error, although no static validation proves that a deployed application meets its business objective.

Secrets and identity require defense in depth. Prefer managed identity or workload identity federation when the platform and execution path support it. A secret stored in a pipeline variable may still leak through command-line arguments, logs or excessive diagnostic output. Securing secrets in Azure DevOps pipelines involves short-lived access, controlled scopes, reviewable changes and rotation procedures. Service connections should not grant a repository-wide automation process subscription-owner powers simply because the first deployment was easier with them. Carefully constrain which branches, workflows and environments may use production credentials.

Deploy progressively and retain a credible recovery path

Release design is a risk-management decision. A blue-green approach prepares a second environment and then changes traffic routing; a canary exposes a limited population before broader adoption. Both can reduce exposure to certain defects, but neither automatically handles irreversible database migrations or incompatible message formats. Blue-green and canary deployments should be chosen with application state, traffic behavior and rollback ability in mind. A nominally reversible code release may still corrupt shared data if the new version writes values the old version cannot interpret.

Feature flags can decouple deployment from exposure, allowing the team to test a new path with selected users or turn it off if indicators worsen. Flags also create debt when abandoned, and targeting rules can become security-sensitive if used to determine access rather than simply feature visibility. Operational owners should know which signals trigger a rollout halt, who is authorized to make that decision and what happens to in-flight requests. Release evidence should show which version is active in each environment, not only which pipeline job ran most recently.

Release gates and progressive delivery connect automated health checks and approval policies to meaningful deployment stages. A gate based only on zero infrastructure alarms may approve a broken checkout service. Validate representative business requests, error budgets, dependency connectivity and security anomalies. Define pause, rollback and forward-fix criteria before exposure expands. For systems with complex state migrations, a forward-compatible change sequence may offer a safer recovery path than promising an instant reversal after data contracts have changed.

Integrate security, testing and compliance into delivery

DevSecOps should provide security evidence continuously instead of treating every release as a last-minute compliance exercise. Source scanning can identify credentials and vulnerable coding patterns; dependency analysis can reveal known issues in libraries; infrastructure checks can detect dangerous public exposure or missing policy controls. These signals differ in certainty and impact. A high-volume scanner with many untriaged findings can desensitize engineers, while a pipeline with no scanning may allow predictable mistakes to persist. Assign responsibility for reviewing findings, set risk-based thresholds and record justified exceptions with expiry dates.

DevSecOps controls in Azure delivery pipelines belong within a broader assurance system that includes peer review, segregation of duties and production access logs. An isolated deployment stage should not allow an untrusted pull-request workflow to read production credentials. Keep audit records for approvals and artifact changes, but also plan retention, privacy and incident access requirements. Compliance evidence is strongest when it records an actual repeatable control, not a screenshot taken once for an assessment.

Testing strategy should match failure modes: unit tests detect local regressions, contract tests reveal interface incompatibilities, integration tests examine dependencies and load tests expose capacity problems. For a system that publishes transactions to a queue, a healthy HTTP response is not enough if messages are silently rejected downstream. Exercise transient failures, permission errors and malformed responses in safe environments, and confirm that the application fails predictably. These tests are especially valuable before automating a release gate that might otherwise mistake a narrow green test suite for comprehensive safety.

Build operational feedback into every release

Deployment is not the end of the change lifecycle. Application Insights, Azure Monitor and other telemetry sources can connect requests, dependencies, logs and traces so an operator can distinguish an application defect from an unavailable database, throttled API or network configuration problem. Establish meaningful correlation identifiers and evaluate whether traces include sensitive data that should not be retained. Good observability helps engineers answer what changed, who is affected, where latency emerged and whether a rollback improved the service.

Alert design should express customer impact and ownership. A warning that every web server has 60 percent CPU utilization may be irrelevant, while a rising failure rate for payment capture is immediately important. Set thresholds, suppression behavior and escalation procedures according to service objectives. Use post-incident reviews to improve reliability without deleting the factual timeline of what happened. An incident may reveal a missing pre-production test, an unsafe deployment permission, a fragile dependency or a rollback that takes too long. Convert such findings into changes that can be verified at the next release rather than accumulating an unowned action list.

To practice, trace a small API change from a work item through a reviewed commit, reproducible build, automated tests, artifact signing or integrity verification, limited rollout and production observation. Deliberately inject a harmless fault in a non-production environment and document the halt or recovery decision. Then repeat the exercise after correcting the issue, demonstrating that the original artifact and its approvals can be audited. This end-to-end discipline is the central skill of AZ-400: reliable delivery emerges from aligned source control, infrastructure, identity, security, deployment decisions and operational evidence, not from an attractive pipeline diagram.