--- title: "AZ-400 Study Guide — DevOps Engineer Expert" description: "An interactive study guide built on 7 memory techniques to help you pass the AZ-400: Designing and Implementing Microsoft DevOps Solutions exam." url: "https://lucidlabs.com.au/insights/az-400" --- # Master the AZ-400 An interactive study guide built on 7 memory techniques to help you pass the AZ-400: Designing and Implementing Microsoft DevOps Solutions exam. Design and implement processes and communications 10-15%Design and implement a source control strategy 10-15%Design and implement build and release pipelines 50-55%Develop a security and compliance plan 10-15%Implement an instrumentation strategy 5-10% What it covers The Expert-level capstone for DevOps: process and communication design, Git branching strategy, Azure Boards/Repos, YAML build and multi-stage release pipelines, deployment patterns (blue-green, canary, ring-based), Infrastructure as Code with Bicep/ARM/Terraform, Azure Artifacts and dependency management, security scanning (SAST/DAST/SCA) and Key Vault integration, and instrumentation with Application Insights and Azure Monitor. Ideal for DevOps engineers, platform engineers, and Azure administrators or developers who already run CI/CD and want the Expert credential that proves end-to-end delivery capability across both GitHub and Azure DevOps. Aspire to this if You already hold AZ-104 (Azure Administrator) or AZ-204 (Azure Developer) and want the capstone Expert certification that proves you can design and run continuous delivery across the whole toolchain — not just one half of it. Section 1 / Spatial Memory ## The Map Tap any component to see what you need to know for the exam. **🤝 Process & Communication** Agile · SRE · Value Streams **📋 Work Item Tracking** Azure Boards · Kanban · Traceability **🌳 Source Control Strategy** Trunk-based · GitFlow · Release Flow **🔀 Repos & Branch Policies** Reviews · Status Checks · CODEOWNERS **🏗️ Build Pipelines (CI)** YAML · Multi-stage · Triggers **📦 Artifacts & Dependencies** Feeds · Upstream Sources · SemVer **🚀 Release Pipelines (CD)** Stages · Approvals · Environments **🎯 Deployment Patterns & Gates** Blue-green · Canary · Rings **🧱 Infrastructure as Code** Bicep · ARM · Terraform **🔍 Security Scanning** SAST · DAST · SCA **🔐 Secrets & Compliance** Key Vault · Managed Identity · Audit **📊 Instrumentation & Feedback** App Insights · Monitor · DORA Section 2 / Narrative Memory ## The Story Follow the narrative to build a mental model of how everything connects. 🤝 ### The Alignment Before a single pipeline runs, teams must agree on how they work together. Agile ceremonies set the cadence, value stream mapping exposes where work stalls, and SRE thinking introduces error budgets so reliability and velocity stop fighting each other. DevOps starts as a culture problem, not a tooling problem. **Exam Intel**Know the difference between Scrum (fixed sprints), Kanban (continuous flow, WIP limits), and SAFe (scaled agile across teams). Error budget: the acceptable amount of unreliability before feature work pauses for reliability work. 📋 ### The Backlog Every unit of work lives in Azure Boards — epics break into features, features into stories, stories into tasks. Kanban boards make flow visible; a WIP limit stops a team from starting ten things and finishing none. Traceability threads a single work item all the way through to the commit, the build, and the release that shipped it. **Exam Intel**Hierarchy: Epic → Feature → User Story/Bug → Task. Velocity and burndown/burnup charts forecast sprint completion. Dashboards and Analytics views report cycle time — know the difference between cycle time and lead time. 🌳 ### The Fork in the Road Every team must choose how code branches. Trunk-based development keeps branches short and merges constantly — fast, but demands strong automated testing and feature flags to hide unfinished work. GitFlow keeps long-lived release branches — safer for scheduled releases, slower to integrate. Release flow, Microsoft’s own model, branches from main per release and only ever fixes forward. **Exam Intel**Trunk-based = high merge frequency, low branch lifespan, needs feature flags. GitFlow = develop/release/hotfix branches, good for versioned/shipped software. Release flow = release branch per sprint, cherry-pick or forward-fix, no going backward. 🔀 ### The Gatekeeper A branch is only as trustworthy as the policy protecting it. Required reviewers, linked work items, and passing builds all have to clock in before a pull request can merge. CODEOWNERS automatically pulls in the right expert for the right file. Forks keep outside contributors at arm’s length from anything protected. **Exam Intel**Branch policies: minimum reviewers, linked work items required, build validation, comment resolution required. Required status checks block merge on failing CI. CODEOWNERS auto-assigns reviewers by path pattern. 🏗️ ### The Assembly Line A push lands, and the build pipeline wakes up. YAML defines every stage as code — build, unit test, package — versioned right alongside the source it compiles. Multi-stage pipelines chain the whole journey from commit to artifact in a single file, triggered by CI pushes, pull requests, schedules, or another pipeline’s own output. **Exam Intel**YAML pipelines are the recommended pattern over classic (designer-based) pipelines — auditable, code-reviewable, versioned. Microsoft-hosted agents need zero maintenance; self-hosted agents give you control (private network, custom tools, GPU). 📦 ### The Warehouse Nothing gets built from scratch every time. Azure Artifacts feeds host NuGet, npm, Maven, Python, and Universal Packages, with upstream sources proxying the public internet so a single internal feed becomes the source of truth. Semantic versioning is the contract that stops today’s build from silently breaking tomorrow’s consumer. **Exam Intel**Feed types: NuGet, npm, Maven, Python, Universal Packages. Upstream sources cache/proxy public registries (npmjs, NuGet.org). SemVer: major.minor.patch — major breaks compatibility. GitHub Packages is the equivalent when standardised on GitHub. 🚀 ### The Launch Sequence A build artifact becomes a release only after passing through staged environments — dev, test, staging, production — each one a gate for the next. Approvals pause the pipeline for a human sign-off; automated checks pause it for a machine one. This is where 50%+ of the exam lives: the mechanics of getting code safely, repeatably, into production. **Exam Intel**Stages have explicit dependsOn relationships. Approvals: pre-deployment and post-deployment, with timeout and required approver count. Deployment jobs: runOnce (default), rolling (batch through instances), canary (Kubernetes-native). 🎯 ### The Blast Radius Shipping to everyone at once is a bet you don’t need to make. Blue-green keeps two identical environments and flips traffic between them instantly — rollback is just flipping back. Canary sends a sliver of real traffic to the new version and watches. Ring-based deployment goes further, expanding in concentric circles from an internal ring outward to the whole customer base. **Exam Intel**Blue-green = instant cutover + instant rollback, needs double the environment. Canary = small % traffic, monitor before proceeding. Ring-based = staged concentric rollout (Microsoft uses this internally: Ring 0 → Ring 3+). Release gates: work item query, Azure Monitor alert, REST API call, security/compliance scan. 🧱 ### The Blueprint Infrastructure is code now, not a ticket to the platform team. Bicep compiles down to ARM and deploys idempotently — run it twice, get the same result. Terraform trades that Azure-native tightness for multi-cloud reach, tracking reality in a state file and previewing every change with a plan before it touches anything. **Exam Intel**Bicep/ARM: Azure-native, idempotent, what-if preview. Terraform: multi-cloud, state file (local or remote backend), plan then apply. IaC belongs in the same pipeline as the app it provisions for — infra and code stay in lockstep. 🔍 ### The Inspection Security that only happens right before release is security that happens too late. SAST reads the source without running it, catching injection flaws and hard-coded secrets at the PR stage. DAST attacks a running instance the way an actual adversary would. SCA checks whether any of the hundred open-source packages you depend on have a known CVE attached. **Exam Intel**SAST = static, source-level, shift-left (runs in PR/build). DAST = dynamic, runtime, needs a deployed target. SCA = dependency/component scanning — GitHub Dependabot and GitHub Advanced Security are the named tools. Container scanning covers base images and layers. 🔐 ### The Vault A secret typed into a pipeline’s YAML is a secret that is no longer secret. Azure Key Vault holds it instead, and a variable group links the pipeline to the vault without ever exposing the value in source control. Service connections increasingly skip stored credentials entirely, authenticating via managed identity or workload identity federation. **Exam Intel**Variable groups can link to Key Vault secrets by reference, not value. Managed identity / workload identity federation removes long-lived service principal secrets. Every approval, permission change, and deployment must be traceable for compliance (SOC 2, ISO 27001 style audits). 📊 ### The Feedback Loop The pipeline doesn’t end at deployment — it ends when production tells you the truth. Application Insights streams telemetry back the moment users touch the new release. Azure Monitor alerts can halt or roll back a bad deployment automatically. DORA metrics turn all of it into a scoreboard: how often you ship, how fast you recover, how often it breaks. **Exam Intel**Application Insights: requests, dependencies, exceptions, custom events, distributed tracing. Azure Monitor alerts can be wired directly into release gates. DORA metrics: deployment frequency, lead time for changes, mean time to restore (MTTR), change failure rate. Section 3 / Acronym Memory ## Mnemonic Wall Memorable acronyms and phrases to anchor key exam concepts in your memory. 🌳 TGR **T**runk-based, **G**itFlow, **R**elease flow The three Git branching strategies AZ-400 expects you to compare and recommend for a given scenario. 🎯 BCR **B**lue-green, **C**anary, **R**ing-based Three deployment patterns that minimise risk and downtime during a release — know the trigger words for each. 🔍 SDS **S**AST, **D**AST, **S**CA Three security scanning types across the pipeline — static code, dynamic runtime, and dependency composition. 🚦 WAR **W**ork item query, **A**zure Monitor alert, **R**EST API call Three common automated release gate checks that must pass before a stage is allowed to proceed. 🧱 BAT **B**icep, **A**RM templates, **T**erraform The three IaC languages tested — Azure-native declarative (Bicep/ARM) versus multi-cloud (Terraform). 🔐 KVM **K**ey Vault, **V**ariable groups, **M**anaged identity The secretless pipeline chain — Key Vault stores it, a variable group links it in, managed identity authenticates without any stored credential. Section 4 / Contrast Memory ## Versus Arena Side-by-side comparisons to sharpen your understanding of similar concepts. vs Azure PipelinesvsGitHub Actions Click to compare #### Azure Pipelines vs GitHub Actions | Aspect | Azure Pipelines | GitHub Actions | | --- | --- | --- | | Definition file | azure-pipelines.yml | .github/workflows/\*.yml | | Release model | Multi-stage pipelines with environments | Jobs + environments with protection rules | | Compute | Microsoft-hosted or self-hosted agents | GitHub-hosted or self-hosted runners | | Approvals | Stage approvals and checks | Environment required reviewers | | Package hosting | Azure Artifacts | GitHub Packages | | Best for | Azure Boards-integrated enterprise CI/CD | GitHub-native repos, open-source, tight PR integration | Click to flip back vs Blue-GreenvsCanaryvsRing-Based Click to compare #### Blue-Green vs Canary vs Ring-Based Deployment | Aspect | Blue-Green | Canary | Ring-Based | | --- | --- | --- | --- | | Traffic shift | Instant cutover | Small % gradually increased | Concentric rings expanding outward | | Environments needed | Two full identical environments | One + routing | One, segmented by ring | | Rollback speed | Instant (flip back) | Fast (route back) | Slower — ring-by-ring | | Risk exposure | All-or-nothing per flip | Small, monitored slice | Very small, then progressively larger | | Typical use | Stateless web apps | User-facing features | Platform-wide or OS-level rollouts | | Best for | Zero-downtime releases | Validated gradual rollout | High-blast-radius changes needing staged trust | Click to flip back vs Azure ArtifactsvsGitHub Packages Click to compare #### Azure Artifacts vs GitHub Packages | Aspect | Azure Artifacts | GitHub Packages | | --- | --- | --- | | Feed types | NuGet, npm, Maven, Python, Universal | npm, NuGet, Maven, Docker/container, RubyGems | | Upstream sources | Proxies public registries into one feed | Consumes directly from public registries | | Scoping | Organisation or project-level feeds | Repository or organisation-level packages | | Views | Local, prerelease, release promotion views | Tied to repository visibility and releases | | Native integration | Azure Pipelines and Azure Boards | GitHub Actions and GitHub repositories | | Best for | Azure DevOps-centric toolchains | GitHub-centric toolchains | Click to flip back vs Bicep/ARMvsTerraform Click to compare #### Bicep/ARM Templates vs Terraform | Aspect | Bicep/ARM | Terraform | | --- | --- | --- | | Cloud scope | Azure-only, native to Azure Resource Manager | Multi-cloud (Azure, AWS, GCP, and more) | | State tracking | Stateless — ARM tracks deployed resources | State file (local or remote backend, e.g. Azure Storage) | | Change preview | what-if command | terraform plan | | Language | Bicep DSL (compiles to ARM JSON) | HCL (HashiCorp Configuration Language) | | Idempotency | Native — same template, same result | Native — reconciles state on each apply | | Best for | Azure-only shops wanting native tooling | Hybrid or multi-cloud infrastructure | Click to flip back vs SASTvsDAST Click to compare #### Static vs Dynamic Application Security Testing | Aspect | SAST | DAST | | --- | --- | --- | | When it runs | Against source code, no execution needed | Against a running, deployed application | | Pipeline stage | PR / build stage (shift-left) | After deploy to a test environment | | Finds | Injection flaws, hard-coded secrets, unsafe patterns | Exploitable runtime behaviour, auth bypass, config issues | | False positives | Higher — no runtime context | Lower — tests real behaviour | | Speed | Fast, runs on every PR | Slower, typically scheduled or pre-release | | Best for | Catching issues before they merge | Validating the deployed system as attackers see it | Click to flip back Section 5 / Grouping Memory ## Cheat Sheet Organised reference grouped by exam domain — everything you need on one page. ### Design and Implement Processes and Communications 10-15% #### Agile & Process - Scrum, Kanban, and SAFe practices support continuous delivery of value - Value stream mapping identifies waste and delay across the delivery pipeline - SRE principles: error budgets, blameless postmortems, toil reduction - Communication plans align Dev, Ops, QA, and Security stakeholders - InnerSource models scale collaboration using open-source contribution patterns #### Work Item Tracking - Azure Boards hierarchy: Epic > Feature > User Story/Bug > Task - Kanban boards visualise flow; WIP limits prevent overloading a stage - Sprints/iterations forecast delivery using velocity and burndown charts - Dashboards and Analytics views report cycle time and lead time - Traceability: work items link to commits, PRs, builds, and releases #### Team Collaboration - Pull request templates standardise review expectations - CODEOWNERS routes review requests automatically by file path - Wikis and READMEs document decisions alongside the code they describe - Retrospectives feed process improvements back into the next sprint - Teams/Slack integrations surface pipeline and PR events where people work ### Design and Implement a Source Control Strategy 10-15% #### Branching Strategies - Trunk-based development: short-lived branches, frequent merges to main - GitFlow: long-lived develop/release/hotfix branches for scheduled releases - Release flow (Microsoft model): branch from main per release, forward-fix only - Feature branching: one branch per feature, merged via pull request - Feature flags let trunk-based teams hide incomplete work in production #### Repo Governance - Branch policies: required reviewers, linked work items, build validation - Required status checks block merge until CI and PR checks pass - CODEOWNERS auto-assigns reviewers by path - Fork-based contribution isolates external contributors from protected branches - Git hooks (pre-commit, pre-push) enforce checks before code reaches the remote #### Git Operations - git rebase keeps history linear; git merge preserves full branch history - Squash merges collapse a PR into a single commit on the target branch - Git submodules/subtrees manage nested repository dependencies - Git LFS (Large File Storage) manages binary assets without bloating history - Monorepo vs polyrepo trade-offs affect build scope and ownership boundaries ### Design and Implement Build and Release Pipelines 50-55% #### Build Pipelines (CI) - YAML pipelines are versioned as code; recommended over classic pipelines - Multi-stage pipelines chain build, test, and deploy in a single file - Triggers: CI (push), PR validation, scheduled, and pipeline resource triggers - Microsoft-hosted agents = zero maintenance; self-hosted = full control - Templates and variable groups share configuration across pipelines #### Release Pipelines (CD) - Stages represent environments (dev/test/staging/prod) with dependencies - Approvals and checks gate a stage before deployment proceeds - Deployment jobs: runOnce, rolling, and canary (Kubernetes) strategies - Environments in Azure Pipelines track deployment history per resource - Deployment groups target multiple on-prem or VM-based servers #### Deployment Patterns - Blue-green: swap traffic between two identical environments, zero downtime - Canary: route a small % of traffic to the new version before full rollout - Ring-based: progressive expansion — canary ring → early adopters → broad - Release gates automate checks: work item query, Azure Monitor alert, REST API - Rollback strategy must be defined before every production deployment #### IaC & Artifacts - Bicep/ARM: Azure-native declarative deployment, idempotent by design - Terraform: multi-cloud IaC with state file and plan/apply workflow - Azure Artifacts: NuGet, npm, Maven, Python, and Universal Package feeds - Upstream sources proxy public registries inside an internal feed - SemVer versioning prevents breaking downstream consumers silently ### Develop a Security and Compliance Plan 10-15% #### Security Scanning - SAST scans source code statically, before the app ever runs - DAST probes a running application for exploitable weaknesses - SCA (GitHub Dependabot/Advanced Security) flags vulnerable dependencies - Container image scanning checks base images and layers for known CVEs - Shift-left: embed scanning in the PR and build stage, not just pre-release #### Secrets Management - Azure Key Vault centralises secrets, keys, and certificates - Variable groups link to Key Vault so secrets never live in pipeline YAML - Service connections use managed identity or workload identity federation - Secret scanning / push protection blocks committed credentials - Rotate secrets regularly; avoid long-lived static credentials #### Compliance & Governance - Azure Policy / OPA enforce guardrails automatically at deployment time - Pipeline permissions and approvals create a traceable change history - Audit logs capture who approved, deployed, and to which environment - Compliance frameworks (SOC 2, ISO 27001) require reproducible, auditable pipelines - Branch and pipeline protection prevent unreviewed changes reaching production ### Implement an Instrumentation Strategy 5-10% #### Telemetry & Monitoring - Application Insights captures requests, dependencies, exceptions, custom events - Azure Monitor aggregates metrics and logs across resources - Distributed tracing correlates a request across microservices - Synthetic/availability tests validate uptime independent of real traffic - Log Analytics workspaces query telemetry with Kusto Query Language (KQL) #### Feedback Loops - Azure Monitor alerts can gate or roll back a release automatically - Production telemetry feeds directly back into the Azure Boards backlog - A/B testing and feature flag analytics validate feature impact - Dashboards surface DORA metrics: deployment frequency, lead time, MTTR, change failure rate - Continuous improvement closes the loop from production back to planning #### Alerting Strategy - Metric alerts trigger on thresholds (CPU, error rate, latency) - Log alerts trigger on Kusto query results over a time window - Action groups route alerts to email, SMS, webhook, ITSM, or Logic Apps - Smart detection in Application Insights auto-flags anomalies - Alert fatigue is reduced by tuning thresholds and grouping related alerts Section 6 / Method of Loci ## The Memory Palace Walk through themed rooms — each object anchors a concept in spatial memory. ### The Planning Loft Process & Communication — Where delivery starts 🤝 Agile Ceremonies Stand-ups, retros, and sprint planning align delivery cadence across teams 📋 Azure Boards Epics → Features → User Stories → Tasks, tracked on Kanban boards with WIP limits 🔥 SRE Practices Error budgets and blameless postmortems balance velocity against reliability 🔗 Traceability Work items link to commits, PRs, builds, and releases for a full audit trail ### The Source Control Vault Branching Strategy — Where history is managed 🌳 Trunk-Based Development Short-lived branches merged frequently; feature flags hide incomplete work 🔀 GitFlow Long-lived develop/release/hotfix branches for scheduled, versioned releases 🛡️ Branch Policies Required reviewers, linked work items, build validation before merge 👥 CODEOWNERS Auto-assigns reviewers by path; protects critical code from unreviewed change ### The Pipeline Factory Build & Release — Where 50%+ of the exam lives 🏗️ YAML Pipelines Versioned as code; multi-stage build → test → deploy in one file 🎯 Deployment Patterns Blue-green, canary, and ring-based rollouts minimise blast radius 🚦 Release Gates Work item query, Azure Monitor alert, REST API checks before a stage proceeds 🧱 Infrastructure as Code Bicep/ARM (Azure-native) or Terraform (multi-cloud) deployed via pipeline 📦 Azure Artifacts NuGet/npm/Maven/Python feeds with upstream sources and SemVer versioning ### The Security & Signal Room Compliance & Instrumentation — Where risk and feedback close the loop 🔍 SAST / DAST / SCA Static code, dynamic runtime, and dependency composition scanning 🔐 Key Vault Integration Secrets never live in YAML; variable groups link directly to Key Vault 🪪 Managed Identity Workload identity federation replaces stored service connection secrets 📊 Application Insights Telemetry on requests, dependencies, exceptions, and custom events 🔁 Continuous Feedback Production telemetry and Azure Monitor alerts route back into the backlog Section 7 / Pattern Recognition ## Pattern Spotter Decision trees and trigger-answer pairs — see the pattern, know the answer. Which Branching Strategy? Which Branching Strategy?   ├── Small team, frequent releases, mature test automation → Trunk-based development  ├── Scheduled releases with maintained release branches → GitFlow  ├── Microsoft-style, forward-fix-only release cadence → Release flow  └── Need to hide incomplete work behind a toggle → Feature flags + trunk-based development Which Deployment Pattern? Which Deployment Pattern?   ├── Need zero-downtime with instant rollback → Blue-green deployment  ├── Want to validate with a small % of real traffic first → Canary release  ├── Progressive rollout: internal → early adopters → everyone → Ring-based deployment  ├── Need to decouple deploy from release, toggle at runtime → Feature flags  └── Kubernetes-native progressive rollout → Canary deployment strategy in YAML Which IaC Tool? Which IaC Tool?   ├── Azure-only, want native ARM API integration → Bicep  ├── Existing JSON templates, need day-0 ARM compatibility → ARM templates  ├── Multi-cloud or hybrid infrastructure → Terraform  └── Post-provisioning OS/app configuration → Azure Automation / DSC Which Security Scan? Which Security Scan?   ├── Catch vulnerabilities in source before it ever runs → SAST (static analysis)  ├── Test a running app for exploitable weaknesses → DAST (dynamic analysis)  ├── Flag vulnerable open-source dependencies → SCA (GitHub Dependabot / Advanced Security)  └── Check container base images before deploy → Container image scanning ## Decision Cards "zero downtime" or "instant rollback"→Blue-green deployment "small percentage of traffic" or "gradual rollout"→Canary release "internal ring then broad rollout"→Ring-based deployment "decouple deploy from release"→Feature flags "multi-cloud infrastructure as code"→Terraform "Azure-native declarative infrastructure"→Bicep (or ARM templates) "secret hard-coded in pipeline YAML" (what NOT to do)→Link a variable group to Azure Key Vault instead "vulnerable open-source dependency"→Software Composition Analysis (SCA) / Dependabot "approval required before deploying to production"→Release gates / stage approvals "trace a request across microservices"→Distributed tracing (Application Insights) Ready to certify? ## Train with practitioners, not presenters Lucid Labs delivers Microsoft certification training led by Microsoft Certified Trainers (MCTs) and grounded in real-world project experience. We adapt every session to your team's environment, data stack, and business objectives — because the best exam prep comes from engineers who build these solutions every day. 🎯 Tailored Content Training built around your actual Azure DevOps and GitHub toolchain, branching strategy, and deployment targets — not generic slides. 🛠️ Hands-On Labs Build real multi-stage pipelines, IaC deployments, and release gates with expert guidance at every step. 📈 Exam + Capability Pass the Expert-level certification and build lasting CI/CD capability your team can apply from day one. [Talk to us about AZ-400: DevOps Engineer Expert training](https://lucidlabs.com.au/?service=training-consulting&message=I%27m%20interested%20in%20AZ-400%20DevOps%20Engineer%20training%20and%20CI%2FCD%20pipeline%20consulting%20for%20my%20team.#contact) Custom training for teams & individuals — remote or on-site across Australia ![Keith Oak](https://lucidlabs.com.au/team/koak-400.jpg) Keith Oak Chief Technology Officer — Lucid Labs Microsoft Solutions Partner architect specialising in Fabric, Azure Data & AI, and GitHub Enterprise. 18+ years delivering data platforms for Australian businesses — building the systems these exams test every day. [LinkedIn ↗](https://www.linkedin.com/in/keithoak/)[lucidlabs.com.au ↗](https://lucidlabs.com.au/)Published 29-03-2026