How to pass Designing and Implementing Microsoft DevOps Solutions (AZ-400)
22 min read5 domains coveredFree practice, no sign-up
AZ-400 (Designing and Implementing Microsoft DevOps Solutions) is Microsoft's expert-level DevOps exam and the path to the DevOps Engineer Expert credential. It tests one skill above feature recall: choosing the practice, process, or tooling that best delivers value across the whole software life cycle, on "Azure DevOps" and "GitHub" together. You are handed a scenario with a stated requirement, such as least downtime on a release, least operational overhead on a build, gradual exposure of a new version, least privilege on a deployment identity, or no long-lived secrets in automation, then asked which capability meets it. The hard part is rarely knowing what a feature does. It is knowing which of two or three plausible options actually satisfies the requirement the stem names.
It suits practising DevOps engineers, build and release engineers, and platform engineers who already work across both "Azure DevOps" and "GitHub": people who write "Azure Pipelines" and "GitHub Actions" workflows, manage branch policies and pull requests, wire up package feeds, harden deployment identities, and instrument running services. The five domains map to those daily concerns, and the questions assume you have lived with multi-stage YAML, environments and approvals, service connections, and "Application Insights", not just read about them.
The exam is heavily weighted: build and release pipelines is over half of the whole exam, so YAML, deployment strategies, package management, infrastructure as code, and agent infrastructure are where most marks live. The other four domains (processes and communications, source control, security and compliance, instrumentation) are smaller but reliable. Across all of them the questions reward requirement-driven judgement, not datasheets: most items are short scenarios where two answers are technically capable and only one fits the named constraint. That is why practising on scenario questions with a worked explanation, and a reason every wrong option is wrong, beats memorising tool comparison tables.
AZ-400 is a requirement-to-capability exam across "Azure DevOps" and "GitHub": almost every question states a constraint such as least downtime, least operational overhead, gradual exposure, least privilege, or no long-lived secrets, and the right answer is the feature built for that constraint, not the most powerful one.
Difficulty
Advanced
Best for
Practising DevOps, build and release, and platform engineers who already work across "Azure DevOps" and "GitHub" and need to prove they can design and implement pipelines, source control, security, and instrumentation that meet real delivery constraints rather than just describe the tools.
Prerequisites
No exam is formally required, but AZ-400 is built on associate-level Azure experience. Microsoft expects you to already hold or match either AZ-104 (Azure Administrator) or AZ-204 (Azure Developer), plus genuine hands-on time with both "Azure DevOps" and "GitHub". Without working knowledge of YAML pipelines, branching, service connections, and Azure resources, the build and release questions are very hard.
Typically 40 to 60 questions
Questions
150 min
Time allowed
700 / 1000
Pass mark
$165
Exam cost (USD)
293
Practice questions
How this exam thinks
One habit decides this exam: read the scenario for the named requirement, then pick the capability built for it rather than the most feature-rich option. Almost every item states a constraint in plain words (least downtime, least operational overhead, gradual exposure, least privilege, no long-lived secrets, end-to-end traceability) and several options will be technically capable. Only one fits the requirement once you weigh it, and it usually does so at the lowest ongoing effort. The default tie-breaker is the managed, built-in feature that matches the documented pattern: an upstream source on an "Azure Artifacts" feed rather than a hand-maintained mirror, build validation as a branch policy rather than trusting developers, workload identity federation rather than a stored secret, "Application Insights" sampling rather than disabling collection. Reach for the heavier or less obvious option only when the scenario names a reason. The exam also leans on a set of "Azure DevOps" versus "GitHub" discriminations: branch policies versus branch protection rules, "Azure Artifacts" versus "GitHub Packages", "GitHub Advanced Security" versus "Microsoft Defender for Cloud". Name the requirement, then choose the feature designed for it.
What each domain tests and how to study it
The AZ-400 blueprint is split across 5 domains. Weights are the official share of the exam; see the official exam guide for the authoritative breakdown.
What you must be able to do. Given a team's traceability, metrics, and collaboration needs, design and configure the work-tracking links, DevOps flow metrics, dashboards, wikis, and integrations between "Azure Boards", "GitHub", and Microsoft Teams that surface delivery health with the least ongoing effort.
In one sentenceThe flow-and-visibility domain: wiring commits and pull requests to work items, choosing the right DORA metric, and surfacing it on dashboards and wikis without hand-maintained reporting.
Recall check: answer these from memory first
How do you make a commit or pull request automatically link to an "Azure Boards" work item without anyone editing the item by hand?
Which DORA metric reports release cadence as a throughput count, and how does that differ from lead time and cycle time?
When must you publish a code wiki rather than provision a project wiki, and what does each do to the review workflow?
Which dashboard approach trends deployment frequency from pipeline data at the least ongoing effort, and why?
What it tests. Designing how work, code, and conversation connect. Traceability and flow of work (linking commits and pull requests to "Azure Boards" work items, GitHub Flow, source-to-quality traceability); DevOps metrics, queries, and dashboards (the DORA flow metrics of deployment frequency, lead time, cycle time, change failure rate, and time to recovery, and the Analytics-backed widgets that trend them); and collaboration (provisioned versus published code wikis, release documentation, webhooks, and integration across "Azure Boards", "GitHub", and Microsoft Teams).
How to study it. Learn each capability by the requirement it answers. Fix the work-item linking rule: referencing an item by its identifier with the hash syntax in a commit message or pull request description creates the development link automatically, so traceability builds itself. Drill the DORA metrics by what they measure and their units: deployment frequency is a throughput count over a window, while lead time and cycle time are elapsed durations, and change failure rate is a share, so a stem asking for cadence as a count points to deployment frequency. For dashboards, prefer the Analytics-backed widget over any scheduled export or external charting service because it refreshes from live data at the least overhead. For wikis, separate provisioned (inline editor, no review gate) from published code wiki (renders repository markdown and inherits pull request review).
Easy to confuse
Provisioned project wiki versus published code wiki. A provisioned wiki uses an inline editor with no pull request gate, so changes are not reviewed; a published code wiki renders markdown straight from a chosen repository branch and folder, so edits flow through the repository's branch policies and pull request review. If documentation must be reviewed before it appears, it is a published code wiki.
Deployment frequency versus lead time. Deployment frequency is a count of successful production deployments in a window, a throughput measure of how often you ship; lead time is an elapsed duration from change requested to in production, a speed measure for one change. A stem asking for cadence as a count wants deployment frequency, not an elapsed-time metric.
Worked example from the AZ-400 bank
lock_openFree sampleDesign and Implement Processes and Communicationsmedium
Leadership asks for a single DORA metric that answers how often the team delivers value to users, reported as a throughput count over a window rather than as any elapsed duration, so they can compare release cadence against an industry benchmark. Which metric should the team report?
ALead time, calculated from when a change is requested until it reaches production, which reports the elapsed duration a single change takes to travel through the delivery pipeline.
BChange failure rate, calculated as the share of deployments that cause a production failure needing remediation, which reports how risky the team's releases are to ship.
CCycle time, calculated from a developer's first commit until the change reaches production, which reports how long active development and delivery take for a single item.
DDeployment frequency, calculated as the number of successful production deployments completed in a window, which reports how often the team releases value as a throughput count.check_circle Correct
Recognise deployment frequency as the DORA flow metric reporting release cadence as a throughput count, distinct from elapsed-time measures. DORA expresses delivery throughput as deployment frequency, a count of successful production deployments per window, and delivery speed as lead time, an elapsed duration. Because leadership asked for a cadence count rather than a duration, deployment frequency is the metric, and the elapsed-time measures cycle time and lead time do not fit.
Why A is wrong: Lead time is a DORA flow metric but expresses an elapsed duration per change, not a throughput count of how often the team ships, so it answers the wrong shape of question.
Why B is wrong: Change failure rate is a DORA stability metric about release quality, not a count of how often the team deploys, so it does not express delivery cadence.
Why C is wrong: Cycle time is an elapsed-duration measure for one item's active development, so it cannot serve as the throughput count of releases per window leadership wants.
Why D is correct: Deployment frequency is the DORA flow metric expressed as a count of production deployments per window, which is exactly the cadence throughput figure leadership asked to benchmark.
What you must be able to do. Given collaboration scale, review, and repository-management requirements, design the branching model, the pull request and merge-restriction policy, and the repository configuration that keep integration debt low and protect the default branch using the right "Azure Repos" or "GitHub" mechanism.
In one sentenceThe Git-strategy domain: choosing a branching model, gating merges with branch policies or branch protection rules, and managing repositories including tags, large files, and recovery.
Recall check: answer these from memory first
Which branching strategy best suits a team that integrates many times a day and wants to keep merge conflicts small, and why?
What does a required build validation branch policy validate that a plain CI trigger does not, and how does it gate the merge?
When do you need an annotated Git tag rather than a lightweight one for a release marker?
Which "GitHub" branch protection setting discards an approval automatically when new commits are pushed to a pull request?
What it tests. Designing how code is organised and protected. Branching strategy (trunk-based, feature branch, and release branch models, and matching one to how often a team integrates); pull request and merge restrictions (build validation, required reviewers, dismissing stale approvals, and the difference between "Azure Repos" branch policies and "GitHub" branch protection rules); and repository management (Git LFS for large files, scaling, permissions, lightweight versus annotated tags, and recovery or removal of specific data).
How to study it. Match each requirement to one mechanism. For branching, tie integration frequency to model: a team integrating many times a day with short-lived branches wants trunk-based development, whereas long-lived parallel branches (GitFlow, release branches) let divergence accumulate. For merge gating, learn that a required build validation branch policy queues the chosen pipeline against the merged preview of a pull request and blocks completion until it succeeds, which is stronger than a bare CI trigger. Keep the platform vocabulary straight: "Azure Repos" uses branch policies, "GitHub" uses branch protection rules with options such as dismiss stale approvals on new commits. For repository management, separate lightweight tags (bare movable pointers) from annotated tags (full objects holding tagger, date, message, and a signature).
Easy to confuse
"Azure Repos" branch policies versus "GitHub" branch protection rules. Branch policies are the "Azure Repos" mechanism (build validation, required reviewers, comment resolution) configured per branch in the project; branch protection rules are the "GitHub" equivalent (required reviews, required status checks, dismiss stale approvals). The terminology is platform-specific, so match the named platform in the stem to the right one.
Lightweight tag versus annotated tag. A lightweight tag is just a movable name pointing at a commit; an annotated tag is a full object in the database holding the tagger, timestamp, and message, and it can be GPG-signed. A release marker that must be verifiable, metadata-rich, and explicitly pushed for the team needs an annotated tag.
Worked example from the AZ-400 bank
lock_openFree sampleDesign and Implement a Source Control Strategymedium
An "Azure Repos" team wants the project's continuous integration pipeline to run against the merged result of every pull request targeting main, and a pull request must be blocked from completing while that pipeline is failing or has not yet run. Which configuration achieves this directly on the main branch?
AAdd a continuous integration trigger to the pipeline YAML so a commit to any pull request branch starts the build, and rely on developers not to complete a pull request while that build is red.
BAdd a build validation branch policy on main that references the continuous integration pipeline, marking it required so a pull request cannot complete until the build succeeds against the merged source.check_circle Correct
CConfigure a required reviewers policy that adds the pipeline service account as a mandatory reviewer, so its automated approval depends on the build outcome before the pull request can merge.
DEnable a status check policy and have the pipeline post a status to the pull request on completion, then block merges manually whenever the posted status indicates the build did not succeed.
Apply a required build validation branch policy so the CI pipeline runs on the merged pull request and gates completion. Build validation is a branch policy in Azure Repos that automatically queues a chosen pipeline against the merged preview of a pull request. When marked required, completion is blocked until the build succeeds, ensuring the merge result is validated rather than just the source branch tip.
Why A is wrong: A CI trigger does start builds on commits, which is tempting, but it does not gate pull request completion; nothing stops a developer from merging while the build is failing.
Why B is correct: A required build validation policy queues the named pipeline on the pull request's merged result and blocks completion until it passes, which is precisely the stated requirement.
Why C is wrong: Required reviewers adds an approver and is tempting because it gates completion, but a service account does not vote based on a build result, so this neither runs nor evaluates the pipeline.
Why D is wrong: Status checks can gate on a posted status, but manual blocking is not enforcement and rebuilding this with external statuses duplicates the purpose-built build validation policy unnecessarily.
What you must be able to do. Given delivery, packaging, testing, deployment, and infrastructure requirements, design and implement the "Azure Pipelines" or "GitHub Actions" workflow, the package and versioning strategy, the deployment pattern that minimises downtime or exposes change gradually, and the infrastructure-as-code and agent design that meet them at the least operational overhead.
In one sentenceThe dominant domain: YAML pipelines, package feeds, testing and gates, deployment strategies, infrastructure as code with "Bicep", and agent infrastructure, all chosen to fit the stated delivery constraint.
Recall check: answer these from memory first
Which "Azure Artifacts" feed capability lets builds survive a public-registry outage and keeps every pulled version, and how does it work?
How do you declare in a Release pipeline's YAML that it should start when a separate CI pipeline completes successfully and consume its artifacts?
How does a downstream YAML job read an output variable set by an earlier job in the same stage, and what must it declare?
Which deployment strategy gives near-zero downtime by swapping a warmed-up target into production, and which exposes a new version gradually to a subset of users?
What it tests. Over half of the whole exam, the engine room of delivery. Package management with "Azure Artifacts" and "GitHub Packages" (feeds, views, upstream sources) and versioning with SemVer and CalVer; testing strategy and quality, release, and security gates with code coverage; deployment automation across "GitHub Actions", "Azure Pipelines", and their integration; authoring YAML (triggers, multi-stage pipelines, job order, parallelism, output variables, pipeline resources and templates, variable groups); agent and runner infrastructure (Microsoft-hosted versus self-hosted, scale set agents, cost, connectivity); checks and approvals on YAML environments; deployment strategies (blue-green, canary, ring or progressive exposure, feature flags, A/B); downtime-minimising mechanics (deployment slots and swap, rolling deployments, hotfix paths, containers, database tasks); and infrastructure as code with ARM, "Bicep", desired state configuration, and Azure Deployment Environments.
How to study it. Spend the most time here because it is over half the exam. For packaging, learn an upstream source on an "Azure Artifacts" feed as the answer to surviving a public-registry outage and retaining pulled versions, since it proxies and caches transparently. For pipelines, drill multi-stage YAML mechanics until they are automatic: a resources pipelines entry with a pipeline trigger chains one pipeline to another's successful completion and artifacts (distinct from a CI trigger on code pushes), and a downstream job reads a cross-job output variable through the dependencies context keyed by producing job and step name, with dependsOn declared. For infrastructure as code, fix the "Bicep" what-if operation as the tooling-produced preview of creates, modifications, and deletions before applying. For deployment, map each requirement to a pattern: deployment slots and swap for near-zero-downtime releases, canary or ring for gradual exposure, blue-green for instant rollback. For agents, weigh Microsoft-hosted (no maintenance) against self-hosted or scale set (custom software, private connectivity, controlled cost).
Easy to confuse
Pipeline-completion trigger (resources pipelines) versus CI trigger. A resources pipelines entry with a pipeline trigger starts a pipeline when another named pipeline completes successfully on a matching branch and lets it consume that run's artifacts; a CI trigger fires on code pushes to the pipeline's own repository. When the dependency is on another pipeline finishing, it is a pipeline-completion trigger, not a CI trigger or a schedule.
Blue-green deployment versus canary deployment. Blue-green keeps two full environments and switches all traffic from the old to the new at once, giving instant rollback by switching back; canary shifts a small percentage of traffic to the new version first and grows it as health holds, exposing change gradually. Choose blue-green for instant cutover and rollback, canary or ring for progressive exposure.
Worked example from the AZ-400 bank
lock_openFree sampleDesign and Implement Build and Release Pipelineshard
Before a Bicep deployment to a busy production resource group runs in the pipeline, reviewers want a report that lists exactly which resources the deployment would create, modify, or delete, and which properties would change, without applying anything. They want this output generated by the deployment tooling itself rather than inferred from a diff of the source files. Which operation produces it?
ARun the deployment in validate mode, which submits the template to Azure Resource Manager to confirm it is syntactically correct and the parameters resolve before the real deployment is attempted.
BBuild the Bicep file to ARM JSON and run a text diff of the generated template against the previously deployed template stored in source control to see which lines changed.
CDeploy in complete mode to a throwaway resource group first, then compare the resources created there against production to estimate what the real deployment would change.
DRun the "what-if" operation against the deployment, which has Azure Resource Manager evaluate the template and report the resource and property level changes it would make without applying any of them.check_circle Correct
Use the ARM and Bicep what-if operation to preview resource and property level changes before applying a deployment. The what-if operation sends the template to Azure Resource Manager, which compares it against the current state of the target scope and returns the predicted set of creates, modifications, and deletions down to changed properties, all without performing the deployment. This is the tooling-produced preview reviewers need, and it is more accurate than diffing source files because it accounts for live state and defaults.
Why A is wrong: Validate mode confirms a template would be accepted, which is useful, but it does not enumerate the per-resource and per-property create, modify, or delete changes the reviewers want to see before applying.
Why B is wrong: A text diff of compiled templates shows source changes but not the actual effect on live resources, since it cannot account for current resource state or defaults, so it is the source-file inference the requirement explicitly rejects.
Why C is wrong: Deploying to a scratch resource group does apply resources and still would not mirror production state, so it is slower, costs money, and does not give the non-destructive predicted-change report that what-if provides directly.
Why D is correct: The what-if operation asks Azure Resource Manager to predict the effect of a deployment and returns the create, modify, and delete changes at resource and property level without making any change, which is exactly the pre-apply report requested.
What you must be able to do. Given authentication, secret-management, and scanning requirements, design the identity and authorisation model for pipelines and connections, eliminate long-lived secrets from automation, and automate dependency, code, secret, and licence scanning using the right "GitHub Advanced Security" or "Microsoft Defender for Cloud" capability.
In one sentenceThe shift-left domain: least-privilege identities for pipelines, secretless authentication with workload identity federation and "Azure Key Vault", and automated scanning across code, dependencies, secrets, and licences.
Recall check: answer these from memory first
How does an "Azure Pipelines" service connection authenticate to Microsoft Entra with no long-lived secret stored anywhere, and what two values pin the trust?
Where do you store a code-signing certificate so it is not in the repository or a variable but is available only to authorised pipelines?
Which "GitHub Advanced Security" capability produces a machine-readable component and licence inventory that can flag a forbidden licence on a pull request?
When does the exam want a managed identity or service connection at least privilege rather than a personal access token?
What it tests. Securing the delivery chain. Authentication and authorisation (Microsoft Entra service principals, managed identities, GitHub Apps, and "Azure DevOps" service connections and permissions at least privilege); managing sensitive information in automation ("Azure Key Vault", secure files, secretless authentication, and workload identity federation with its federated-credential issuer and subject); and automated security and compliance scanning (dependency, code, secret, and licence scanning with "GitHub Advanced Security" features such as CodeQL, Dependabot, secret scanning, the dependency graph and dependency review, and "Microsoft Defender for Cloud").
How to study it. Anchor every answer to a security requirement. For secretless authentication, fix workload identity federation as the answer when the pipeline must hold no exportable credential: "Azure DevOps" presents a short-lived OpenID Connect token to Microsoft Entra and exchanges it for an access token, and the federated credential is pinned by its issuer and subject so only the intended service connection's runs can use it. For files that cannot live in the repository or a variable, learn secure files in the "Azure DevOps" Library with the download secure file task. For scanning, map each requirement to the right "GitHub Advanced Security" feature: CodeQL for code vulnerabilities, secret scanning for committed credentials, Dependabot for vulnerable and out-of-date dependencies, and the dependency graph plus dependency review for a component and licence inventory that flags forbidden licences.
Easy to confuse
Workload identity federation versus a service principal with a client secret. Workload identity federation stores no secret or certificate: the connection presents a short-lived OpenID Connect token and exchanges it for an Azure access token via a federated credential pinned by issuer and subject. A service principal with a client secret holds a long-lived credential that can be exported or leaked, even if stored in "Azure Key Vault". When the requirement is no long-lived secret, it is federation.
Dependency review and the dependency graph versus secret scanning. The dependency graph plus dependency review enumerate resolved components and their licence metadata, so they flag a disallowed licence on a pull request; secret scanning detects committed credentials and tokens, not licences. A licence-inventory requirement points to dependency review, not to secret, code, or version-update tooling.
Worked example from the AZ-400 bank
lock_openFree sampleDevelop a Security and Compliance Planhard
A pipeline in "Azure Pipelines" deploys to an Azure subscription through an Azure Resource Manager service connection. A security review requires that the pipeline hold no long-lived credential that could be exported or leaked, while still authenticating to Microsoft Entra to obtain Azure access tokens. Which way of configuring the service connection meets the requirement?
ACreate the service connection using a Microsoft Entra service principal with a client secret, then store that secret in "Azure Key Vault" and have the pipeline read it at run time so it is never committed to the repository.
BCreate the service connection using workload identity federation so Azure DevOps presents an OpenID Connect token to Microsoft Entra and exchanges it for an access token, with no secret or certificate held on the connection.check_circle Correct
CCreate the service connection using a Microsoft Entra service principal authenticated with a certificate, and rotate the certificate automatically every ninety days so a leaked credential has a short useful lifetime.
DCreate the service connection from a personal access token scoped only to release management, and grant that token rights on the subscription so the pipeline authenticates without storing an Entra service principal secret.
Use workload identity federation on an Azure Resource Manager service connection to authenticate to Microsoft Entra without storing any long-lived secret. Workload identity federation configures a federated credential in Microsoft Entra that trusts tokens issued by Azure DevOps. At run time the service connection presents a short-lived OpenID Connect token and exchanges it for an Azure access token, so authentication succeeds without any client secret or certificate being stored on the connection.
Why A is wrong: Keeping the secret in a vault improves storage hygiene and is tempting, but a client secret is still a long-lived credential that can be exported, so it does not satisfy the no-stored-credential requirement.
Why B is correct: Workload identity federation lets the service connection exchange a short-lived OpenID Connect token for an Azure access token through a federated credential, so no secret or certificate is ever stored, meeting the requirement exactly.
Why C is wrong: Certificate credentials with rotation reduce exposure and look secure, but the certificate is still a long-lived secret stored against the connection, which is exactly the artefact the review wants eliminated.
Why D is wrong: A personal access token authenticates to Azure DevOps itself rather than to an Azure subscription, and it is still a long-lived secret, so it can neither perform the deployment nor satisfy the requirement.
What you must be able to do. Given monitoring and analysis requirements, configure the right "Azure Monitor" and "Application Insights" telemetry, alerting, and querying so the team gets application-level visibility, real-time deployment monitoring, and anomaly detection without authoring fixed thresholds where a learned baseline fits better.
In one sentenceThe observability domain: enabling "Application Insights" for request and dependency telemetry, controlling its cost with sampling, watching deployments live, and detecting anomalies against a learned baseline.
Recall check: answer these from memory first
Which capability auto-collects request, dependency, and failure telemetry with correlated distributed traces, and how does it differ from VM or Container Insights?
How do you cut "Application Insights" ingestion cost while keeping representative data and accurate aggregate counts?
Which feature lets you watch an instrumented service at roughly one-second latency during a deployment so you can abort on the first sign of trouble?
Which "Application Insights" feature alerts on abnormal degradation against a learned baseline with no fixed threshold authored in advance?
What it tests. Seeing what production is doing. Monitoring configuration ("Azure Monitor", "Application Insights" for application telemetry, Container Insights, and alerts for "GitHub Actions" and "Azure Pipelines"); and analysing metrics (infrastructure performance indicators, distributed tracing that correlates a request across services, Live Metrics Stream for near one-second latency during a rollout, Smart Detection for baseline-relative anomaly alerts, sampling to cut ingestion cost, and Kusto Query Language for querying telemetry).
How to study it. Separate application-level telemetry from infrastructure counters. Fix "Application Insights" as the answer for auto-collecting request rates, response times, failures, and dependency calls with correlated distributed traces, distinct from VM Insights or Container Insights, which report host and container resource counters. For cost, learn that sampling retains a correlated representative subset and adjusts aggregate counts, so it cuts ingestion without losing trend fidelity, unlike shortening retention or disabling collection. For watching a deployment, use Live Metrics Stream for a near one-second live view that bypasses ingestion lag. For anomaly alerting without a hand-set threshold, use Smart Detection, which learns each operation's normal failure rate and latency and warns on abnormal deviation, distinct from static metric alerts and scheduled log search alerts that depend on author-set thresholds.
Easy to confuse
"Application Insights" versus Container Insights or VM Insights. "Application Insights" auto-instruments per-request application behaviour: requests, dependencies, exceptions, and correlated distributed traces; Container Insights and VM Insights report host, node, pod, and resource counters. When the requirement is per-request and dependency telemetry with traces, it is "Application Insights", not an infrastructure-focused insight.
Smart Detection versus a static metric alert rule. Smart Detection learns each operation's normal failure rate and latency from history and fires when current behaviour deviates abnormally, with no threshold authored in advance; a static metric alert needs the author to set the exact numeric level. When the requirement is anomaly detection against a learned baseline, it is Smart Detection.
Worked example from the AZ-400 bank
lock_openFree sampleImplement an Instrumentation Strategymedium
During a production deployment, engineers want to watch their "Application Insights" instrumented service in real time, seeing incoming request rates, failures, and server performance counters with a latency of roughly one second, so they can abort the rollout the instant the new build misbehaves. They do not want to wait for telemetry to be ingested and queried. Which Application Insights feature gives them this immediate view?
ARun a Kusto query over the requests table on a short time range and refresh it repeatedly so the most recent ingested request and failure rows appear as they arrive.
BConfigure a near-real-time metric alert on the server response time so the team is notified within the evaluation window when the new build slows the service after deployment.
COpen the Live Metrics Stream for the resource to watch incoming requests, failures, and performance counters updating at roughly one-second latency directly from the running instances.check_circle Correct
DEnable Profiler on the resource so it captures detailed call stacks and traces of slow requests that the team can examine after the deployment completes.
Use Live Metrics Stream to watch Application Insights telemetry at near one-second latency for real-time monitoring during a deployment. Live Metrics Stream pushes request, failure, and performance counter data from the running application to the portal at roughly one-second latency, bypassing the ingestion and indexing pipeline that ordinary queries depend on. This makes it the right feature for watching a deployment live and aborting on the first sign of trouble. Refreshed Kusto queries and metric alerts both depend on ingested data and so lag by minutes, and Profiler produces after-the-fact call-stack samples rather than a live view.
Why A is wrong: Querying the requests table reflects ingested data and is tempting for recency, but ingestion and indexing add minutes of delay, so a refreshed query cannot deliver the roughly one-second view required to abort a rollout immediately.
Why B is wrong: A metric alert reacts automatically and feels fast, but it notifies only after an evaluation window passes and shows a single metric, not the live multi-signal stream engineers want to watch during the rollout.
Why C is correct: Live Metrics Stream pushes metrics from the running application to the portal at about one-second latency without the usual ingestion and indexing delay, which is exactly the near-instant deployment-watch view the engineers need.
Why D is wrong: Profiler captures call-stack traces for slow requests and is useful for root cause, but it produces samples for later analysis rather than a live one-second view, so it cannot support aborting the rollout in the moment.
A study plan that works
Map the blueprint and book a date
Day 1
Read Microsoft's skills-measured outline and the five domains with their weights, and note immediately that build and release pipelines is over half the exam while processes, source control, security, and instrumentation share the rest. Book a provisional date now: a fixed date turns open-ended study into a plan and is the strongest predictor of actually sitting. Weight your calendar to match the weighting.
Build the requirement-to-capability maps
Week 1
Before drilling any domain, build the decision maps the whole exam rests on: the "Azure DevOps" versus "GitHub" vocabulary (branch policies versus branch protection rules, "Azure Artifacts" versus "GitHub Packages", "GitHub Advanced Security" versus "Microsoft Defender for Cloud"), and the requirement keywords (least downtime, gradual exposure, no long-lived secret, least operational overhead). Use the recall prompts in this guide: cover the answer, choose from the constraint, then reveal. If you cannot pick from the requirement alone, you do not own it yet.
Go deep on Build and Release Pipelines, part one
Weeks 1 to 3
This is over half the exam, so it gets the most time. Start with YAML mechanics until they are automatic: multi-stage pipelines, triggers, job order and parallelism, output variables through the dependencies context, pipeline resources and pipeline-completion triggers, templates, and variable groups. Author real pipelines, do not just read them. Then add package management: "Azure Artifacts" feeds, views, and upstream sources, "GitHub Packages", and SemVer versus CalVer versioning.
Finish Build and Release Pipelines, part two
Weeks 3 to 4
Cover the rest of the dominant domain: deployment strategies (blue-green, canary, ring and progressive exposure, feature flags, A/B), downtime-minimising mechanics (deployment slots and swap, rolling, hotfix paths, containers, database tasks), checks and approvals on YAML environments, agent and runner infrastructure (Microsoft-hosted versus self-hosted and scale set, cost and connectivity), and infrastructure as code with ARM, "Bicep", the what-if preview, desired state configuration, and Azure Deployment Environments. Drill every choice against its named requirement.
Lock Source Control and Processes and Communications
Week 4
These are reliable marks. For source control, separate branching models by integration frequency, fix build validation as a branch policy, keep branch policies versus branch protection rules straight, and learn lightweight versus annotated tags and LFS. For processes, fix the hash-syntax work-item linking, the DORA metrics by unit, the Analytics-backed dashboard widgets, and provisioned versus published code wikis.
Cover Security and Compliance and Instrumentation
Week 5
Security rewards a clean identity tree: least-privilege service connections and managed identities, workload identity federation with its issuer and subject, secure files and "Azure Key Vault", and the "GitHub Advanced Security" scanning map (CodeQL, secret scanning, Dependabot, dependency graph and review). Instrumentation reduces to "Application Insights" versus infrastructure insights, sampling for cost, Live Metrics Stream for live rollouts, and Smart Detection for baseline anomalies.
Drill weak domains, then sit timed mocks
Weeks 5 to 6
Use your per-domain accuracy to attack the areas dragging you down, not to re-read what you already know, and keep build and release pipelines green because it carries the most marks. Take at least one full timed mock under exam conditions to rehearse pacing and the flag-and-return habit, and practise reading any case study once to extract every requirement before answering its cluster. Review every missed question and name the constraint you misread before you book or sit.
Know when you're ready
Readiness for AZ-400 is a measured score on scenario questions you have not seen before, not a feeling that the tools are familiar. Those are different things, and the gap between them is where people fail. Re-reading the documentation builds fluency, and fluency feels like knowledge, so confidence rises while real recall does not. The fix is to test yourself: if you can read a fresh scenario, name the requirement it states, and pick the right capability while explaining why each other option is wrong, you know it; if you can only nod along to an explanation, you do not yet. Be especially wary of early confidence on the feature map. Knowing what build validation, upstream sources, workload identity federation, and "Application Insights" each do is the easy half; choosing the right one under a named constraint, when two would plausibly work, is the half the exam tests. Set the bar at clearing every domain comfortably on unseen questions across more than one session, with build and release pipelines reliably strong because it is over half the exam, not scraping a single pass.
Ready to put this into practice?
Free AZ-400 questions with worked explanations. No sign-up.
Name the requirement in the stem before judging the options. AZ-400 questions state a constraint (least downtime, gradual exposure, least operational overhead, no long-lived secret, end-to-end traceability) and the answer is the capability built for it, not the most powerful one.
Keep the build and release domain green above all. It is over half the exam, so master YAML mechanics, package feeds, deployment strategies, infrastructure as code, and agent design first; weak marks there cost more than anywhere else.
Match the platform vocabulary to the named platform. "Azure Repos" uses branch policies, "GitHub" uses branch protection rules; "Azure Artifacts" and "GitHub Packages" are the two package homes; "GitHub Advanced Security" and "Microsoft Defender for Cloud" cover different scanning scopes. Read which platform the stem names.
When the requirement is no long-lived secret, choose workload identity federation. A service principal client secret, even one stored in "Azure Key Vault", is still an exportable credential, so it loses to a federated OpenID Connect exchange with no stored secret.
Map deployment requirements straight to a strategy. Deployment slots and swap for near-zero downtime, canary or ring for gradual exposure, blue-green for instant rollback; the named outcome picks the pattern.
Prefer the managed, built-in feature at the least overhead when two options both work. An upstream source beats a hand-maintained mirror, an Analytics-backed widget beats a scheduled export, a required build validation policy beats trusting developers.
Flag and move on. Cover every question once before you spend time on a hard one; collecting the clear marks first protects the ones you actually know across a tight clock, and any case study should be read once in full before its questions.
Frequently asked questions
Is AZ-400 hard?
It is an expert-level exam, and the difficulty is judgement rather than recall. Most questions are scenarios where two or three capabilities across "Azure DevOps" and "GitHub" could plausibly work and only one fits the requirement the stem names. Scenario practice with worked explanations matters far more than memorising what each feature does.
Do I need AZ-104 or AZ-204 before taking AZ-400?
Neither is a formal prerequisite, but AZ-400 is built on associate-level Azure experience and Microsoft expects you to hold or match either the AZ-104 (Administrator) or AZ-204 (Developer) skill set. Without that grounding plus hands-on "Azure DevOps" and "GitHub" time, the build and release questions are very hard.
Which domains should I focus on?
Build and release pipelines is over half the whole exam, so it deserves the most time by a wide margin: YAML, package management, deployment strategies, infrastructure as code, and agent infrastructure. The other four domains (processes and communications, source control, security and compliance, instrumentation) are smaller but reliable marks once you separate their key discriminations cleanly.
How much does it test "GitHub" versus "Azure DevOps"?
Both, heavily, and often side by side. The exam expects you to know branch policies and branch protection rules, "Azure Artifacts" and "GitHub Packages", "Azure Pipelines" and "GitHub Actions", and "GitHub Advanced Security" alongside "Microsoft Defender for Cloud". Learn the matching vocabulary so you pick the right tool for the platform the stem names.
How long should I study for AZ-400?
Most candidates with real DevOps experience across both platforms are ready in five to seven weeks of steady study. Less hands-on exposure means more time on the build and release domain, which is over half the exam, and on the requirement-to-capability decisions the whole exam rests on.
What kinds of questions appear?
Multiple choice, multiple response (select two or more, where you must get every correct option), and case studies that stack several decisions on one shared set of requirements. Read each stem for the named constraint, and on multiple-response items treat each option as a separate true-or-false judgement.
How many practice questions should I do before booking?
Enough that every domain clears comfortably on questions you have not seen, with build and release pipelines reliably strong, and a full timed mock feels comfortable on pacing. Quality of review beats raw volume: on every question, read the explanation and name the constraint that picked the answer, including on the ones you got right.
Is AZ-400 worth it?
It genuinely benefits DevOps, build and release, and platform engineers who already work across both Azure DevOps and GitHub and want to formalise their expertise. It earns the DevOps Engineer Expert credential, and organisations running Microsoft toolchains often look for it specifically when hiring for senior pipeline and delivery engineering roles.
Examworthy is not affiliated with or endorsed by Microsoft. This guide is original study material based on the public exam blueprint. We never reproduce live exam items. AZ-400 and related marks belong to their respective owners.
