What the AZ-400 exam covers
- Configure Processes and Communications99 questions
- Design and Implement Source Control123 questions
- Design and Implement Build and Release Pipelines387 questions
- Develop a Security and Compliance Plan140 questions
- Implement an Instrumentation Strategy59 questions
Free AZ-400 practice test questions
A sample of 10 questions with answers and explanations. Sign up free to practice all 808.
-
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: BBranch policies in Azure DevOps provide a native mechanism to enforce governance rules at the source control level. By configuring a branch policy that requires work item links, Azure DevOps automatically blocks pull request completion until all linked work items are attached, ensuring traceability and maintaining project discipline without requiring custom code or external tools.
Why the other options are wrong- ACreate a custom pipeline gate that checks for work item links is incorrect because while gates can add validation, branch policies are the purpose-built Azure DevOps feature for enforcing work item requirements on pull requests.
- CConfigure a service hook to block PRs without work items is incorrect because service hooks trigger external notifications or webhooks, not enforcement mechanisms that prevent pull request completion.
- DSet up a compliance policy in Azure Policy for the DevOps organization is incorrect because Azure Policy governs Azure infrastructure resources, not Azure DevOps pull request requirements.
-
Global Manufacturing Corp. uses Git in Azure DevOps. A developer wants to combine multiple small commits into a single clean commit before merging a feature branch into main. Which Git operation should they use?
- Agit reset --mixed
- Bgit cherry-pick
- Cgit merge --squash
- Dgit rebase --interactiveCorrect
✓ Correct answer: Dgit rebase --interactive (-i) provides full control over commits during the rebase operation, allowing developers to squash, reorder, and edit commits interactively before rebasing onto the target branch. This operation flattens multiple small commits into consolidated logical units while preserving the development narrative through clear commit messages. The interactive rebase workflow is the standard Git approach for cleaning up feature branch history before merging.
Why the other options are wrong- Agit reset --mixed is incorrect because reset modifies the index and working directory but doesn't reorganize commits themselves.
- Bgit cherry-pick is incorrect because cherry-pick applies selected commits to a new branch but doesn't combine them into single commits.
- Cgit merge --squash is incorrect because while squash merge combines commits at merge time, the developer's goal is to clean the feature branch before merging, not to merge with squashing.
-
You are configuring a pipeline to deploy a containerized application to Azure Kubernetes Service (AKS). The pipeline needs to build the Docker image, push it to Azure Container Registry (ACR), and update the Kubernetes deployment. Which is the correct order of tasks?
- AkubernetesManifest deploy -> Docker build -> Docker push to ACR
- Bdocker build -> Docker push to ACR -> KubernetesManifest deploy taskCorrect
- Cdocker build -> KubernetesManifest deploy -> Docker push to ACR
- Ddocker push to ACR -> Docker build -> kubectl apply
✓ Correct answer: BContainerized AKS deployments follow a strict dependency chain. The docker build task first compiles the application into an image on the agent, the Docker push task then uploads that image to Azure Container Registry so the cluster can retrieve it, and finally the KubernetesManifest deploy task applies manifests that reference the pushed image. This ordering guarantees the image already exists in the registry before Kubernetes attempts to pull it, preventing image pull failures.
Why the other options are wrong- AkubernetesManifest deploy -> Docker build -> Docker push to ACR is incorrect because it deploys first, so Kubernetes tries to pull an image that has not yet been built or pushed to the registry, causing image pull errors.
- Cdocker build -> KubernetesManifest deploy -> Docker push to ACR is incorrect because deployment runs before the push, so the built image is not yet in the registry when Kubernetes attempts to pull it.
- Ddocker push to ACR -> Docker build -> kubectl apply is incorrect because it tries to push the image before it has been built, which is impossible since there is no image to upload.
-
You need to restrict which pipelines can use a production service connection in Azure DevOps. What should you configure?
- ASet the service connection as a secret variable to limit visibility
- BUse a different Microsoft Entra ID tenant for production service connections
- CCreate the service connection in a separate project and share it selectively
- DConfigure pipeline permissions on the service connection to authorize only specific pipelinesCorrect
✓ Correct answer: DAzure DevOps provides a feature called pipeline permissions that allows you to restrict which pipelines can use a specific service connection. By configuring these permissions, you explicitly authorize only the pipelines that need access to the production service connection, preventing unauthorized pipelines from using it. This ensures that only approved deployment pipelines can interact with production resources, reducing the risk of accidental or malicious misuse.
Why the other options are wrong- ASet the service connection as a secret variable to limit visibility is incorrect because secret variables only hide the value in logs; they do not restrict which pipelines can use the service connection.
- BUse a different Microsoft Entra ID tenant for production service connections is incorrect because using a separate tenant is a drastic measure that complicates architecture rather than providing fine-grained pipeline-level control.
- CCreate the service connection in a separate project and share it selectively is incorrect because project-level separation is coarse-grained and does not provide pipeline-specific authorization.
-
Tailwind Traders wants to implement distributed tracing across their microservices architecture to track requests as they flow through multiple services. The application uses a mix of .NET, Java, and Node.js services. What should the DevOps engineer implement?
- ANSG flow logs to monitor all traffic between services
- BService Bus message tracking used to trace between services
- CInsights using correlation IDs and the W3C Trace ContextCorrect
- DSeparate log files per service correlated by timestamp
✓ Correct answer: CDistributed tracing in Application Insights uses correlation IDs and the W3C Trace Context standard to follow a single request's journey across multiple services. When a request enters Service A (.NET), it generates a trace ID that is propagated to Service B (Java) and Service C (Node.js) through HTTP headers following the W3C standard format. Application Insights SDKs for each language automatically extract and preserve these trace IDs, creating a connected view of the entire request flow in the Application Insights Portal. This enables engineers to visualize end-to-end request flows, identify where latency is introduced, and correlate failures across service boundaries-capabilities impossible with separate log files or per-service monitoring.
Why the other options are wrong- ANetwork Security Group flow logs to monitor traffic between services is incorrect because NSG logs capture network-level traffic patterns, not application request flows or dependencies.
- BAzure Service Bus message tracking to trace requests between services is incorrect because Service Bus is a messaging system and does not automatically correlate asynchronous messages into cohesive request traces.
- DSeparate log files on each service with timestamps for manual correlation is incorrect because manual correlation is error-prone, time-consuming, and cannot handle complex request paths with parallel service calls.
-
When implementing Implement practices in Design and Implement Build and Release Pipelines, which approach is recommended?
- AAllow direct edits to production without any tracking
- BTrack changes in a spreadsheet updated manually
- CKeep only the most recent version of each configuration file
- DUse version control for all configuration and code changesCorrect
✓ Correct answer: DVersion control for all configuration and code changes in build and release pipelines ensures every change has history, authorship, and the ability to revert. This practice enables reproducibility, facilitates code reviews, and maintains compliance audit trails. Version control is the foundation of repeatable, auditable deployments.
Why the other options are wrong- AAllow direct edits to production without any tracking is incorrect because untracked changes prevent rollback, hide authorship, and violate compliance requirements.
- BTrack changes in a spreadsheet updated manually is incorrect because manual spreadsheet tracking is unreliable, lacks automation, and doesn't integrate with pipeline tooling.
- CKeep only the most recent version of each configuration file is incorrect because maintaining version history enables rollback and investigation of configuration issues.
-
An administrator at Fabrikam Inc is planning to use SonarQube code analysis. Which two of the following are requirements or features of this solution? (Choose two.)
- AAccess control for pipelinesCorrect
- BOWASP dependency check
- CAudit loggingCorrect
- DCodeQL analysis
- EAnalysis code SonarQube
✓ Correct answer: A, CSonarQube code analysis integrates into Azure DevOps pipelines where access control ensures only authorized users can modify analysis configurations and view sensitive code quality metrics. Audit logging records all SonarQube analysis executions, result changes, and policy decisions, providing compliance evidence and enabling root cause analysis of code quality issues. These controls establish governance over the analysis process and maintain an auditable record of all quality gate decisions.
Why the other options are wrong- BOWASP dependency check is incorrect because this is a separate complementary tool for dependency analysis, not a core SonarQube requirement.
- DCodeQL analysis is incorrect because CodeQL is GitHub's analysis engine, distinct from SonarQube.
- Eanalysis code SonarQube is incorrect because this is a malformed option that doesn't represent a valid feature.
-
A developer reports that after enabling commit signing, their commits in Azure Repos show as 'Unverified' even though they configured a GPG key locally. Which step is most likely missing?
- AAdding the public GPG key to their Azure DevOps / GitHub account profileCorrect
- BRunning git config --global commit.gpgsign false
- CDeleting and re-cloning the repository
- DGranting themselves Force push permission on the branch
✓ Correct answer: ACommits are signed locally with the private GPG key, but the hosting platform can only mark them Verified if it holds the matching public key associated with the committer's account. Uploading the public key to the user's profile lets the service validate the signature and the committer email, changing the status from Unverified to Verified.
Why the other options are wrong- BSetting commit.gpgsign to false disables signing entirely, which would make commits unsigned rather than verified.
- CRe-cloning the repository does not register the public key with the service and would not change the verification status.
- DForce push permission concerns branch write access and has no relationship to signature verification.
-
Two pipelines from different teams both deploy to the shared Staging environment. When both are triggered close together, the second run currently starts deploying before the first finishes, causing intermittent failures. What should you add to the environment to prevent overlapping deployments?
- AAn Exclusive lock check, which serializes runs so only one proceeds to deployment at a timeCorrect
- BA Branch control check, limiting both pipelines to deploy from the same branch
- CA Business hours check, so both pipelines can only deploy at scheduled non-overlapping times
- DA Required template check, forcing both pipelines to share one YAML template
✓ Correct answer: AThe Exclusive lock check ensures that once one run passes the check and begins deploying, any other run targeting the same environment is held pending (or canceled, depending on configuration) until the first completes, directly solving the overlapping-deployment problem. Branch control validates source branches, Business hours only restricts a time window rather than serializing runs, and Required template addresses pipeline structure.
Why the other options are wrong- BBranch control only validates which branch a run came from; it does not prevent two runs from overlapping.
- CBusiness hours restricts the allowed time window, but two runs could still start within that same window at once.
- DRequired template only enforces that pipelines extend from a shared YAML template; it has no locking behavior.
-
A pipeline needs three secrets from an Azure Key Vault. You configure a variable group linked to that Key Vault so the secrets appear as variables automatically. What must also be true for those variables to populate correctly at runtime?
- AThe service connection needs get and list permission on vault secretsCorrect
- BYou must still add an AzureKeyVault@2 task to every pipeline as well
- CThe secrets must be renamed to match reserved variable names
- DThe Key Vault must sit in the same Azure DevOps project
✓ Correct answer: AA Key Vault-linked variable group surfaces the vault's secrets as pipeline variables automatically, but only if the service connection behind that link has get and list permission on secrets, via the vault's access policy or an RBAC role assignment. No separate AzureKeyVault@2 task is needed once the group is linked, secret names need no reserved naming scheme, and Key Vault has no dependency on Azure DevOps project boundaries.
Why the other options are wrong- BA linked variable group already pulls secrets automatically; the AzureKeyVault@2 task is only needed when not using a linked group.
- CSecret names inside the vault are used as-is for the variable names; there is no reserved-name requirement to satisfy.
- DKey Vault is governed by subscription and RBAC boundaries, not by which Azure DevOps project a pipeline happens to live in.
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-900 practice examRelated
- DP-300 practice examRelated
AZ-400 practice exam FAQ
How many questions are in the AZ-400 practice exam on CertGrid?
CertGrid has 808 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 808-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.