Microsoft AZ-400: Practical DevOps Engineering Exercises

Practical AZ-400 preparation should make DevOps decisions visible. The current Microsoft blueprint emphasizes build and release pipelines, but the role still connects source control, collaboration, security, infrastructure as code, deployment, observability, and feedback. A useful lab therefore produces evidence that a change can move from reviewed source to a healthy production state—and can recover when something goes wrong.

Use the Microsoft AZ-400 exam as the target, but build your practice around systems rather than portal steps. Every exercise below should answer four questions: what requirement are you solving, what control enforces it, what evidence proves the result, and what recovery path exists if the change fails?

Exercise 1: design a repository and pull-request policy

Create a small production repository and define the branch model, review requirements, protected paths, validation checks, and emergency-change process. Include one high-risk file such as deployment configuration or security policy and decide whether code owners, additional approval, or specialized validation should protect it.

Then test the policy. Attempt a direct change that should be blocked, submit a compliant pull request, and verify the audit trail. The goal is not to maximize controls; it is to make each rule traceable to a risk such as unreviewed production changes, lost accountability, or accidental bypass.

Exercise 2: build a traceable continuous-integration pipeline

Start from reviewed source, restore dependencies, build the application, run tests, perform quality and security checks, and publish a versioned artifact. Record which commit produced the artifact and which checks were required before publication.

Break one dependency or test and confirm that the artifact is not promoted. Then fix the issue and rerun. This makes CI a quality boundary rather than a YAML exercise.

Exercise 3: promote one artifact through environments

Build once, then promote the same tested artifact through development, test, and production. Keep environment-specific configuration outside the artifact so the binary or package being validated is the one that reaches production.

Add approvals or checks only where the risk justifies them. Introduce a failed production health check and decide whether to halt, roll back, or fix forward. The decision should follow recoverability and user impact, not a universal rule.

Exercise 4: secure identities, secrets, and permissions

Create a deployment identity with intentionally broad access, prove what it can reach, and then reduce it to the minimum durable scope. Replace hard-coded credentials with a supported secret store, managed identity, workload identity federation, or scoped service connection where appropriate.

Test rotation or revocation and preserve evidence showing which principal performed the deployment. Security is stronger when the pipeline can operate without long-lived credentials that are difficult to track or revoke.

Exercise 5: compare GitHub Actions and Azure Pipelines

Implement or model the same deployment in both platforms. Compare runner or agent trust, environment protection, reusable definitions, artifact handling, identity, approvals, integration, and audit evidence. Do not decide that one platform is universally better.

The current AZ-400 role expects familiarity with both GitHub and Azure DevOps. The useful skill is recognizing which control or operating model satisfies the scenario. The AZ-400 source-control guide can support that comparison.

Exercise 6: deliver infrastructure as code and detect drift

Version an infrastructure definition beside the delivery workflow, validate it before deployment, and apply it to a small environment. Then change one resource manually outside the normal path.

Compare actual state with the versioned definition and decide how drift should be detected, approved, reconciled, or reversed. This exercise shows why infrastructure as code is an operating control: it makes intended state reviewable and reproducible.

Exercise 7: instrument the delivery system and workload

Collect signals for pipeline failure rate, duration, deployment success, application health, latency, errors, and important infrastructure metrics. Deploy a deliberately faulty version and identify which signal detects the problem first.

Then follow the evidence to a decision. Monitoring is not complete because a dashboard exists; it is useful when a signal leads to remediation, rollback, capacity action, or investigation.

Exercise 8: create a controlled failure and recovery drill

Break one dependency, revoke one deployment permission, introduce an unhealthy release, or create infrastructure drift. Diagnose the problem from logs, metrics, pipeline state, and configuration before changing anything.

Recover the service and record the timeline, contributing factors, detection point, action taken, and one improvement that would make the same class of failure easier to prevent or detect. The AZ-400 preparation mistakes article is useful for checking whether the lab demonstrated systems thinking rather than familiarity with a tool.

Exercise 9: test reproducibility from a clean environment

Rebuild the delivery process using only source-controlled definitions, documented identities, approved dependencies, and explicit configuration. Any hidden manual state should be classified as code, configuration, secret, or runbook work that still needs to be formalized.

Repeat the exercise after removing one environment dependency. If recovery requires one administrator to remember an undocumented step, the system is not yet reproducible.

Exercise 10: scale the same design beyond one team

For every successful lab, ask what changes when dozens of teams use the same pattern. A branch rule, self-hosted runner, manual approval, or shared template may work well for one service and become a bottleneck at scale.

Identify which decisions should become reusable platform patterns and which must remain service-specific. This distinction separates a working lab from an operable DevOps model.

Build one AZ-400 capstone

Finish with an end-to-end service: reviewed source, CI, versioned artifact, protected deployment, infrastructure as code, scoped identity, observable workload, controlled failure, and documented recovery. Rebuild it from a clean state and explain the evidence at every stage.

Microsoft’s current July 27, 2026 blueprint gives build and release pipelines the largest share of the exam, but pipeline work should still connect to source control, security, communication, and instrumentation. A candidate is ready when those pieces form one delivery system rather than a collection of disconnected tools.