The AZ-400 blueprint is unusually concentrated: build and release pipelines account for 50–55% of the current exam. A practical study sequence should therefore establish workflow and source control quickly, spend the largest block on CI/CD and IaC, then integrate security and instrumentation. The current AZ-400 skills were updated on July 27, 2026.
Phase one: learn the delivery loop and metrics
Start with flow of work, GitHub Flow, Azure Boards, GitHub Issues/Projects, traceability, feedback, dashboards, cycle time, lead time, time to recovery, and cross-functional metrics.
A work-tracking exercise should connect one feature from request through code, build, deployment, and production feedback.
Phase two: design source control deliberately
Compare trunk-based, feature-branch, and release-branch strategies. Build pull-request workflows, branch protection/policies, required reviews, merge restrictions, permissions, tags, Git LFS/large-file handling, and repository-recovery practices.
Introduce one accidental secret or oversized binary in a lab and practice the safe remediation path.
Phase three: learn package and artifact discipline
Use Azure Artifacts or GitHub Packages to publish a small package. Apply semantic or calendar versioning and distinguish package versions from pipeline artifacts.
Reproducibility improves when downstream jobs consume explicit versions rather than mutable “latest” outputs.
Phase four: give the largest block to CI pipelines
Build pipelines in both GitHub Actions and Azure Pipelines where possible. Practice YAML, triggers, job/stage order, parallelism, hosted versus self-hosted agents/runners, reusable templates, variables, and integration between GitHub repositories and Azure Pipelines.
A pipeline lab should include a deliberate failure so logs and retry behavior become familiar.
Phase five: add testing and gates
Include unit, integration, load, and other relevant tests; publish results; inspect code coverage; and add quality, security, and governance gates at the appropriate stages.
Do not make every test block every commit. Learn where fast checks, deeper validation, and release approvals belong.
Phase six: practice progressive deployment patterns
Compare blue-green, canary, ring, rolling, A/B testing, feature flags, and deployment slots. Define success/rollback criteria before release.
Then add a database change or dependency ordering requirement so deployment becomes a multi-component problem.
Phase seven: make infrastructure as code part of the pipeline
Use Bicep or ARM plus source control and automated validation. Add Azure Machine Configuration, Automation State Configuration, or Azure Deployment Environments conceptually where appropriate.
Infrastructure definitions should move through review and promotion rather than being edited manually in production.
Phase eight: integrate identity, secrets, and scanning
Practice managed identity/service principal decisions, service connections, GitHub authentication, Key Vault, OIDC/workload identity federation, and secure-file handling. Then add dependency, secret, code, license, container, and vulnerability scanning.
A DevSecOps review should show how each security check prevents or detects a different supply-chain risk.
Phase nine: instrument the environment and pipelines
Configure Azure Monitor/Application Insights concepts, pipeline alerts, GitHub insights, infrastructure metrics, distributed traces, and simple KQL queries. Track pipeline health such as duration, failure rate, flaky tests, concurrency, cost, and artifact retention.
A continuous-monitoring exercise should feed at least one production finding back into the backlog.
Finish with end-to-end delivery failures
Use mixed scenarios: broken branch policy, flaky test, exhausted runner capacity, secret leak, vulnerable dependency, failed canary, database migration problem, or missing telemetry. Diagnose the stage first and avoid fixing symptoms in the wrong tool.
Keep one sample service throughout preparation. Give it a backlog, Git repository, package dependency, pipeline, infrastructure definition, staging and production environments, telemetry, and one security requirement. Reuse creates context so every AZ-400 objective becomes part of one delivery system.
During flow-of-work study, measure one feature from work-item creation to production. Note waiting time in refinement, development, review, build, approval, and deployment. This makes lead time and cycle time useful rather than abstract metrics.
During collaboration study, create release notes and a Mermaid deployment diagram from repository information. Then automate at least part of the documentation. The goal is to reduce stale manual documentation without producing unreadable generated output.
During branch-strategy study, run the same small feature through trunk-based and feature-branch approaches. Compare merge frequency, conflict risk, release isolation, and policy. The best strategy depends on team and product constraints rather than fashion.
During repository-security study, commit a fake test secret, then practice removing it and rotating the credential conceptually. Add secret scanning so the same mistake is blocked earlier. This reinforces that Git history and credential validity are separate incident concerns.
During package study, publish version 1.0.0 and a breaking 2.0.0 of a sample library. Observe how explicit dependency versions protect downstream builds. Then add an upstream dependency and discuss how a compromised package source could affect the pipeline.
During runner/agent study, compare hosted and self-hosted execution with a private endpoint or internal resource requirement. Decide whether network reachability justifies self-hosting and which patching, autoscaling, isolation, and credential controls you would need.
During YAML study, extract repeated stages into templates. Version the template and deliberately make one incompatible change. This teaches that shared pipeline code needs the same compatibility discipline as shared application libraries.
During test strategy, classify checks by speed and risk. Unit tests should be fast enough for frequent feedback; integration or load tests may run later; security and governance gates should block at the earliest stage where the evidence is reliable.
During deployment-pattern study, use the same application with canary and blue-green designs. Define traffic movement, rollback, database compatibility, and telemetry. If you cannot explain which failure each pattern contains, the deployment concept is not yet practical.
During feature-flag study, deploy code with a feature disabled, enable it for a limited cohort, monitor behavior, and turn it off without redeploying. This demonstrates why deployment and feature release can be separated.
During IaC study, review the same pull request for application and infrastructure changes. Run lint/validation, security checks, and a preview/diff. Infrastructure should not receive weaker change control merely because it is declarative.
During self-service environment study, design an approved template developers can deploy without platform-team tickets. Define limits, network/security defaults, naming, cost controls, and cleanup. Platform engineering succeeds when self-service is both fast and governed.
During identity study, replace one stored cloud secret with OIDC/workload identity federation. Document the trust relationship and permission scope. This provides a memorable example of how modern pipelines reduce secret-management burden.
During DevSecOps study, introduce one dependency vulnerability, one code finding, and one secret leak. Decide which should block merge, block release, or create a remediation issue based on severity and context. Not every scanner finding deserves identical treatment.
During instrumentation study, define a release dashboard that includes application errors/latency plus deployment version. Without version correlation, teams may detect a problem but struggle to determine whether the most recent release caused it.
During KQL practice, keep queries tied to operational questions: Did error rate rise after version X? Which requests are slow? Which dependency is failing? The exam expects useful analysis, not advanced data-engineering mastery.
In final practice, identify the stage before choosing the product. Is the problem work flow, Git policy, package provenance, CI execution, deployment strategy, identity/secrets, security scanning, or instrumentation? Stage classification quickly narrows the answer choices.
Before scheduling the exam, rebuild the 10–15/10–15/50–55/10–15/5–10 weighting and one applied example per domain. If more than half your study notes are not pipeline-related, rebalance them to match the current exam.
Add a work-item-to-release traceability drill. Start from a bug, create the fix branch, open a pull request, run CI, publish an artifact, deploy it, and link the production result back to the original work item. This is the simplest way to make “traceability” feel operational rather than theoretical.
Add a release-notes exercise using Git history or automated tooling. The output should explain meaningful user or operational changes, not just dump commit messages. Good release documentation supports support teams, auditors, and incident responders after deployment.
Add a repository-permission review. Separate read, contribute, maintain, and administrative responsibilities for developers, bots, and external collaborators. Source control is a production security boundary because a malicious or accidental merge can flow directly into automated delivery.
Add a pipeline-template ownership scenario. One central template controls deployment for many teams. Define versioning, testing, rollout, and rollback for template changes so a central improvement does not become a fleet-wide outage. Platform code deserves production-grade change management.
Add an environment approval design for production, staging, and ephemeral test environments. Decide which can deploy automatically and which require checks. Then introduce an emergency hotfix and use the predefined expedited path rather than inventing approvals under pressure.
Add one pipeline-resilience exercise where a hosted service is unavailable or a self-hosted runner pool is exhausted. Decide whether jobs queue, fail over, or use an alternate pool. The current blueprint treats runner/agent architecture as a real availability concern.
Add a release-observability drill: deploy a canary, watch error rate, latency, and business signal, then either promote or roll back based on thresholds. This ties the 50–55% pipeline domain to the 5–10% instrumentation domain in the way Microsoft expects.
Add one final “delivery-system ownership” review. For each component—repository, runner pool, shared template, package feed, service connection, environment approval, monitoring, and incident runbook—name the team that owns maintenance and escalation. DevOps automation becomes fragile when shared components have no explicit operational owner.
Finish by writing a one-page architecture for the delivery platform itself: code hosts, work tracking, runners, artifact stores, deployment targets, identities, security scanners, and telemetry. If you can explain the dependencies and failure modes of that platform, your AZ-400 preparation has moved beyond individual features into systems thinking.
The AZ-400 study model is strongest when one application moves through the full delivery loop repeatedly. That is closer to real DevOps work than memorizing Azure DevOps and GitHub features separately.