Home / devops-containers / Designing and Implementing Microsoft DevOps Solutions (AZ-400) / Cheat Sheet
Designing and Implementing Microsoft DevOps Solutions (AZ-400)

AZ-400 Cheat Sheet

AZ-400 Tests Pipeline Design Across Azure DevOps and GitHub — Not Tool Trivia

An expert-level exam for engineers who build delivery systems. Build and release pipelines alone are 50–55%, so YAML structure, agents, environments, deployment patterns and IaC decide the result.

Check Your Readiness →
Among the harder certs
Avg: Not published by Microsoft
Pass: 750 / 1000
Most candidates understand Designing and Implementing Microsoft DevOps Solutions (AZ-400) concepts — and still fail. This exam tests how you apply knowledge under pressure.

AZ-400 Domain Map (skills measured as of July 27, 2026)

Scenarios mix Azure DevOps and GitHub, and the right answer is usually the built-in feature with least effort and least privilege rather than a custom script. Half the exam is YAML, agents, environments, feeds and deployment strategies. 100 minutes; question count not published.

  1. 01
    Processes and communications (10–15%) — AB# traceability, DORA and flow metrics, dashboards, wikis, Teams integration
  2. 02
    Source control strategy (10–15%) — branching models, branch policies and protection, Git LFS, Scalar, history rewrites
  3. 03
    Build and release pipelines (50–55%) — packages and feeds, testing, YAML pipelines, deployment patterns, IaC, maintenance
  4. 04
    Security and compliance plan (10–15%) — workload identity federation, service connections, secrets, code and dependency scanning
  5. 05
    Instrumentation strategy (5–10%) — Application Insights, VM and Container Insights, KQL queries, alerts

Wrong instinct vs correct approach

A bot must update files across many repositories in a GitHub organization
✕ Wrong instinct

Create a PAT on an administrator account for the bot

✓ Correct approach

A PAT is tied to a person and usually broader than needed. A GitHub App installs on the organization with fine-grained permissions and short-lived tokens. For same-repository tasks, GITHUB_TOKEN limited by the permissions key is enough.

A tested package must reach release consumers without being rebuilt or republished
✕ Wrong instinct

Create separate dev, test and prod feeds and republish

✓ Correct approach

Use feed views: promote the same package version from @local to @prerelease to @release. Consumers point at the view and the binary never changes, preserving traceability. Upstream sources separately cache public registry packages on first use.

Rollback of a web app must take seconds after a bad release
✕ Wrong instinct

Use a rolling deployment across the instances

✓ Correct approach

Rolling rollback redeploys batch by batch. App Service deployment slots or blue-green let you swap back instantly; warm the staging slot before swapping and mark environment-specific settings slot-sticky so they stay put.

Clones of a huge monorepo with thousands of folders are slow
✕ Wrong instinct

Move the repository's files into Git LFS

✓ Correct approach

Git LFS solves large binary files, not repository breadth or history size. Scalar enables partial clone, sparse checkout and background maintenance for very large repositories, so developers fetch and check out only what they need.

Pages are slow, but App Service CPU and memory look normal
✕ Wrong instinct

Scale up the App Service plan

✓ Correct approach

Healthy resource metrics point to a slow dependency. Use Application Insights end-to-end transaction details and the application map to find the slow call; instrument with the Azure Monitor OpenTelemetry Distro if telemetry is missing.

Know these cold

  • ▸ Link commits to Azure Boards with AB#ID; plain #ID targets GitHub issues
  • ▸ Without dependsOn, jobs run in parallel; YAML file order never sets execution order
  • ▸ Task groups are classic only; YAML shares logic through step, job, stage or extends templates
  • ▸ Variable groups can link Key Vault secrets, which stay masked in pipeline logs
  • ▸ A breaking API change means a major bump under MAJOR.MINOR.PATCH semantic versioning
  • ▸ Squash merge collapses a pull request to one commit; rebase or basic merge keeps them all
  • ▸ Tag releases with annotated tags, which record tagger, date and message
  • ▸ Parallel jobs fix queues; one slow run needs caching, job splitting or faster agents
  • ▸ Stakeholder access is free for work items; outside collaborators see specific repositories only
  • ▸ Bicep provisions Azure resources; in-guest OS settings need Azure Machine Configuration

Can you answer these without checking your notes?

In this scenario: "A bot must update files across many repositories in a GitHub organization" — what should you do first?
A PAT is tied to a person and usually broader than needed. A GitHub App installs on the organization with fine-grained permissions and short-lived tokens. For same-repository tasks, GITHUB_TOKEN limited by the permissions key is enough.
In this scenario: "A tested package must reach release consumers without being rebuilt or republished" — what should you do first?
Use feed views: promote the same package version from @local to @prerelease to @release. Consumers point at the view and the binary never changes, preserving traceability. Upstream sources separately cache public registry packages on first use.
In this scenario: "Rollback of a web app must take seconds after a bad release" — what should you do first?
Rolling rollback redeploys batch by batch. App Service deployment slots or blue-green let you swap back instantly; warm the staging slot before swapping and mark environment-specific settings slot-sticky so they stay put.

Common Exam Mistakes — What candidates get wrong

Putting production approvals in the YAML file

Approvals and checks live on the environment, service connection or other protected resource, outside YAML, so editing the pipeline cannot bypass them. In GitHub Actions the equivalent is environment protection rules with required reviewers and environment secrets.

Using Microsoft-hosted agents to reach private endpoints

Hosted agents run outside your network and cannot reach resources with public access disabled. Use a self-hosted agent or runner inside the VNet, or Managed DevOps Pools for Azure Pipelines. A managed identity also needs code running on your own Azure resource.

Shortening secret expiry instead of adopting workload identity federation

Federation exchanges a short-lived OIDC token from the pipeline for Microsoft Entra access, so no client secret is stored or rotated. A 30-day secret is still a stored secret. Restrict each service connection to approved pipelines as well.

Running git revert to remove a committed secret

The credential stays in earlier history. Rewrite history with git filter-repo or BFG, force push, have everyone re-clone, and rotate the secret because it is already exposed. Secret scanning with push protection stops the next leak before it lands.

Swapping lead time and cycle time in metrics questions

Lead time starts when the work item is created and reflects what customers wait. Cycle time starts when work begins and reflects team throughput. A widening band on a cumulative flow diagram, not a burndown, shows where work is stuck.

Resources to help you pass Azure DevOps Engineer AZ-400 on your first attempt

Find out whether your pipeline, identity and deployment choices meet the AZ-400 bar.