How to Pass Microsoft Azure DevOps Solutions (AZ-400) in 2026: Complete Study Guide

# How to Pass Microsoft Azure DevOps Solutions (AZ-400) in 2026: Complete Study Guide The AZ-400 Designing and Implementing Microsoft DevOps Solutions exam is the gateway to the DevOps Engineer Expert certification. Unlike most Azure exams, it covers a broad horizontal slice of the DevOps lifecycle — from source control and CI/CD pipelines to security scanning and observability. This guide provides everything you need to pass in 2026. --- ## Exam Format and Prerequisites | Detail | Value | |---|---| | Exam code | AZ-400 | | Cost | $165 USD | | Number of questions | 40–60 questions | | Time limit | 120 minutes | | Level | Expert | | Passing score | 700 / 1000 | | Prerequisite | AZ-104 (Azure Administrator) OR AZ-204 (Azure Developer) | **This is an Expert-level exam.** Microsoft strongly recommends completing AZ-104 or AZ-204 first. The exam assumes you already understand Azure fundamentals, resource management, and either infrastructure or application development. AZ-400 itself does not grant a certification — you earn the **DevOps Engineer Expert** badge by pairing it with either AZ-104 or AZ-204. --- ## Exam Domain Breakdown | Domain | Weight | Question Estimate (~50q) | |---|---|---| | Configure processes and communications | 10–15% | ~6 questions | | Design and implement source control | 15–20% | ~9 questions | | Design and implement build and release pipelines | 40–45% | ~21 questions | | Develop a security and compliance plan | 10–15% | ~6 questions | | Implement an instrumentation strategy | 10–15% | ~6 questions | The pipelines domain alone accounts for nearly half the exam. If you have limited study time, prioritize YAML pipeline syntax, deployment strategies, and environment approvals above everything else. --- ## Domain 1: Processes and Communications This domain covers agile project management in Azure DevOps Boards and integrations with development tools. **Azure DevOps Boards:** - Work item types: Epic → Feature → User Story → Task (or Bug) - Process templates: Agile, Scrum, CMMI (choose at project creation, cannot change later) - Backlogs, sprint planning, Kanban boards, and velocity charts **GitHub vs Azure DevOps:** - Use GitHub when the project is open source, the team already uses GitHub, or you want GitHub Actions - Use Azure DevOps when the organization requires Azure integration, advanced release gates, or the project is enterprise-internal - Both can be used together: GitHub Repos + Azure Pipelines is a common hybrid pattern --- ## Domain 2: Source Control **Git branching strategies:** | Strategy | Description | Best for | |---|---|---| | Trunk-based development | All developers commit to `main` (or short-lived feature branches < 1 day) | High-frequency deployment, feature flags | | GitHub Flow | Feature branches + PRs to `main`, deploy immediately after merge | Web apps with continuous deployment | | GitFlow | `main`, `develop`, `release/`, `hotfix/` branches | Versioned products, scheduled releases | | Release Flow (Microsoft) | Feature branches from `main`, topic branches for large features | Large teams with multiple release trains | **Pull request policies (Azure Repos):** - Required reviewers (minimum approver count) - Linked work items required - Comment resolution required - Build validation (run a pipeline before merge) - Branch policies prevent direct pushes to protected branches **CODEOWNERS (GitHub):** - A `CODEOWNERS` file maps file patterns to required reviewers - When a PR changes a file matching a pattern, the owner is automatically added as a required reviewer - Azure DevOps equivalent: required reviewers policy (manual configuration) --- ## Domain 3: Build and Release Pipelines (40–45%) This is the core of the AZ-400 exam. Master these concepts. **YAML Pipeline Anatomy:** ```yaml trigger: branches: include: [main] variables: buildConfiguration: Release stages: - stage: Build jobs: - job: BuildApp pool: vmImage: ubuntu-latest steps: - task: DotNetCoreCLI@2 inputs: command: build arguments: '--configuration $(buildConfiguration)' ``` Key elements: `trigger`, `pr`, `schedules`, `variables`, `stages`, `jobs`, `steps`, `pool`, `environment`. **Deployment Strategies:** | Strategy | Description | Rollback | Risk | |---|---|---|---| | Blue-Green | Two identical environments; switch traffic instantly | Instant (switch back) | Low — old version always available | | Canary | Route small % of traffic to new version; increase gradually | Remove canary instances | Low — limited blast radius | | Rolling | Replace instances incrementally in batches | Complex | Medium — mixed versions during rollout | | Recreate | Stop all instances, deploy new version, start | N/A | High — downtime | **Feature Flags:** - Azure App Configuration stores feature flag definitions - Applications query App Configuration at runtime to enable/disable features - Decouples deployment from release — code is deployed but feature is off until the flag is toggled **Environments and Approvals:** - Environments represent deployment targets (e.g., staging, production) - Approvals: a human reviewer must approve before a stage deploys to the environment - Checks: automated gates (REST API call, Azure Monitor alert query, business hours) - Exclusive lock: prevents concurrent deployments to the same environment > **💡 Exam Tip:** Approvals are configured on the **environment**, not on the pipeline. A pipeline job that targets an environment inherits all the environment's approval and check requirements. **Agent Types:** | Agent | Pros | Cons | |---|---|---| | Microsoft-hosted (ubuntu-latest, windows-latest) | No maintenance, always updated | No persistence, limited network access | | Self-hosted (agent pool) | Full network access, custom software | You manage updates and scaling | | Scale set agents | Auto-scale self-hosted on Azure VMSS | More complex setup | --- ## Domain 4: Security and Compliance **Defender for DevOps:** - Connector available for Azure DevOps and GitHub - Surfaces security findings directly in the Azure portal - Findings include: secret scanning, code scanning (SAST), infrastructure-as-code scanning, dependency vulnerabilities - Results appear in Microsoft Defender for Cloud as recommendations **Security scanning types:** | Type | What it scans | Tool examples | |---|---|---| | SAST (Static Application Security Testing) | Source code for vulnerabilities without running the app | GitHub CodeQL, SonarQube, Checkmarx | | DAST (Dynamic Application Security Testing) | Running application from the outside | OWASP ZAP, Burp Suite | | SCA (Software Composition Analysis) | Open source dependency vulnerabilities | Dependabot, Mend (WhiteSource), Snyk | | Container scanning | Container image layers for CVEs | Trivy, Microsoft Defender for Containers | | IaC scanning | ARM, Bicep, Terraform for misconfigurations | Checkov, tfsec, Defender for DevOps | **Secret scanning alerts:** - GitHub: secret scanning detects tokens, keys, and credentials committed to repos - Push protection: blocks pushes that contain detected secrets before they are committed - Azure DevOps: credential scanner task available for pipelines > **💡 Exam Tip:** The exam distinguishes between SAST (static, finds code vulnerabilities) and DAST (dynamic, runs against a live application). If the question says "before the app is deployed," the answer involves SAST or SCA, not DAST. --- ## Domain 5: Instrumentation Strategy **Application Insights:** - Application Performance Management (APM) service for web applications - Collects: requests, dependencies, exceptions, page views, custom events, custom metrics - Distributed tracing: traces are correlated by `operation_id` across microservices - Sampling: reduces data ingestion cost — adaptive sampling (default, reduces volume automatically) vs fixed rate sampling **Log Analytics Workspace:** - Central repository for logs from all Azure services - Kusto Query Language (KQL) for querying - Application Insights can be workspace-based (logs go to Log Analytics) **Alert types:** | Alert type | Trigger | Latency | Use case | |---|---|---|---| | Metric alert | Metric threshold (real-time) | Near real-time | CPU > 90%, error rate spike | | Log query alert | KQL query on log data | Minutes (scheduled) | Complex multi-condition logic | | Activity log alert | Azure resource events | Near real-time | Resource deletion, policy violations | **Deployment slot swap (Azure App Service):** - Swap staging slot to production slot (URL swap, zero downtime) - Traffic routing: send a percentage of traffic to a slot for gradual validation - Auto-swap: automatically swaps after a successful deployment to the staging slot --- ## 6-Week Study Plan | Week | Focus | Activities | |---|---|---| | 1 | Boards and Source Control | Review GitFlow vs trunk-based, PR policies, CODEOWNERS. Set up a GitHub repo with branch protection. | | 2 | YAML Pipeline Basics | Write trigger/variable/stage/job/step YAML from scratch. Run a pipeline in Azure DevOps or GitHub Actions. | | 3 | Advanced Pipelines | Templates (stage/job/step/variable), environments, approvals, deployment jobs (rolling/canary). | | 4 | Security and Artifacts | Defender for DevOps setup, secret scanning, Azure Artifacts feeds, upstream sources. | | 5 | Monitoring | Application Insights SDK integration, distributed tracing, metric vs log query alerts, App Configuration feature flags. | | 6 | Practice and Review | Full practice exams. Review deployment strategy trade-offs. Re-read pipeline YAML template documentation. | --- ## Key Resources - **Microsoft Learn**: AZ-400 learning path (free, official) - **Azure Pipelines documentation**: YAML schema reference - **GitHub Actions documentation**: Comparing GitHub Actions vs Azure Pipelines - **CertLand practice exams**: 340 AZ-400 scenario questions --- ## Final Exam Tips 1. The pipelines domain is 40-45% of the exam — know YAML syntax deeply 2. Understand deployment strategy trade-offs (blue-green = fastest rollback, canary = lowest blast radius) 3. Know when to use Azure DevOps vs GitHub Actions (hint: GitHub is preferred for open source) 4. Approvals are on environments, not pipelines 5. Feature flags decouple deployment from release — this is a core DevOps philosophy question Ready to practice? **[Start AZ-400 Practice Exam on CertLand →](https://certland.net/exam/designing-and-implementing-microsoft-devops-solutions-az-400-340-questions)**