Microsoft Azure DevOps Engineer Expert (AZ-400)

This is the certification people mean by “the Azure DevOps cert” — and almost everyone gets its name wrong, including the title above. Microsoft calls it Microsoft Certified: DevOps Engineer Expert, with no “Azure” in it, earned by passing one exam: AZ-400: Designing and Implementing Microsoft DevOps Solutions. The syllabus is broad and genuinely useful — pipelines, source control strategy, infrastructure as code, secrets and telemetry under one roof. It is also expert-tier: you must already hold an Azure associate certification, then renew every year or lose it. Below, the verified facts, the official domain weights, and a straight answer on when to skip it.

What this credential is and where it sits

☺ Like you’re 10: It is Microsoft’s top-level badge for “the person who builds the pipeline.” One exam — but you need a smaller badge first.

The issuer is Microsoft, through the Microsoft Learn credentials programme; the exam is delivered by Pearson VUE, test centre or online-proctored. It sits at the top of Microsoft’s three-tier role-based ladder — Fundamentals, Associate, Expert — and is the delivery-and-automation Expert credential.

The name changed — and so did the exam title

Two naming facts save you from buying the wrong study guide. First, the certification is officially “Microsoft Certified: DevOps Engineer Expert” — the word “Azure” is not in it. Second, the exam is officially “AZ-400: Designing and Implementing Microsoft DevOps Solutions”; older books and job ads call it “Microsoft Azure DevOps Solutions.” Microsoft publishes only the current names, not a dated history of the renames or a rationale for them, so treat any specific date you read for either change — including in this paragraph’s absence of one — as third-party folklore. What is verifiable is that the exam code never changed, which is why everyone still says AZ-400, and that the current objectives give GitHub billing alongside Azure DevOps throughout.

Two product families, one exam

The word “Microsoft” in the title is doing real work. AZ-400 tests two product families side by side: Azure DevOps (Pipelines, Repos, Boards, Artifacts) and GitHub (Actions, Packages, Issues, Projects, Advanced Security, Dependabot). The audience profile is explicit — you “should also have experience implementing both GitHub and Azure DevOps solutions.” Know only one and half an exam of study awaits; it is usually the Azure DevOps half that catches GitHub-native engineers out.

Why a platform engineer might take it — and when to skip it

☺ Like you’re 10: Worth it if your job really is on Azure. If it isn’t, it’s like getting expert at one shop’s self-checkout machine.

Let us be blunt, because a page that recommends every certification is worth nothing. AZ-400 is vendor-locked knowledge. Much of what you memorise — service connections, variable groups, Artifacts feed views, deployment slots, agent pools — evaporates the day you move to a GitLab shop, or AWS. That is not a criticism; it is what a vendor certification is. Price the effort accordingly.

☺ Like you’re 10: If two people offer you a badge and only one of them is your boss, take the one your boss cares about.

One overlap worth naming: if you hold GitHub certifications, much of the pipelines and security content is revision — GitHub is a Microsoft property, and its exams now sit on Microsoft Learn and Pearson VUE alongside AZ-400 itself — making AZ-400 cheaper for you, not redundant. The reverse trap is nastier: CKA holders sometimes assume AZ-400 teaches cloud-native delivery. It teaches Microsoft’s delivery products. Progressive delivery in the Argo Rollouts / Flagger sense is absent — blue-green, canary and ring appear as design strategies and vendor features, not CNCF controllers.

What it actually tests — the official domains

☺ Like you’re 10: Five topics. One of them is half the whole exam. Study that one hardest.

These five skill areas and weights are transcribed from the official AZ-400 study guide and exam details page, as of writing. Microsoft does publish weights, so there is no guesswork here — but confirm them yourself before booking, because Microsoft says it reviews its cloud exams quarterly. One reassurance: the study guide currently heads its objective list “Skills measured as of July 27, 2026” — the date the English exam updates — and its own change log marks every one of the five skill areas “No change,” so the table below holds on both sides of that update.

Notice the shape. The third area alone is 50–55% — the weights are published as ranges that resolve to 100%, so that one area is worth at least as much as the other four put together — and “design and implement infrastructure as code” is a first-class sub-objective inside it. That is why this exam belongs on a platform-engineering site at all. Spend limited time on YAML pipelines, deployment strategies and IaC. And so you do not over-study: there is no Kubernetes-internals depth, no CNCF tooling by name, no GitOps reconciliation in the Argo CD / Flux sense, and no service mesh.

The substance you need to know

☺ Like you’re 10: Four things — write the pipeline in YAML, describe the infrastructure in a file, never type a password, and watch the logs.

Multi-stage YAML pipelines, environments and approvals

The highest-value artefact to be fluent in is a multi-stage azure-pipelines.yml. The exam cares that you know environments are where checks and approvals live (not the YAML), that deployment jobs differ from ordinary jobs, and that templates and variable groups prevent copy-paste across teams.

trigger:
  branches: { include: [ main ] }

variables:
  - group: platform-shared          # variable group, backed by Key Vault

stages:
- stage: Build
  jobs:
  - job: buildAndPush
    pool: { vmImage: ubuntu-latest }
    steps:
    - task: Docker@2
      inputs:
        containerRegistry: acr-service-connection   # a service connection, not a password
        repository: checkout
        command: buildAndPush
        tags: $(Build.BuildId)

- stage: DeployProd
  dependsOn: Build
  jobs:
  - deployment: rollout            # a *deployment* job, so it targets an environment
    environment: prod-aks          # approvals & checks are configured ON the environment
    strategy:
      runOnce:
        deploy:
          steps:
          - task: KubernetesManifest@1
            inputs:
              action: deploy
              kubernetesServiceConnection: aks-prod
              manifests: manifests/deployment.yaml

The GitHub Actions half asks the same questions in a different dialect: environment: with required reviewers, reusable workflows instead of YAML templates, GITHUB_TOKEN permissions instead of service connections. Knowing which concept maps to which product is a favourite question shape — and it all sits on top of CI/CD & Progressive Delivery.

Secretless authentication and Key Vault

This is the modern answer to “how does my pipeline get into Azure,” and it is worth learning even if you never sit AZ-400. Workload identity federation (OIDC) lets a workflow exchange a short-lived, workload-scoped token for an Azure token — nothing stored, nothing to rotate, nothing to leak.

permissions:
  id-token: write        # required to mint the OIDC token
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: azure/login@v2          # NO client secret — federated credential only
        with:
          client-id:       ${{ secrets.AZURE_CLIENT_ID }}
          tenant-id:       ${{ secrets.AZURE_TENANT_ID }}
          subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

      - name: Pull a secret at deploy time
        run: |
          DB=$(az keyvault secret show --vault-name kv-platform-prod \
                 --name checkout-db-password --query value -o tsv)
          echo "::add-mask::$DB"      # never let it land in the log

The exam likes contrasting failure modes: a long-lived client secret in a variable group (rotatable, leakable) versus a managed identity or federated credential (nothing to store). Contrast both with the Kubernetes-native route — External Secrets Operator pulling Key Vault into the cluster — in Secrets Management.

Infrastructure as code on Azure

Objective 3 explicitly names Azure Resource Manager, Bicep, Azure Machine Configuration and Azure Automation State Configuration. Bicep is the one to actually learn — the readable, transpiled-to-ARM language modern Azure shops write.

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

resource aks 'Microsoft.ContainerService/managedClusters@2025-10-01' = {
  name: clusterName
  location: location
  identity: { type: 'SystemAssigned' }        // managed identity, no secrets
  properties: {
    dnsPrefix: clusterName
    agentPoolProfiles: [ {
      name: 'system'
      count: 3
      vmSize: 'Standard_D4s_v5'
      mode: 'System'
    } ]
    oidcIssuerProfile: { enabled: true }      // OIDC issuer: the prerequisite...
    securityProfile: {
      workloadIdentity: { enabled: true }     // ...and the add-on that actually
    }                                         //    turns on workload identity
  }
}

# what-if is the exam's favourite ARM/Bicep verb: preview the diff before you commit.
az deployment group what-if \
  --resource-group rg-platform-prod \
  --template-file infra/aks.bicep \
  --parameters clusterName=aks-prod

az deployment group create \
  --resource-group rg-platform-prod \
  --template-file infra/aks.bicep \
  --parameters clusterName=aks-prod

Telemetry and KQL

Domain 5 is small but very answerable, and the neglected part is Kusto Query Language. You do not need fluency; you need to read a query and pick the right one from four options.

// Failed requests for one service in the last hour, bucketed by 5 minutes
requests
| where timestamp > ago(1h)
| where cloud_RoleName == "checkout"
| where success == false
| summarize failures = count() by bin(timestamp, 5m), resultCode
| order by timestamp desc

If domain 1’s metrics feel familiar, they should — cycle time, lead time and time to recovery are three of the four DORA metrics, exactly the numbers Observability and Release Engineering teach you to build a platform around. Microsoft is asking you to instrument the delivery system, not just the app.

How it maps onto this site

☺ Like you’re 10: Every AZ-400 topic already has a page here explaining the idea. Read the idea first, then learn Microsoft’s button for it.

This is the most useful thing on the page. Concepts transfer between clouds; buttons do not.

Exam logistics

☺ Like you’re 10: One exam, one smaller badge needed first, and a short quiz every year forever.

Every row below comes from the official AZ-400 exam page, the official certification page or Microsoft’s published exam-policy pages, as of writing. Confirm each one yourself before you book.

The renewal treadmill is the real cost

This is what people underestimate. You will carry two Microsoft certifications, not one — AZ-400 and the AZ-104 or AZ-204 prerequisite — and Microsoft’s FAQ is explicit that “each certification must be renewed separately by passing the associated renewal assessment.” Two assessments a year, on two anniversary dates, forever. They are free and short, so the cost is not money; it is attention, precisely the resource that fails silently. One quirk from the same FAQ: if your associate prerequisite expires, your Expert certification does not automatically expire with it — you can hold a valid DevOps Engineer Expert on top of a lapsed AZ-104.

☺ Like you’re 10: Put both renewal dates in your calendar the day you pass. Free is only free if you remember.

Verdict — where it fits in a realistic order

☺ Like you’re 10: Build the ladder in the order that pays you back soonest.

AZ-400 is a good exam — broad, current, and unusually honest about testing design judgement rather than trivia. It is also, unavoidably, a badge that says “I am productive inside Microsoft’s tooling.” That is worth a lot to a Microsoft shop and comparatively little to anyone else, so the verdict is entirely conditional on where you work.

If your platform runs on Azure: take it, in this order — AZ-104 or AZ-204 first (mandatory anyway; AZ-104 if you lean infrastructure, AZ-204 if you lean application code), then AZ-400. Slot CKA in alongside if AKS is central, because AZ-400 will not teach you Kubernetes. Realistic effort: two exams, three to six months at a working pace.

If it does not: skip it, without guilt. Put the hours into the vendor-neutral core — CNPA for platform concepts, CKA for the substrate, Terraform Associate for IaC — plus the certification matching the cloud you are actually on. Come back the week you join a Microsoft shop, not before. The certifications hub lays out the full ladder; the exam guide covers study technique that transfers across all of them.

The transferable half of AZ-400 is not the product names — it is the shape: a versioned source of truth, a gated pipeline, declarative infrastructure, no stored secrets, telemetry on the delivery system itself. Learn that shape here, and every vendor’s exam becomes a vocabulary test.