Guide to Preparing for the AZ-400 Microsoft Azure DevOps Solutions Exam
The AZ-400 exam tests whether a DevOps engineer can design a delivery system, not whether they remember the location of a button in Azure Pipelines. Microsoft’s July 27, 2026 skills guide weights build and release pipelines at 50–55% and also assesses collaboration, source control, security, compliance and instrumentation. That emphasis suggests a practical preparation method: build one application delivery pipeline, deliberately break its controls, and explain how to restore a safe release.
This guide is for someone who already knows basic Git and can deploy a small application. It differs from a week-by-week study timetable: each section defines one failure scenario, the evidence required to diagnose it, and a decision an AZ-400 candidate should be able to defend. The Microsoft AZ-400 third-party practice page can help find conceptual gaps after lab work; it does not provide Microsoft’s official questions or replace hands-on testing.
Scenario 1 — A production hotfix bypasses the normal review path
Imagine a team has a protected main branch, an ordinary pull-request workflow, and a critical fix needed during an incident. Someone suggests granting temporary direct-push permission to every developer. A stronger approach preserves the essential checks while providing a documented urgent path: identify the incident, make a narrow change, run an appropriate test set, secure authorized review and trace the resulting artifact to the incident record. The exact approval depth can differ during an emergency, but the system still needs a record of who accepted the risk.
Practice in a disposable repository. Configure branch protection or Azure Repos policies, attempt an unauthorized merge, and inspect which rule blocks it. Then create a short-lived hotfix branch that satisfies an approved emergency process. Confirm that the fix merges or is reconciled into the normal development line afterward. The success criterion is one identifiable source revision reaching production through a reviewable exception—not simply pushing a change quickly.
Scenario 2 — Tests pass, but the release uses a different artifact
A pipeline builds an application for staging, tests it, then builds it again for production. The second build resolves a different dependency version. The staging green check no longer proves the actual deployed binary is the one tested. A defensible delivery pipeline creates a versioned immutable artifact once, records its source commit and dependencies, and promotes that same artifact through approved environments.
Build a small CI job that runs unit tests and publishes an artifact. Add a downstream deployment stage that consumes the published artifact by immutable version. Intentionally change a dependency after the first build, then demonstrate why rebuilding would weaken the evidence chain. The appropriate choice depends on the build tools and retention policy, but the principle is stable: trace source, test result, artifact identifier and deployment record to one release.
Scenario 3 — A YAML pipeline works for one branch but leaks a secret in pull requests
An external contributor opens a pull request and the CI pipeline exposes production credentials as ordinary environment variables. The weakness is not solved by masking a value in logs alone. Separate untrusted code-validation jobs from privileged deployment jobs, constrain which events can access secrets, and prefer appropriately scoped workload identity federation or managed identity mechanisms over long-lived keys where supported.
Create a demonstration repository with a harmless placeholder secret and an untrusted test branch. Verify the CI stage can build and test without accessing the protected deployment identity. Add a gated deployment environment and confirm that the identity is available only when the release conditions are met. Review effective permissions for GitHub Actions or an Azure DevOps service connection; a pipeline YAML file cannot enforce least privilege if its backing service principal is subscription Owner.
Scenario 4 — A deployment updates code before its database is compatible
A new API version expects a column not yet present in the database. The application deploys successfully as a container but immediately fails real requests. Deployment order and compatibility matter more than the number of pipeline stages. A safer plan tests the schema change, considers whether old and new application versions must run simultaneously, and chooses an expand-and-contract or other compatible migration pattern where appropriate.
In a disposable application, add a field and implement a migration with a test database. Rehearse deploying the application before and after the database change; document why one order fails. If an irreversible data transformation is required, identify the last safe rollback point and the recovery procedure. “Revert the container tag” is not a complete rollback plan when the data schema changed in a way the old application cannot read.
Scenario 5 — The infrastructure template reports success but creates risky drift
An engineer changes an Azure resource manually, then the next infrastructure-as-code deployment unexpectedly widens a firewall rule or replaces a resource. A production pipeline should preview changes and compare them with the intended state before applying. Source-controlled Bicep, ARM or another supported IaC definition makes planned changes reviewable, but it does not prevent every operator from making changes outside that path.
Provision a low-cost disposable resource through IaC, change one harmless setting in the portal, then run a plan or what-if comparison. Record which side is now authoritative and how the manual change should be reconciled. Demonstrate that a risky resource replacement would need an explicit approval or a redesigned deployment strategy. A good answer identifies the state difference and business effect rather than reflexively overwriting production because a template expects another value.
Scenario 6 — One failed deployment should not affect every customer
A new release passes integration tests but increases live HTTP 500 rates. Decide whether a canary, ring, rolling or blue-green deployment can limit exposure while preserving rollback or forward-fix options. The choice depends on hosting platform, user sessions, database compatibility and how quickly success metrics become meaningful. A slow rollout is not safer if nobody can detect an unhealthy canary.
Deploy a sample service with a known baseline response. Introduce a version that fails a controlled subset of requests and route a small share of synthetic traffic to it. Monitor error rates or another user-facing service-level signal, then demonstrate an automatic or operator-controlled stop and restoration. Document which metric and threshold caused the action. If release telemetry is delayed, acknowledge that the decision window is less reliable than the diagram suggests.
Scenario 7 — A package feed contains an unexpected vulnerable dependency
A repository resolves a dependency through an upstream feed and suddenly acquires a vulnerable version. Package management belongs in the security and reproducibility story: use an appropriate feed or registry, known version constraints, controlled updates and scanning with an accountable exception process. A scanner finding is a prompt for evaluation, not always proof that the application is exploitable.
Add a non-sensitive example dependency to a disposable project and enable a supported dependency or code security check. Simulate an approved update and document the test evidence. Where a scanner flags a false positive, record the accepted risk, affected artifact and expiry of the exception instead of disabling the whole scan. Review who can publish to the feed and how compromised artifacts would be quarantined or replaced.
Scenario 8 — Alerts fire but no one knows whether the release was harmful
Pipeline health and application health are distinct. A deployment can be technically successful while users experience timeouts, and a failed pipeline can leave the running service unaffected. Instrument both: pipeline duration/failure, artifact and environment identity, application latency/error rate, and useful trace or log context. Azure Monitor alert routing matters when a named responder must connect a degraded service to a recent release.
Emit a deployment marker and generate a controlled application error. Use Application Insights or suitable supported telemetry to correlate the error with the release version and relevant request. Verify the notification reaches the chosen recipient, then show whether the team should roll back, disable a feature flag or repair a dependency. The correct answer may differ by the blast radius and reversibility; the evidence should explain why.
Scenario 9 — The team optimizes deployment frequency but loses traceability
A dashboard shows twice as many deployments after a workflow change, but incident recovery is slower and releases are harder to attribute to work items. Improving one metric does not prove the process improved. AZ-400’s processes-and-communications domain expects traceability among work, source changes, build artifacts, deployment records, incidents and feedback. Choose metrics that reveal both throughput and outcome.
Link one issue or work item to a pull request, build and deployment. Simulate a defect report and trace it back to the change without relying on a developer’s memory. Compare lead time, blocked work, deployment failures and recovery time rather than optimizing frequency alone. A small project with a complete evidence chain is more useful exam preparation than a large project where nothing is attributable.
Final readiness exercise — Trace one complete change and a rollback
Ask a colleague to inspect your release record without a guided tour. They should be able to identify the requirement and source commit, test and security results, immutable artifact, infrastructure plan, deployment approval, production version, user-facing validation and rollback decision. If they cannot establish one of those links, the missing evidence identifies what to practice next. Also run one similar path in the ecosystem you use less often—GitHub Actions or Azure Pipelines—so that the assessed design principle is not trapped inside one product UI.
This scenario-based approach deliberately complements broader Azure DevOps product introductions and time-based study schedules rather than repeating them. Before your appointment, check the current Microsoft AZ-400 skills outline for objective changes. Passing the exam alone is not the same as meeting every prerequisite for the DevOps Engineer Expert credential; verify the certification pathway separately. The durable result is knowing how to make changes repeatable, secure, observable and reversible when an ordinary release takes an unexpected turn.
- Category: Others
