Microsoft AZ-400 DevOps Engineer Practical Preparation: Scenarios, Exercises, and Skills to Rehearse

 

AZ-400 preparation becomes much more efficient when the current skills outline is converted into things you can build, break, observe, and explain. Microsoft expects candidates to reason about DevOps across people, processes, products, source control, automation, security, delivery, monitoring, and feedback. That means passive study has a ceiling. You can memorize what a branch policy is and still be unprepared to choose one. You can recognize a GitHub Actions example and still be unable to explain why the workflow receives too much permission. You can know that canary deployment exists and still be unable to define the evidence that makes a canary safe.

The current exam strongly emphasizes build and release pipelines, which account for about 50-55 percent of the blueprint. Processes and communications, source control, and security/compliance each account for about 10-15 percent, while instrumentation is about 5-10 percent. A practical plan should respect that weighting while still connecting the domains. The best exercises are therefore not isolated feature demos. They are compact delivery systems where one change passes through planning, source control, CI, security, deployment, and production feedback.

The exercises below can be done with a small legal lab and disposable resources. Their purpose is not to recreate a large enterprise. Their purpose is to make design decisions visible. ExamSnap’s AZ-400 implementation guide can provide wider implementation context, while the exercises below deliberately force hands-on decisions and failure analysis.

Build one small system that can support many experiments

Start with a deliberately simple application: a minimal web API, static web application with a small backend, or containerized service. The application should be simple enough that you spend time on DevOps rather than business logic. Put it in a repository and create at least two environments, even if they are lightweight.

Choose either GitHub or Azure Repos as the primary repository, but plan to repeat selected controls in the other platform because Microsoft explicitly expects experience with both GitHub and Azure DevOps solutions. Use Azure Pipelines or GitHub Actions for the main pipeline and create a smaller equivalent in the alternative platform later.

Define a few nonfunctional requirements before touching YAML: every change must be reviewed; builds must be repeatable; the same artifact should progress between environments; production access must be narrowly scoped; secrets should not be embedded in code; failed tests must block deployment; a production health signal must determine whether release is healthy.

Those requirements become the constraints that make the lab useful. Without constraints, every configuration looks acceptable.

Exercise 1: connect work items to code and deployment evidence

Create a work item or issue that describes a small change. Give it acceptance criteria and an owner. Create a branch from that item, make the change, open a pull request, and connect the pull request back to the work record. When the pipeline runs, preserve enough metadata that you can identify which commit and work item produced the deployed artifact.

Then ask a reconstruction question: if an incident occurs two days later, can you trace from the production version back to the deployment, artifact, build, commit, pull request, reviewer, and original work item?

If not, your traceability is incomplete.

Repeat the exercise with a defect. Notice how useful traceability becomes when explaining why a risky change was made and who approved it. This is not about surveillance; it is about making the delivery system observable to the organization.

For exam preparation, be able to explain where GitHub Issues/Projects, Azure Boards, repository links, deployment status, and dashboards fit. The exact product may vary, but the principle is persistent evidence across the flow of work.

Exercise 2: design branch protection or branch policies that match risk

Protect the main branch. Require a pull request. Require at least one review. Require a successful validation workflow. Add ownership rules for a sensitive area of the repository.

In GitHub, explore rulesets or branch protection and CODEOWNERS. In Azure Repos, explore branch policies such as minimum reviewers, build validation, comment resolution, and work-item linking. Do not simply turn on every control. For each control, write one sentence explaining what failure it prevents and one sentence explaining its cost.

Then create edge cases. What happens when a hotfix is urgent? What happens when a repository administrator can bypass the rule? What happens when the required build is renamed? What happens when the same person authors and approves a change?

The exam rewards design judgment. A policy is useful only when it supports the workflow and risk model. Rehearse explaining why a rule exists and how exceptions are governed.

Exercise 3: compare branching strategies with the same application

Run two short development cycles using different approaches. In one, use short-lived branches merging frequently to main. In another, maintain a longer-lived release branch. Record merge effort, synchronization work, release isolation, and operational overhead.

Then model a regulated scenario where a released version must be maintained while new development continues. A release branch may have a role there. Model a high-frequency SaaS team where changes are small and continuously deployed. Long-lived branches may create unnecessary divergence.

Do not try to identify “the AZ-400 branching strategy.” There is no single correct strategy for every organization. Practice matching branching to deployment model, release cadence, team topology, risk, and support needs.

Finally, explain how feature flags can decouple deployment from release. A feature flag can allow code to reach production without exposing functionality to all users, but it also introduces lifecycle and configuration complexity that must be managed.

Exercise 4: create a pull-request validation pipeline

Build a fast pipeline that runs on pull requests. It should restore dependencies, compile or validate the code, run unit tests, and produce test results. Add one static analysis or linting step.

Measure how long feedback takes. Then deliberately make it slow by adding an expensive integration test. Decide whether the expensive test belongs in every pull request, in a separate stage, or after merge. Your answer should consider risk, feedback speed, cost, and confidence.

Next, add path filters if the repository contains multiple components. Make sure a documentation-only change does not needlessly build an unrelated service unless policy requires it.

This exercise teaches a core principle: pipeline design is an optimization problem. The goal is not to run every possible check as early as possible; it is to produce trustworthy feedback at the right point in the flow.

Exercise 5: build once and promote the same artifact

Create a CI process that produces a versioned artifact or container image. Record commit information in the artifact metadata or release record. Deploy that same artifact to a test environment and later to production.

Do not rebuild the application separately for production. Rebuilding can introduce dependency drift, environment differences, or an unreviewed change in build inputs. Promotion strengthens confidence that the thing tested is the thing released.

Now test rollback. Keep the previous artifact available. Deploy a bad version to a nonproduction environment, detect failure, and return to the prior version. Record which parts of rollback are application-level, infrastructure-level, and data-level.

The exercise exposes a common misconception: “rollback” is not always easy. Database schema changes, stateful systems, and irreversible external side effects can make simple redeployment insufficient. A good AZ-400 design anticipates this.

Exercise 6: use pipeline templates or reusable workflows

As the lab grows, duplicate one pipeline pattern into a second component, then refactor common logic.

In Azure Pipelines, explore YAML templates for stages, jobs, or steps. In GitHub Actions, explore reusable workflows and composite actions where appropriate. Decide what should be centrally governed and what teams should customize.

A template can enforce secure defaults, artifact naming, scanning, or deployment conventions. It can also become a bottleneck if every small change requires a central team. Reusable components need versioning and ownership.

Intentionally introduce a breaking change to the shared template in a safe branch. How would consuming repositories detect or avoid breakage? Can versions be pinned? Who tests template changes? How do you roll them out?

This is the kind of operational reasoning that turns “I know templates exist” into practical readiness.

Exercise 7: compare Microsoft-hosted and self-hosted agents or runners

Run the same build on a hosted execution environment and a self-hosted one. Record setup time, network access, tool availability, performance, maintenance burden, and security implications.

A self-hosted agent may be necessary to reach private resources or use specialized software. It also becomes infrastructure you must patch, monitor, scale, isolate, and protect. A compromised agent can expose credentials or build outputs. Persistent workspaces can accidentally carry state between jobs.

A hosted agent reduces maintenance and often provides clean execution, but it may have network or customization limitations.

Rehearse a scenario: a deployment must reach a private endpoint inside a restricted network. What agent placement solves connectivity without granting unnecessary inbound access? What identity does the agent use? How are updates applied? What happens when capacity is exhausted?

Exercise 8: remove a long-lived cloud secret from deployment

Create a deployment workflow that initially authenticates to Azure with a client secret stored in the platform’s secret store. Use a harmless lab credential with minimal scope and short life.

Then redesign it using workload identity federation where supported. In GitHub, configure OpenID Connect so the workflow can request a token based on trusted repository/workflow conditions. In Azure DevOps, explore workload identity federation for an appropriate service connection.

Document what changed. With a stored client secret, the platform possesses a reusable credential that must be protected and rotated. With federation, trust is established through token exchange and configured subject/audience conditions, reducing standing-secret exposure.

Now examine permissions. Federation does not make an overprivileged identity safe. Scope the Azure role narrowly and restrict which workflows or environments can use the connection.

This one exercise combines identity, least privilege, pipeline governance, and modern DevOps security.

Exercise 9: integrate Key Vault or secure secret handling

Even after removing cloud credentials, applications and pipelines may need secrets. Create a small scenario where a deployment or application needs a database password or API token.

Store the value in an appropriate secret service rather than in source code or plain pipeline variables. Grant the consuming identity only the access required. Verify that logs do not print the secret. Rotate the secret and confirm the application can continue using the new value according to your design.

Then ask whether the “secret” can be eliminated entirely. Managed identity may allow an Azure workload to authenticate to supported services without storing a password. Good security engineering reduces secret count rather than simply moving secrets between stores.

Practice questions often present several technically workable options. The strongest design usually minimizes standing credentials, scopes privilege, preserves auditability, and separates responsibilities.

Exercise 10: add security scanning at different stages

Add at least three kinds of scanning to the lab: secret scanning or credential detection, dependency/software-composition analysis, and static code or configuration analysis. If the application uses containers or infrastructure as code, add a relevant scan there too.

Do not make every finding a build blocker. Decide severity thresholds and exception handling. A critical exposed credential may justify immediate blocking. A lower-confidence code-quality finding may create a work item instead. The decision should consider exploitability, confidence, business risk, and remediation cost.

Create one safe known finding and verify how it appears. Can a developer understand the issue from the pull request? Can a security team track unresolved risk? Is there a way to suppress a false positive with justification rather than silently disabling the scanner?

This builds intuition for integrating security into flow rather than treating scanning as an external report.

Exercise 11: implement a staged deployment with approvals and checks

Create a release that moves through test and production environments. Add an automated test gate before production. Add a manual approval only if you can explain the risk or governance requirement it represents.

Then challenge the design. If the automated evidence is strong, could a low-risk service deploy automatically while a high-risk service requires approval? Can approvals be separated from pipeline code so a developer cannot simply remove them in the same change? Who is authorized to approve?

Approvals should not become ceremonial clicks. They are useful when a human must evaluate information that automation cannot reliably decide, or when policy requires explicit authorization.

Practice describing the difference between a technical check, policy control, and human approval.

Exercise 12: compare blue-green, canary, and rolling deployment

Use diagrams if the lab cannot cheaply implement every strategy.

For blue-green, maintain two production-capable environments and switch traffic when the new one is validated. Think about cost, state, database compatibility, and fast rollback.

For canary, expose the new version to a small portion of traffic or users and define metrics that determine expansion or rollback. A canary without measurable success criteria is just a slow rollout.

For rolling deployment, replace instances gradually. Think about mixed-version compatibility and capacity during the update.

Create one failure scenario for each. Then explain which strategy fits a stateless web service, a stateful system, or a high-risk customer workflow. The exam is testing selection, not vocabulary.

Exercise 13: provision infrastructure as code and validate it in pull requests

Describe or build a simple Azure environment with infrastructure as code. The exact language is less important than the workflow: version the definition, review changes, validate syntax and policy, create a plan or preview where available, and deploy through controlled automation.

Make a change that would accidentally broaden network exposure or delete a critical resource. Explore how policy, review, previews, or safety settings can reveal risk before execution.

Separate application and infrastructure responsibilities thoughtfully. In some organizations one pipeline manages both; in others, infrastructure changes have distinct approvals or ownership.

The important skill is treating infrastructure as versioned, reviewable, repeatable code while respecting the higher blast radius some changes carry.

Exercise 14: create production telemetry and a release health check

Instrument the application with at least one useful metric, structured logs, and if practical a trace or dependency signal. Send telemetry to an Azure monitoring solution. Build a dashboard that answers a real operational question, not just “is there data?”

Create an alert for a meaningful condition such as error rate, latency, availability failure, or resource exhaustion. Trigger the condition safely. Verify that the alert reaches an owner and includes enough context to begin investigation.

Now connect deployment to monitoring. Record the deployment time and compare telemetry before and after release. A release health check can use objective evidence to decide whether to continue a rollout.

This exercise teaches why instrumentation belongs in DevOps: feedback closes the loop between code and real behavior.

Exercise 15: create an incident from a failed deployment and feed learning back

Deploy a deliberately flawed change to a safe environment. Detect it through telemetry. Open an incident or work item. Capture the affected version, diagnostic evidence, timeline, mitigation, and root cause. Restore service. Then create a follow-up improvement.

Avoid turning the exercise into a blame report. Focus on system learning. Why did the change pass validation? Was the test missing? Was the canary metric insufficient? Was the permission model too broad? Did the alert arrive without context?

Add one improvement to the pipeline and verify that the same failure would now be prevented or detected earlier.

This completes the DevOps feedback cycle and integrates process, source control, pipeline, security, and monitoring skills.

Exercise 16: optimize a slow pipeline using evidence

Make the pipeline intentionally inefficient. Disable caching, run unrelated jobs sequentially, repeat dependency downloads, and add a slow test suite. Measure total time and stage durations.

Then optimize one bottleneck at a time. Parallelize independent work. Cache safely. Split fast and slow tests. Reduce redundant execution with path or trigger logic. Choose an agent with appropriate capacity. Preserve evidence that optimization did not reduce quality.

Do not optimize blindly. Faster is not always better if it makes builds nondeterministic or hides important checks. The exam can present trade-offs between speed, cost, and confidence.

Your final explanation should identify what changed, why it was the bottleneck, and what new risk the optimization introduced.

Exercise 17: recover from a repository mistake

In a disposable repository, make several safe mistakes: merge an unwanted commit, create a bad tag, and commit a placeholder “secret” that contains no real credential.

Practice using revert for shared history. Compare it with reset and explain when rewriting published history is dangerous. Correct the tag safely. For the fake secret incident, document the order of operations you would use with a real credential: revoke or rotate first, then clean history if necessary, investigate exposure, and add preventive controls.

This rehearsal matters because source control questions often combine Git mechanics with security and collaboration.

Exercise 18: design for a monorepo and a multi-repository system

Create two architecture sketches. In the monorepo version, several components share one repository. Decide how triggers avoid rebuilding everything, how ownership is defined, and how shared libraries are versioned. Consider template reuse and permissions.

In the multi-repository version, services have separate repositories. Decide how shared components are consumed, how cross-repository changes are coordinated, and how release dependencies are managed.

Neither model is automatically superior. A monorepo can simplify atomic changes and centralized tooling but increase repository scale and permission complexity. Multiple repositories can align ownership boundaries but introduce dependency and coordination challenges.

Practice choosing based on organization, coupling, deployment independence, and governance.

Turn the lab into an exam-readiness notebook

For every exercise, keep a short record with four fields: design decision, evidence, failure mode, and alternative.

The design decision states what you chose. Evidence shows that it worked. Failure mode captures what could go wrong. Alternative explains another valid design and when it would be better.

For example: “Use workload identity federation for GitHub Actions to Azure. Evidence: workflow obtains a short-lived token and deploys with a scoped role. Failure mode: overly broad federated subject or Azure role. Alternative: managed identity on an Azure-hosted self-runner when that architecture fits.”

This notebook is far more valuable than screenshots of successful pipelines because it records reasoning.

Use practice questions after the practical work

Once the labs make the concepts concrete, use AZ-400 practice questions to test recognition and decision-making under exam-style constraints. For every wrong answer, map it to one of your exercises. If a question exposes a concept you never implemented, add a small lab. If you implemented it but chose poorly, write the trade-off you missed.

Practice should shorten the path from scenario to principle. A question about slow releases should trigger thoughts about flow, pipeline architecture, feedback, and deployment strategy. A question about authentication should trigger identity, token lifetime, scope, and trust boundaries.

The goal is not to memorize the question. It is to make the underlying decision familiar.

Final practical readiness test

You are approaching AZ-400 readiness when you can create a small delivery system from scratch without treating every step as a copy-paste exercise. You can explain why the branch is protected, why the pipeline builds once, why the artifact is immutable, why deployment identity is scoped, why a particular release strategy fits, and how production feedback changes future work.

You should also be comfortable breaking that system and restoring it. Real DevOps competence appears when green-path automation fails: when a token expires, a runner cannot reach a resource, a policy blocks a merge, a package version changes, or a deployment looks successful while users see errors.

A focused lab will never reproduce every enterprise detail, but it can rehearse the reasoning AZ-400 measures. Build fewer systems, inspect them more deeply, and deliberately connect source control, pipelines, security, infrastructure, and observability into one continuous flow.

Exercise 19: build a supply-chain path from package to production

Create a small internal package or library, publish it to a package feed, and make the application depend on a fixed version. Record who is allowed to publish, how versions are named, and how the build authenticates to the feed.

Then release a new package version with a safe intentional defect. Verify that the consuming build uses the pinned version rather than silently taking an uncontrolled latest version. Add dependency scanning or provenance information where practical.

This exercise connects package management, identity, source control, build repeatability, and security. It also teaches why “the repository did not change” does not always mean “the build inputs did not change.” External dependencies are part of the supply chain.

Exercise 20: create an operational approval policy based on risk

Define three deployment classes: routine low-risk change, higher-risk production change, and emergency remediation. Decide which evidence is automatic and which decision, if any, requires a human.

For the routine path, automated tests and health checks may be enough. For the higher-risk path, an environment approval or change-control decision may be justified. For emergency remediation, define who can bypass, how the action is logged, and what post-change review is required.

The goal is not to discover the one correct approval pattern. It is to rehearse proportional governance. AZ-400 questions often reward designs that protect production without adding meaningless friction.

Capstone: rebuild the entire delivery path from a blank repository

At the end of practical preparation, delete your dependence on the original lab notes. Create a new repository and reproduce the core system from memory: work item, branch protections, pull request validation, build, test, artifact, secure deployment identity, nonproduction deployment, production gate, rollout, health verification, and feedback.

Time the process, but do not optimize for speed. Record every place where you need documentation because you forgot a concept. Those lookups identify final study gaps.

Then break three things chosen at random: remove an Azure role assignment, make a status check fail, and create an unhealthy post-deployment signal. Diagnose each without undoing unrelated controls.

This capstone is a stronger readiness signal than completing dozens of isolated tutorials because it tests integration and retrieval.

A four-week practical sequence

Week one should center on source control and CI: repository strategy, branch governance, pull-request validation, artifacts, and package handling. Week two should center on release: environments, service connections or federation, IaC, deployment strategies, and rollback. Week three should center on security and observability: scanning, least privilege, telemetry, alerts, and incident feedback. Week four should be integration and failure: the capstone, cross-platform translation, and fresh practice questions.

If you have more time, stretch the sequence rather than adding more unrelated subjects. Repeat important exercises with a second platform or new constraints. Depth produces more transfer than a larger pile of demos.

Keep the lab legal, disposable, and inexpensive

Use your own tenant/subscription or an authorized training environment. Never test offensive techniques against systems you do not own, never place real production credentials in a study repository, and remove resources when the exercise is complete.

Cost awareness is also part of professional practice. Tag lab resources, use budgets where available, choose small tiers, and tear down idle infrastructure. Infrastructure-as-code exercises are ideal because they let you recreate and destroy environments consistently.

The discipline you use in a lab should resemble the discipline you would want in a production engineering team.

Exercise 21: prove that a deployment is safe to stop

Build a release workflow that can be interrupted between stages without leaving the environment in an ambiguous state. The exercise is not merely about adding an approval. Define what is immutable, what can be retried, which side effects have already occurred, and how the pipeline determines whether a retry should continue, roll back, or do nothing. Use an application deployment plus an infrastructure change so that you have to reason about both kinds of state.

The lesson is idempotence. A robust delivery system must tolerate retries, agent loss, approval delays, and partial execution. If a stage creates a resource on the first attempt and blindly tries to create it again on the second, the pipeline is not operationally mature even if the happy path works. Practice writing guards, state checks, and deployment records that let an operator understand exactly what happened.

Exercise 22: compare secret-based and federated authentication

Create two small workflows that reach the same Azure resource. One should use a conventional stored credential in a controlled lab; the other should use workload identity federation. Document the trust boundaries, credential lifetime, storage requirements, rotation burden, and likely failure modes. Then remove or corrupt one configuration element and diagnose the resulting authentication failure.

The important skill is not learning that federation is “more secure.” AZ-400 questions can reward understanding of why a design reduces secret-management burden and blast radius, and what configuration makes that possible. You should be able to explain issuer, subject, audience, permissions, and the difference between authenticating a workload and authorizing it to perform an Azure action.

Exercise 23: rehearse a supply-chain incident

Take a sample repository with package dependencies and introduce a deliberately outdated or vulnerable dependency in a disposable environment. Add dependency scanning, define what severity should block a pull request or release, and decide what evidence an exception would require. Then simulate a case where an urgent production fix conflicts with a security gate.

This forces you to balance delivery speed, policy, and risk rather than treating scanning as a checkbox. Record how an exception is time-bounded, who approves it, what compensating controls are applied, and how the issue is tracked to closure. The exam objective around security and compliance becomes much easier when you have practiced the governance behavior surrounding the tool.

Exercise 24: design telemetry backward from an operational question

Start with a question such as “Why did checkout latency increase after release 42?” and work backward to the signals required to answer it. Identify deployment metadata, traces, metrics, logs, dependency timing, and user-impact indicators. Correlate the release with the observed change and define a threshold or alert that would have detected the regression.

This is better than creating dashboards first. Instrumentation exists to support diagnosis and feedback. If a metric has no decision attached to it, it may be noise. Practice deciding which signal would cause a rollback, which would trigger investigation, and which is merely contextual.

Exercise 25: conduct a pull-request governance review

Create a repository with two classes of changes: ordinary application code and a sensitive path such as production infrastructure or security policy. Configure different review expectations for those paths. Add required status checks, ownership, branch protection or policies, and a process for an emergency change. Then attempt to bypass the controls using an account with insufficient permission.

The exercise connects source-control strategy to organizational governance. A correct design should make routine work efficient while making high-risk changes deliberately harder. You should be able to explain why a control belongs at the repository boundary, why some exceptions require elevated authorization, and how auditability is preserved.

How to score practical exercises

Do not score an exercise as complete because the pipeline eventually turned green. Use four evidence levels. Level one is “followed instructions.” Level two is “rebuilt from memory.” Level three is “diagnosed a deliberately introduced failure.” Level four is “explained a trade-off and redesigned the solution for a changed constraint.” The later levels reveal exam readiness far better than tutorial completion.

Keep artifacts from the exercises: short architecture diagrams, YAML snippets, failure logs, decision notes, and postmortems. Before the exam, reviewing these artifacts is more efficient than repeating every lab because each item carries a concrete memory of a design decision or troubleshooting path.