Azure DevOps Engineer Expert (AZ-400)

The certifications page compares three vendor-neutral-ish options: AWS's professional DevOps exam, the CNCF's hands-on Kubernetes exam, and HashiCorp's single-tool exam. This page profiles a fourth option that page doesn't cover, because it doesn't fit that comparison at all — Microsoft's AZ-400: Designing and Implementing Microsoft DevOps Solutions, the exam behind the Microsoft Certified: DevOps Engineer Expert title. It's the closest thing the Azure ecosystem has to the AWS DevOps Engineer – Professional, right down to sharing the same knowledge-based, no-terminal exam family — with one structural twist neither AWS nor the CNCF impose: you cannot earn this title from AZ-400 alone.

What AZ-400 is, and the prerequisite gate that makes it unusual

☺ Like you're 10: It's Microsoft's hardest general DevOps exam, and passing it alone isn't enough — you also need one specific earlier badge before this one counts.

AZ-400: Designing and Implementing Microsoft DevOps Solutions sits at the top of Microsoft's role-based ladder — Expert, the tier above Associate and below nothing except Microsoft's narrower Specialty credentials. It certifies the same broad territory the AWS exam does: designing processes, source control, dependency management, build and release pipelines, infrastructure automation, security and compliance, and feedback from production — but expressed entirely in Azure-native tooling: Azure DevOps (Boards, Repos, Pipelines, Artifacts), Azure Resource Manager and Bicep, Azure Key Vault, Azure Monitor. It is knowledge-based, delivered as case studies, multiple-choice, multiple-response, drag-and-drop, and ordered-list questions — never a live terminal or a cluster to fix, which is the single biggest way it differs from the CKA and the closest way it resembles the AWS exam on the comparison page.

The genuinely unusual part is what it takes to actually receive the DevOps Engineer Expert title. Microsoft states plainly that candidates must also hold an active Azure Administrator Associate (AZ-104) or Azure Developer Associate (AZ-204) certification before the Expert badge is issued. Nothing technically stops you from registering for and passing AZ-400 with neither associate cert in hand — the exam itself has no enforced prerequisite check at the registration desk — but Microsoft simply will not award the Expert title until that second box is also checked. Pass AZ-400 first and the associate exam later, or the other way around; the order doesn't matter, but skipping one of them entirely means you've passed a hard exam and have nothing to show for it on your Microsoft Learn profile.

It targets DevOps engineers, release engineers, and platform-minded developers or admins whose delivery pipeline runs on Azure DevOps or on GitHub with Azure as the deployment target — people who already touch Azure infrastructure or Azure application code daily, since one of those two associate exams is meant to already be behind them. If your shop is Azure-committed the way an AWS DevOps Engineer – Professional candidate is AWS-committed, this is the exam that certifies the equivalent breadth.

The format, in full

☺ Like you're 10: A screen full of scenarios and questions, no terminal anywhere — but some of those scenarios are pages long, and once you move past one you can't come back to it.

Every figure below is what Microsoft generally publishes for its role-based exams and what candidates consistently report for AZ-400 specifically. Treat it as a solid planning baseline rather than a locked contract — Microsoft revises skill outlines multiple times a year without changing the exam code, which is the single biggest logistics difference from AWS or the CNCF, covered in the warning box below.

That renewal model is worth pausing on, because it's the second structural way this exam differs from everything else on this course's certification shelf. The CKA and the AWS exam both require you to sit a full paid exam again every two or three years to stay current. AZ-400 instead expires after one year but renews for free through a short open-book assessment on Microsoft Learn — no proctor, no fee, no travel — which changes the real long-term cost of holding the credential considerably, even though the up-front exam is comparable in price to the others.

↗ Microsoft official AZ-400 page

The skill domains, and where the exam actually concentrates

☺ Like you're 10: Five topics, and — like the AWS exam and unlike the CKA — building and shipping the pipeline itself is worth nearly half the entire test.

Microsoft's published skills outline for AZ-400 has held a consistent shape across most of the exam's revisions, even as exact wording and percentage bands shift: five domains, with build-and-release pipeline work dominating by a wide margin. The weights below are the ranges that have recurred across multiple published revisions of the outline — treat them as directional, and re-check the current PDF for the live numbers, per the warning above.

The shape is unmistakable even accounting for the fuzziness of the ranges: build, integration & delivery is worth roughly as much as the other four domains combined. That single domain is where source control's output becomes a running deployment — Azure Pipelines authoring, agent pools, environments and approvals, deployment strategies, and dependency management via Azure Artifacts all live inside it. The content brief for this page names four areas specifically: source control, dependency management, build/release pipelines, and infrastructure and configuration — the first three map directly onto the domains above, and infrastructure/configuration is folded into the build-and-release domain rather than standing alone, since on Azure, deploying infrastructure and deploying application code both run through the same Pipelines mechanism.

What you actually need to know, domain by domain

☺ Like you're 10: Here's the real substance behind each label — the actual screens, YAML, and Azure services your hands need to recognize.

Source control strategy

The exam expects fluency in more than one branching model and the judgment to pick between them: trunk-based development (short-lived feature branches, heavy use of feature flags to hide incomplete work, frequent merges to main), classic GitFlow (long-lived develop and release branches, explicit hotfix branches), and Release Flow — the branching strategy Microsoft's own Azure DevOps engineering team uses internally and has publicly documented, worth recognizing by name since it shows up in Microsoft's own exam material. In Azure Repos specifically, branch policies are the enforcement mechanism: minimum reviewer counts, required linked work items, build-validation policies that block a merge until a specified pipeline passes, and required comment resolution. One scenario that shows up nowhere else on this course's certification shelf: migrating a team off Team Foundation Version Control (TFVC), Microsoft's older centralized source control, onto Git — a real, still-current migration problem for organizations with a long Microsoft history.

Dependency management

Azure Artifacts is the domain's center of gravity: private package feeds for NuGet, npm, Maven, Python, and universal packages, each feed configurable with an upstream source that proxies and caches the corresponding public registry (nuget.org, npmjs.com) so a single feed serves both your team's own packages and cached copies of public ones. Feed views (commonly named @Local, @Prerelease, @Release) let a package get promoted through quality gates without ever being re-uploaded — the same immutable artifact, just a new view membership. The exam also expects awareness of Component Governance, Azure DevOps' built-in scanning for open-source license and known-vulnerability issues in whatever a build pulls in, which is the same instinct this course covers in full at supply-chain security & SBOM.

Build, integration & delivery — the pipeline itself

Azure Pipelines is authored in YAML today (the older drag-and-drop classic editor still exists but the exam assumes YAML fluency), structured as stages → jobs → steps. Each job runs on an agent pool — Microsoft-hosted images (ubuntu-latest, windows-latest, macOS-latest) for most workloads, or self-hosted agents when a deployment target sits behind a private network the hosted pool can't reach. Parallel jobs are a real capacity constraint worth knowing cold: a free Azure DevOps organization historically ships with one Microsoft-hosted parallel job, which serializes every pipeline in the org until more are purchased or granted.

trigger:
  branches:
    include: [ main ]

stages:
- stage: Build
  jobs:
  - job: BuildAndPublish
    pool: { vmImage: 'ubuntu-latest' }
    steps:
    - task: DotNetCoreCLI@2
      inputs: { command: 'restore', feedsToUse: 'select', vstsFeed: 'contoso/app-feed' }
    - task: DotNetCoreCLI@2
      inputs: { command: 'build' }
    - publish: $(Build.ArtifactStagingDirectory)
      artifact: drop

- stage: DeployProd
  dependsOn: Build
  jobs:
  - deployment: DeployWeb
    environment: 'production'   # approvals & checks live on the Environment, not the stage
    pool: { vmImage: 'ubuntu-latest' }
    strategy:
      runOnce:
        deploy:
          steps:
          - download: current
            artifact: drop
          - task: AzureWebApp@1
            inputs:
              azureSubscription: 'prod-service-connection'
              appName: 'contoso-web'
              package: '$(Pipeline.Workspace)/drop/**/*.zip'

The detail that trips people up: approvals and checks are configured on the Environment resource itself ("production" above), not written inline in the YAML — a pre-deployment approval, a business-hours check, or a gate that queries an Azure Monitor alert state all attach there, which is exactly why the same YAML can be safely reused across Dev, Test, and Prod environments with very different gating per environment. On deployment strategy specifically: Azure App Service's deployment slots give you blue-green (swap a warmed-up staging slot into production, instantly reversible) essentially for free; a true rolling or canary strategy against VM-based targets needs deployment groups, and canary against Kubernetes targets needs additional tooling like Argo Rollouts on top of AKS — Azure Pipelines itself doesn't natively traffic-split the way some platforms do. Compare this directly against the generic version of the same trade-offs in deployment strategies.

Infrastructure and configuration, via Azure-native tooling

The content brief calls this out specifically, and on Azure it's folded into the delivery domain rather than standing alone, because infrastructure deploys through the same pipeline as application code. Bicep is Microsoft's own domain-specific language for Azure infrastructure — cleaner syntax than raw ARM JSON templates, and it transpiles directly to ARM via az bicep build, so anything Bicep expresses, ARM ultimately executes. The exam expects familiarity with both directions of that relationship, plus what-if deployments (a dry-run diff against live Azure state, conceptually the same drift-preview idea as terraform plan, covered vendor-neutral in infrastructure as code).

param location string = resourceGroup().location
param appName string

resource plan 'Microsoft.Web/serverfarms@2023-01-01' = {
  name: '${appName}-plan'
  location: location
  sku: { name: 'B1', tier: 'Basic' }
}

resource site 'Microsoft.Web/sites@2023-01-01' = {
  name: appName
  location: location
  properties: { serverFarmId: plan.id }
}

Governance layers on top of that: Azure Policy enforces rules at deployment time with deny, audit, or deployIfNotExists effects — genuinely compliance-as-code, the same idea this course covers vendor-neutral in compliance as code & policy enforcement. For configuration drift on running VMs rather than at deployment time, the exam expects awareness of the Desired State Configuration (DSC) extension and Azure Automation State Configuration — the reconciliation-loop idea this course covers generally in configuration management. Terraform's azurerm provider is a legitimate alternative path for the same infrastructure work and this course already has a full Terraform page and a Terraform Associate certification profile — but AZ-400 itself is scoped to Azure-native tooling specifically, not multi-cloud IaC choice, so don't expect Terraform questions on this exam even though it's a perfectly valid tool for the same job in a real Azure shop.

Security and compliance

Secrets belong in Azure Key Vault, referenced into a pipeline through a Key-Vault-linked variable group rather than pasted as plain pipeline variables — the same non-negotiable this course argues generally in secrets & credential management. The current best practice for the service connection a pipeline uses to authenticate to Azure is workload identity federation: a short-lived, OIDC-based token exchange instead of a long-lived service-principal client secret sitting in the pipeline's configuration waiting to be rotated or leaked — worth naming specifically since it's a genuinely recent, exam-relevant shift away from the older secret-based service connection. On the scanning side, Microsoft Defender for DevOps and GitHub Advanced Security integrations bring secret scanning, dependency (software composition) scanning, and code scanning directly into pull-request checks — the shift-left instinct covered generally in shift-left security for DevOps.

Instrumentation strategy

The feedback-loop domain, closing the plan-build-release-operate cycle: Application Insights auto-instruments an app for distributed tracing and dependency maps, feeding into Azure Monitor and Log Analytics workspaces queried with KQL. The exam-specific twist worth remembering: an Azure Monitor alert rule can trigger an action group that automatically creates a work item in Azure Boards, closing the loop from "something broke in production" straight back into the same backlog the team already plans from — a concrete implementation of the general idea in monitoring & observability and distributed tracing & telemetry.

How directly this parallels the AWS DOP-C02

☺ Like you're 10: Same seniority, same "no terminal, just scenarios" shape, same breadth of the job — just a different cloud's toolbox, a cheaper ticket, and one extra badge you need first.

For a reader already committed to Azure, AZ-400 is not an alternative to the AWS exam covered on the certifications page — it's the direct parallel, testing the same seniority and the same end-to-end scope through a different vendor's tools. Both are knowledge-based with no live terminal or cluster, both sit at the top of their vendor's general-purpose ladder, and both cover source control, build/release automation, infrastructure automation, security, and feedback from production as named domains rather than an afterthought. The honest differences are structural, not conceptual.

The practical takeaway for someone deciding between the two: don't. They're not really competing for the same slot on a résumé the way, say, the CKA and Terraform Associate partly do. Pick based on which cloud your delivery pipeline actually runs on — and if the honest answer is "both, meaningfully," there's a real case for eventually holding both credentials rather than treating one as a substitute for the other, since the underlying platform knowledge genuinely doesn't transfer (Azure Key Vault and AWS Secrets Manager rhyme conceptually, but the exam questions about them do not).

How to prepare using this site

☺ Like you're 10: Most of the concepts are already here in a cloud-neutral form — the gap is purely the Azure-specific screens and YAML, which no page on this site teaches directly.

This course teaches the DevOps discipline vendor-neutral, so the conceptual half of every AZ-400 domain is already covered — what's missing is exclusively the Azure-native tooling: Azure Repos' specific branch-policy UI, Azure Pipelines' exact YAML schema, Bicep's syntax, and Azure Key Vault's integration mechanics. None of that is a gap in the underlying skill, only in the vendor-specific surface.

Who should take it, and who should look elsewhere

☺ Like you're 10: Take it if Azure is genuinely your day job and you're willing to earn two badges, not one. Skip it if either of those isn't true yet.

Take it if: your organization's delivery pipeline runs on Azure DevOps or GitHub-with-Azure-as-target day to day; you already hold, or are actively working toward, AZ-104 or AZ-204; and you want a credential that signals the same cross-SDLC ownership the AWS exam signals for an AWS shop — process design through production feedback, not just one tool in the middle of it.

Look elsewhere, or sequence carefully, if: you haven't started on AZ-104 or AZ-204 yet — budget for two exams, not one, and decide up front whether to sit the associate exam first (the safer order) or race AZ-400 in parallel knowing the title won't post until both clear; your organization is multi-cloud or AWS/GCP-primary, in which case the AWS DOP-C02 profiled on the comparison page or the Google Cloud Professional DevOps Engineer is the better-matched vendor exam; or you specifically want a credential that proves hands-on execution under a clock rather than scenario judgment, which is exactly what the performance-based CKA tests and this exam does not.