What the AZ-400 exam covers
- Configure Processes and Communications90 questions
- Design and Implement Source Control106 questions
- Design and Implement Build and Release Pipelines342 questions
- Develop a Security and Compliance Plan111 questions
- Implement an Instrumentation Strategy45 questions
Free AZ-400 practice test questions
A sample of 10 questions with answers and explanations. A free account includes a fixed set of 20 practice questions for this exam, retryable anytime. Paid access unlocks the full 694-question bank.
-
Your organization uses Azure Boards and needs to enforce that every pull request is linked to a work item before it can be completed. Which setting should you configure?
- ACreate a custom pipeline gate that checks for work item links
- BEnable branch policies requiring linked work items on the target branchCorrect
- CConfigure a service hook to block PRs without work items
- DSet up a compliance policy in Azure Policy for the DevOps organization
✓ Correct answer: BA branch policy on the target branch with Check for linked work items set to On blocks a pull request from completing until at least one work item is linked to it; set to Optional, the same policy only warns. Because the check runs on every pull request into that branch, traceability is enforced by Azure Repos itself, without custom pipeline logic or an external tool.
Why the other options are wrong- AGates belong to release deployments and evaluate signals such as work item queries or alerts before a stage deploys; they are not evaluated when a pull request is completed, so they cannot hold a pull request until a work item is linked.
- CA service hook sends event data to an external service after an event occurs; it takes no part in pull request completion, so it cannot stop a pull request that has no linked work item.
- DAzure Policy evaluates Azure resources in subscriptions and management groups; it has no control over pull requests in an Azure DevOps organization.
-
Fabrikam Inc has a multi-stage YAML pipeline that deploys to development, staging, and production environments. The production deployment must require manual approval from two designated approvers. How should this be configured?
- AAdd a manual validation task inside the production deploy job
- BUse Azure Policy to require approvals on resource group deploys
- CSet an approval check on production requiring two approversCorrect
- DCreate a separate release pipeline with manual approval triggers
✓ Correct answer: CAzure Pipelines environments are deployment targets that carry approvals and checks. An approval check on the production environment lists the designated approvers and can set a minimum number of approvers that must approve before the stage proceeds, so requiring two approvals is part of the check itself. Approvals and checks are not defined in the YAML file, and users who modify the pipeline YAML cannot change them, which is what makes this the proper way to enforce multi-person approval in a YAML pipeline.
Why the other options are wrong- AA manual validation task inside the production deploy job lives in the pipeline definition that its author controls, whereas an approval check on the environment is owned by the resource and cannot be removed by editing the YAML.
- BAzure Policy evaluates Azure resource requests against rules and can deny or audit them, but it has no approver list and cannot pause a pipeline stage until two named people approve it.
- DA separate release pipeline with manual approval triggers adds a second pipeline to maintain, while the existing multi-stage YAML pipeline already targets environments whose approval checks provide the two-approver gate.
-
Azure Application Insights smart detection automatically analyzes application telemetry and alerts you to potential performance issues and failure anomalies without any manual configuration of alert rules.
- ATrueCorrect
- BFalse
✓ Correct answer: ASmart detection performs proactive analysis of the telemetry an application sends to Application Insights and warns about failure anomalies, performance anomalies, trace degradation, potential memory leaks, abnormal rises in exception volume and security anti-patterns. It needs no configuration once the application sends enough telemetry, and all rules except those in preview send email notifications by default. It can also be migrated to alert rules so that action groups handle the notifications.
Why the other options are wrong- BFalse is incorrect. Smart detection is documented as needing no configuration: it analyses the telemetry and notifies you of failure and performance anomalies without any alert rule being written.
-
Wide World Importers wants automated scanning of its own application source code for injection and authorization flaws, and separately wants to be warned when the open-source packages it consumes have publicly known CVEs. Which TWO capabilities should the administrator configure? (Choose TWO)
- ACodeQL code scanning on the repositoryCorrect
- BDependency (dependabot) vulnerability alertsCorrect
- CSecret scanning push protection
- DAzure Key Vault variable groups
- EA branch policy requiring linked work items
✓ Correct answer: A, BCodeQL performs static analysis of the application's own code to find injection, authorization, and similar security flaws. Dependency vulnerability (Dependabot) alerts match the packages in the manifest against advisory databases and warn when a consumed open-source component has a known CVE. Together they cover both first-party code analysis and third-party dependency risk.
Why the other options are wrong- CSecret scanning finds committed credentials, not code injection flaws or dependency CVEs.
- DKey Vault variable groups supply secrets to pipelines and perform no scanning.
- ERequiring linked work items is a process control on pull requests and has no security scanning function.
-
A job template named deploy-job.yml should accept a parameter named environments, typed so it can hold a list of environment names, defaulting to dev, test, and prod. Which parameter declaration inside the template is correct?
- Aparameters: - name: environments, type: object, default: [dev, test, prod]Correct
- Bparameters: - name: environments, type: string, default: [dev, test, prod]
- Cparameters: - name: environments, type: objectList, default: [dev, test, prod]
- Dparameters: - name: environments, type: object, default: 'dev,test,prod'
✓ Correct answer: AAzure Pipelines typed parameters support object for arbitrary mappings or sequences, so a default of [dev, test, prod] is valid YAML for that type. type: string expects scalar text, objectList is not a defined parameter type, and a comma-joined string is a scalar, not the list structure the template needs to iterate over.
Why the other options are wrong- Btype: string expects a scalar value; a YAML sequence default is invalid for that type.
- CobjectList is not a recognized parameter type in the pipeline schema; the generic type for structured data is object.
- DThe default is a single comma-separated string, not a list, so callers could not loop over individual environment names.
-
Your team wants every new project repository in GitHub to start from the same folder layout and default files, such as the README, .gitignore, and starter configuration. Which feature lets you create a repository whose contents are copied into each newly created repository?
- AA Git submodule referencing a shared baseline repository
- BA repository marked as a template repositoryCorrect
- CA fork of an upstream repository
- DA Git subtree merged into each new repository
✓ Correct answer: BMarking a repository as a template allows developers to generate new repositories that start with the template's files, folder structure, and baseline content. This standardizes scaffolding, README files, .gitignore, and starter configuration across teams without copying manually each time.
Why the other options are wrong- AA submodule embeds a separate repository as a tracked dependency at a fixed commit; it does not scaffold a brand-new repository from a baseline.
- CA fork creates a linked server-side copy intended for contributing back to the upstream, not for standardizing newly initialized project repositories.
- DA subtree merges another project's history into a subdirectory of an existing repository and is not a mechanism for bootstrapping new repositories from a standard layout.
-
Munson's Pickles and Preserves Farm is implementing role-based access control in Azure DevOps. A contractor needs to clone the code, push commits to new feature branches, and create pull requests, but must not be able to edit branch policies or delete repositories. Which built-in security group should the contractor be added to?
- AProject Collection Administrators
- BReaders
- CProject Administrators
- DContributorsCorrect
✓ Correct answer: DBy default, members of the project Contributors group can read a repository, create and contribute to pull requests, and hold Contribute, Create branch, Create tag and Manage notes, which covers pushing commits to feature branches. Delete repository and Edit policies are granted by default only to Project Administrators, so Contributors meets the requirement without administrative rights. Readers can read and take part in pull requests but cannot push commits or create branches, and both administrator groups hold far more than the contractor needs.
Why the other options are wrong- AProject Collection Administrators administer the entire organization, including every project's repositories and policies, which is far beyond what the contractor needs.
- BReaders can read and comment on pull requests, but they lack Contribute and Create branch, so they cannot push the commits a pull request needs.
- CProject Administrators hold Delete repository and Edit policies by default, which the requirement explicitly rules out.
-
You are implementing a secure supply chain for your CI/CD pipeline. You need to verify that build artifacts have not been tampered with between the build and deployment stages. Which practice should you implement?
- AScan the artifact with antivirus before the deploy stage
- BKeep the artifact in a private container with soft delete
- CReuse the same agent for build and deployment
- DSign artifacts at build and verify before deployCorrect
✓ Correct answer: DA digital signature binds the artifact's exact contents to the signer's key. Verifying the signature before deployment confirms both that the artifact came from the trusted build and that nothing in it changed in storage or transit; any change makes verification fail and the deployment stops. Microsoft's guidance for container images describes the same model: a signature added to the image is verified during deployment to show that it is from a trusted publisher and has not been modified, for example with Notation and a signing key held in Azure Key Vault.
Why the other options are wrong- AAntivirus scanning is incorrect because it looks for known malware; an artifact altered with code the scanner does not recognize still passes, so the scan does not prove the artifact is unchanged.
- BA private container with soft delete is incorrect because it limits access and lets deleted blobs be recovered, but anyone with write access can still replace the artifact, and nothing detects that it changed.
- CReusing the same agent is incorrect because it reduces transfer between machines but gives no cryptographic proof that the artifact was not modified between build and deployment.
-
A platform team publishes security-guardrails.yml in a templates repository. The template defines the whole pipeline, including a mandatory scan stage, and exposes a parameter for the build steps teams want to run. Teams should supply only those parameter values, with the template rather than their own file controlling the outer structure. How should each team's azure-pipelines.yml use the template?
- AWith a top-level extends: entry that names security-guardrails.yml@templatesCorrect
- BWith a template: entry for security-guardrails.yml@templates in its stages: list
- CWith a template: entry for security-guardrails.yml@templates in a job's steps: list
- DWith a template: entry for security-guardrails.yml@templates in its jobs: list
✓ Correct answer: ALearn says extends templates "control and define a schema for what is allowed in a pipeline" and define "logic and structure that a pipeline must follow", while includes templates insert content into a pipeline that the consuming file still shapes. The pipeline schema treats extends as its own pipeline form with no stages, jobs or steps lists of its own. To stop a team from removing the extends line itself, the platform team pairs the template with a Required template check on the protected resources.
Why the other options are wrong- BA template: entry in stages: is an includes template; the consuming file still owns its stages list and can add stages before or after the inserted ones.
- CInserting the template into steps: makes it an includes template inside a job the team defines, so the team's file, not the template, controls the structure around it.
- DA template: entry in jobs: is an includes template, which leaves the consuming file in control of the stage and of any other jobs placed next to it.
-
A team has many short-lived feature branches that are never deleted after their pull requests complete, cluttering the Azure Repos branch list. Which pull request completion option most directly reduces this clutter?
- AChoosing Set auto-complete for each pull request
- BSelecting Squash commit as the merge type when completing
- CSelecting Delete <branch name> after merging when completingCorrect
- DSelecting Complete associated work items after merging
✓ Correct answer: CThe Complete pull request pane offers post-completion options, and Delete <branch name> after merging deletes the pull request's source branch once it merges; the Azure DevOps CLI exposes the same choice as delete-source-branch. Selecting it on each completion means finished branches stop accumulating in the branch list.
Why the other options are wrong- ASet auto-complete completes and merges the pull request once it meets all required branch policies; the source branch is removed only if the delete option is also chosen.
- BSquash commit combines all source commits into a single commit on the target, but it leaves the source branch itself in place.
- DComplete associated work items after merging closes the linked work items; it does nothing to the source branch.
Who this AZ-400 practice exam is for
This practice set is for anyone preparing for the AZ-400: Azure DevOps Engineer Expert exam at the advanced level - from first-time candidates building a foundation to experienced Microsoft practitioners doing a final review before test day. If you learn best by working through realistic questions and reading why each answer is right or wrong, it is built for you.
How to use this AZ-400 practice exam
- Start with the free sample questions above to gauge your current baseline.
- Read the full explanation on every question, including why each wrong option is wrong.
- Track your weak domains and focus your study where you are losing the most marks.
- Once you are scoring consistently well, take a timed, full-length mock exam.
- Use your readiness score to decide when you are ready to book the real AZ-400 exam.
Related Microsoft resources
- AZ-400 study guideKey concepts
- Microsoft practice examsAll Microsoft
- Certification pathWhere this fits
- Certification exam guides & tipsBlog
- Plans & pricingFree & paid
- How these questions are written and reviewedMethodology
- Report a problem with a questionCorrections
- AZ-700 practice examRelated
- AZ-802 practice examRelated
- AZ-900 practice examRelated
AZ-400 practice exam FAQ
How many questions are in the AZ-400 practice exam on CertGrid?
CertGrid has 694 practice questions for AZ-400: Azure DevOps Engineer Expert, covering 5 exam domains. The real AZ-400 exam runs 100 min (120 min seat time), typically with 40-60 questions. Microsoft publishes 40-60 questions as a typical range across its exams and states the number varies by exam; it does not publish a count for this one. CertGrid's timed mock is a fixed 50 questions.
What is the passing score for AZ-400?
The AZ-400 exam passing score is 700 / 1000, and you have about 100 min to complete it. CertGrid scores your practice attempts the same way so you know when you are ready.
Are these official AZ-400 exam questions?
No. CertGrid is an independent practice platform. We do not provide real or leaked exam questions. Our questions are original and designed to help you practice the concepts, scenarios, and difficulty style of the AZ-400: Azure DevOps Engineer Expert exam.
Is there a free AZ-400 practice test?
Yes. You can take a free AZ-400: Azure DevOps Engineer Expert practice test straight away: a fixed set of 20 practice questions for this exam, retryable as often as you like, with no credit card required. You get readiness scoring and a weak-domain breakdown on those questions. Paid plans unlock the full 694-question bank, timed mock exams and full-bank domain analytics.
What CertGrid is (and is not)
CertGrid is an independent IT certification practice platform for Azure, AWS, Google, Cisco, Security, Linux, Kubernetes, Terraform, and other certification tracks. It provides objective-mapped practice questions, readiness scoring, weak-domain drills, and explanations to help learners understand what to study next.
Independent & original. CertGrid is an independent practice platform and is not affiliated with or endorsed by Microsoft. Questions are original practice items designed to mirror certification concepts and exam style. CertGrid does not provide official exam questions or braindumps.