MICROSOFT CERTIFICATION

AZ-400 DevOps Engineer Expert Practice Exam

Exam Number: 3108 | Last updated 16-Apr-26 | 992+ questions across 5 vendor-aligned objectives

The AZ-400 DevOps Engineer Expert certification validates the skills of DevOps engineers who combine people, processes, and technologies to deliver valuable products and services that meet end-user needs and business objectives. This exam measures your ability to work with Azure DevOps, GitHub Actions, Azure Pipelines, Azure Repos, Azure Artifacts, Azure Monitor, demonstrating both conceptual understanding and practical implementation skills required in today’s enterprise environments.

The heaviest exam domains include Design and Implement Build and Release Pipelines (40–45%), Design and Implement Source Control (15–20%), and Configure Processes and Communications (10–15%). These areas collectively represent the majority of exam content and require focused preparation across their respective subtopics.

Additional domains tested include Develop a Security and Compliance Plan (10–15%), and Implement an Instrumentation Strategy (10–15%). Together, these areas round out the full exam blueprint and ensure candidates possess well-rounded expertise across the certification scope.

 Build and release pipelines dominate at 40–45% weight. Master YAML pipeline syntax, multi-stage deployments, and GitHub Actions workflows. Understand both Azure DevOps and GitHub-based CI/CD patterns.

Every answer links to the source. Each explanation below includes a hyperlink to the exact Microsoft documentation page the question was derived from. PowerKram is the only practice platform with source-verified explanations. Learn about our methodology →

547

practice exam users

91.3%

satisfied users

90.3%

passed the exam

5/5

quality rating

Test your AZ-400 DevOps Engineer Expert knowledge

10 of 992+ questions

Question #1 - Design and Implement Build and Release Pipelines

A development team needs to build and deploy a .NET application to Azure App Service every time code is merged to the main branch. The pipeline should include automated tests.

Which pipeline configuration should be implemented?

A) Manual build triggered by the team lead
B) A YAML multi-stage pipeline with CI trigger on main, build stage, test stage, and deploy stage
C) A classic release pipeline without testing
D) Scheduled nightly builds only

 

Correct answers: B – Explanation:
A YAML multi-stage pipeline with CI triggers automates the build-test-deploy cycle on every merge. Nightly builds delay feedback. Manual triggers slow delivery. Omitting tests risks deploying broken code. Source: Check Source

A team needs to build and deploy a .NET application to Azure App Service every time code merges to main. The pipeline should include automated tests.

Which pipeline configuration should be implemented?

A) A classic release pipeline that deploys the latest commit directly without any test stages
B) Manual builds triggered individually by the team lead after reviewing the latest commits
C) Scheduled nightly builds that compile and package the application without test execution
D) A YAML multi-stage pipeline with CI trigger on main including build, test, and deploy stages

 

Correct answers: D – Explanation:
A YAML multi-stage pipeline with CI triggers automates the build-test-deploy cycle on every merge, providing fast feedback and continuous delivery. Nightly builds delay feedback by up to 24 hours. Manual triggers slow delivery and depend on individual availability. Omitting tests risks deploying broken code to production environments. Source: Check Source

A team deploys weekly but had three rollback incidents last month from undetected issues. They need to reduce deployment risk.

Which deployment strategy should the team adopt?

A) Deploy to a staging environment and promote manually after a one-week observation period
B) Implement canary deployments with progressive traffic exposure and automated health rollback
C) Use blue-green deployment switching between environments without runtime health monitoring
D) Deploy directly to all production servers simultaneously during a scheduled off-hours window

 

Correct answers: B – Explanation:
Canary deployments progressively route a small percentage of traffic to the new version, enabling automated rollback on error detection before full exposure. Direct full deployment has no safety net for detecting issues before widespread impact. Blue-green without monitoring may promote faulty versions to the active slot. One-week staging delays delivery and cannot simulate real production traffic patterns and volumes. Source: Check Source

A mobile team builds iOS, Android, and backend services from a single repo. Each component has different build requirements and toolchains.

Which pipeline architecture should be used?

A) Three completely separate repositories each with their own independent build pipeline
B) Template-based YAML pipelines using shared stages with platform-specific template extensions
C) A single monolithic YAML pipeline with all platform steps running sequentially in one job
D) A classic UI-based release pipeline definition configured individually for each platform

 

Correct answers: B – Explanation:
Template-based YAML with shared and platform-specific templates enables code reuse while handling different build toolchains cleanly. A single sequential pipeline is slow and wastes time running unrelated platform steps. Separate repos fragment the codebase and complicate cross-component versioning. Classic UI pipelines lack version control integration and template reusability of YAML definitions. Source: Check Source

An organization wants no code to reach production without security scanning. High-severity vulnerabilities should block the deployment.

Which pipeline enhancement should be added?

A) Manual security review performed by the AppSec team after each production deployment
B) Security scans scheduled to run monthly in a separate independent assessment process
C) Descriptive security requirement notes added to each pull request description template
D) SAST and dependency scanning tools integrated as pipeline gates with severity-based fail rules

 

Correct answers: D – Explanation:
Integrating SAST and dependency scanning as pipeline gates with fail conditions on high-severity findings blocks vulnerable code before production. Post-deployment manual review discovers issues after customer exposure. Monthly standalone scans miss vulnerabilities introduced between scan cycles. PR description notes are informational documentation with no enforcement mechanism in the pipeline. Source: Check Source

A DevOps team manages 20 microservices. When one service changes, only the affected service should rebuild and deploy, not all 20.

Which pipeline feature enables this selective triggering?

A) Configure all 20 pipelines to trigger on every commit to the repository regardless of path
B) Disable continuous integration for all pipelines and rely on manual triggers exclusively
C) Use path-based CI triggers in YAML that filter on each service-specific directory subtree
D) Maintain a single unified pipeline for all services that rebuilds everything on each change

 

Correct answers: C – Explanation:
Path-based triggers fire individual pipelines only when files change within their configured directory scope, enabling targeted per-service builds. Triggering everything on every commit wastes significant build resources and time. Manual-only triggers eliminate CI benefits and slow the development feedback loop. A single pipeline for all 20 services forces unnecessary full rebuilds regardless of actual change scope. Source: Check Source

A team of 15 developers works on a shared codebase. They need parallel feature development, code reviews, and a stable main branch.

Which branching strategy should they adopt?

A) GitHub Flow with short-lived feature branches requiring pull request reviews before merging
B) Individual developer branches that accumulate changes and merge once per month in bulk
C) A single long-lived develop branch where all developers push changes without PR reviews
D) All 15 developers commit directly to the main branch without any code review requirements

 

Correct answers: A – Explanation:
GitHub Flow uses short-lived feature branches with mandatory pull requests, keeping main stable while enabling parallel work with code review. Direct main commits risk breaking the shared branch without review. A single develop branch without PRs lacks quality gates and review. Monthly bulk merges create large, risky integration events with complex merge conflicts. Source: Check Source

A regulated company needs every code change traceable to a work item and approved by at least two reviewers before merging.

Which branch policy should be configured?

A) Email-based approval chains requiring manager sign-off forwarded before each commit
B) Post-merge audits reviewing commit history at the end of each development sprint cycle
C) Branch policies requiring linked work items and a minimum of two reviewer approvals on main
D) No branch policies configured — trust developers to follow the documented review process

 

Correct answers: C – Explanation:
Branch policies enforce work item linking and minimum reviewer counts as mandatory prerequisites for merge completion. No-policy approaches rely entirely on voluntary compliance. Post-merge audits are reactive and cannot prevent non-compliant code from reaching main. Email approvals are manual, unenforceable in the CI pipeline, and create delays. Source: Check Source

A project team needs to visualize sprint work, track burndown, and identify blockers across their Azure DevOps project.

Which Azure DevOps feature provides this visibility?

A) Azure Pipelines run history displaying build success rates and deployment frequencies
B) Azure Boards with sprint planning dashboards, burndown charts, and work item tracking
C) Azure Artifacts feed usage statistics showing package download counts and version details
D) Azure Repos commit history graph showing code change frequency and contributor activity

 

Correct answers: B – Explanation:
Azure Boards provides sprint planning, task boards, burndown charts, and work item status tracking for agile project management. Repos shows code change history, not sprint progress. Artifacts tracks package distribution metrics. Pipelines shows build and deployment history, not sprint-level work tracking. Source: Check Source

A company stores pipeline secrets like database connection strings and API keys. Secrets must be accessible to pipelines but hidden from developers in logs.

Which approach should be used?

A) Use variable groups linked to Azure Key Vault with automatic secret masking in pipeline logs
B) Store secret values in a committed text file within the source code repository root
C) Store secret values directly as plain text variables defined within the pipeline YAML file
D) Pass all secret values as visible command-line arguments to the build and deploy scripts

 

Correct answers: A – Explanation:
Variable groups linked to Key Vault automatically mask secrets in pipeline logs and provide centralized lifecycle management with rotation. Plain text YAML variables expose secrets to anyone reading the pipeline definition. Command-line arguments appear in process listings and log output. Repository files expose secrets to every developer with read access to the codebase. Source: Check Source

Get 992+ more questions with source-linked explanations

Every answer traces to the exact Microsoft documentation page — so you learn from the source, not just memorize answers.

Exam mode & learn mode · Score by objective · Updated 16-Apr-26

Learn more...

What the AZ-400 DevOps Engineer Expert exam measures

  • Configure Processes and Communications (10–15%) — Evaluate your ability to implement and manage tasks within this domain, including real-world job skills and scenario-based problem solving.
  • Design and Implement Source Control (15–20%) — Evaluate your ability to implement and manage tasks within this domain, including real-world job skills and scenario-based problem solving.
  • Design and Implement Build and Release Pipelines (40–45%) — Evaluate your ability to implement and manage tasks within this domain, including real-world job skills and scenario-based problem solving.
  • Develop a Security and Compliance Plan (10–15%) — Evaluate your ability to implement and manage tasks within this domain, including real-world job skills and scenario-based problem solving.
  • Implement an Instrumentation Strategy (10–15%) — Evaluate your ability to implement and manage tasks within this domain, including real-world job skills and scenario-based problem solving.

  • Review the official exam guide to understand every objective and domain weight before you begin studying
  • Complete the relevant Microsoft Learn learning path to build a structured foundation across all exam topics
  • Get hands-on practice in an Azure free-tier sandbox or trial environment to reinforce what you have studied with real configurations
  • Apply your knowledge through real-world project experience — whether at work, in volunteer roles, or contributing to open-source initiatives
  • Master one objective at a time, starting with the highest-weighted domain to maximize your score potential early
  • Use PowerKram learn mode to study by individual objective and review detailed explanations for every question
  • Switch to PowerKram exam mode to simulate the real test experience with randomized questions and timed conditions

Earning this certification can open doors to several in-demand roles:

Microsoft provides comprehensive free training to prepare for the AZ-400 DevOps Engineer Expert exam. Start with the official Microsoft Learn learning path for structured, self-paced modules covering every exam domain. Review the exam study guide for the complete skills outline and recent updates.

Related certifications to explore

Related reading from our Learning Hub