AZ-400: Azure DevOps Engineer Expert Practice Exam

What the AZ-400 exam covers

• Configure Processes and Communications129 questions
• Design and Implement Source Control121 questions
• Design and Implement Build and Release Pipelines132 questions
• Develop a Security and Compliance Plan117 questions
• Implement an Instrumentation Strategy112 questions

Free AZ-400 sample questions

A sample of 10 questions with answers and explanations. Sign up free to practice all 611.

1. Question 1Configure Processes and Communications

   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: B

   Branch 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.
2. Question 2Configure Processes and Communications

   What type of branching strategy uses short-lived feature branches merged to main?

   • ATrunk-based developmentCorrect
   • BGitflow
   • CEnvironment branching
   • DRelease branching
   ✓ Correct answer: A

   Trunk-based development is a branching strategy where developers create short-lived feature branches from the main (trunk) branch, implement changes in isolation, and merge back to main after code review and testing. This approach emphasizes frequent integration, reduces merge conflicts through shorter branch lifetimes, and facilitates continuous integration. Feature branches typically exist for only a few days, keeping them small and focused, which accelerates code review and reduces the complexity of merging.

   Why the other options are wrong

   • BGitflow is incorrect because Gitflow uses long-lived develop and release branches alongside feature branches, creating multiple integration points and longer branch lifetimes that increase merge complexity.
   • CEnvironment branching is incorrect because this non-standard approach isolates code by deployment environment rather than features, and does not align with continuous integration principles.
   • DRelease branching is incorrect because release branching is used for managing production releases and hotfixes, not as a primary development strategy for feature work.
3. Question 3Design and Implement Source ControlSelect all that apply

   Trey Research is implementing Git hooks to enforce coding standards. Which TWO client-side Git hooks can be used to validate code before it reaches the remote repository?

   • Apre-push hook to run unit tests before pushing to remoteCorrect
   • Bpre-commit hook to run linters on staged filesCorrect
   • Cpost-receive hook to notify the CI server
   • Dpost-update hook to trigger a deployment
   ✓ Correct answer: A, B

   Both pre-commit and pre-push hooks are client-side hooks that execute locally before data reaches the remote repository. The pre-commit hook runs when developers commit staged changes and is ideal for running linters and code formatters to catch style violations immediately. The pre-push hook executes just before pushing and is perfect for running unit tests to ensure the code builds and passes basic validations. These client-side validations create a fast feedback loop that prevents broken or poorly formatted code from being pushed to the server.

   Why the other options are wrong

   • Cpost-receive hook to notify the CI server is incorrect because post-receive is a server-side hook that runs after the remote repository receives a push; it cannot prevent code from reaching the remote repository, only act on it after arrival.
   • Dpost-update hook to trigger a deployment is incorrect because post-update is a server-side hook that runs after specific refs are updated on the server; it cannot validate code before pushing to remote and is used for post-deployment actions, not pre-push validation.
4. Question 4Design and Implement Build and Release Pipelines

   You need to deploy a Helm chart to an AKS cluster from an Azure Pipeline. The pipeline should authenticate to AKS using a Kubernetes service connection. Which task should you use?

   • AKubernetesManifest@0 with the 'deploy' action
   • BHelmDeploy@0 with the 'upgrade' command and the Kubernetes service connectionCorrect
   • CKubectl@0 with a custom script that runs helm commands
   • DAzureCLI@2 running 'az aks get-credentials' followed by 'helm upgrade'
   ✓ Correct answer: B

   The HelmDeploy@0 task is specifically designed for deploying Helm charts from Azure Pipelines to Kubernetes clusters. It provides native integration with Kubernetes service connections, allowing the pipeline to authenticate securely against AKS. The upgrade command is the standard Helm operation for both installing new releases and updating existing ones, making it suitable for Helm-based deployments. This task handles the Kubernetes authentication and Helm command orchestration, abstracting away the complexity of manual kubectl and helm CLI operations.

   Why the other options are wrong

   • AKubernetesManifest@0 with the 'deploy' action is incorrect because while this task deploys manifests to AKS, it is not optimized for Helm chart deployments and does not handle Helm-specific operations like releases and upgrades.
   • CKubectl@0 with a custom script that runs helm commands is incorrect because this requires custom scripting and does not leverage the purpose-built HelmDeploy task that provides better integration and error handling.
   • DAzureCLI@2 running 'az aks get-credentials' followed by 'helm upgrade' is incorrect because this approach is more manual and does not use the native HelmDeploy task designed for this purpose.
5. Question 5Design and Implement Build and Release Pipelines

   You need to implement a pipeline strategy that prevents deploying a build to production if it has not been successfully deployed and validated in all lower environments first. Which Azure Pipelines concept enforces this?

   • APipeline caching for faster builds
   • BPipeline triggers with branch filters
   • CArtifact versioning with semantic versioning
   • DMulti-stage YAML pipeline with stage dependencies (dependsOn)Correct
   ✓ Correct answer: D

   Stage dependencies declared with dependsOn establish ordering so a stage runs only after the stages it depends on have completed successfully. By chaining Dev, then Test, then Production with dependsOn, the same build artifact must succeed in each lower environment before the production stage is allowed to start, guaranteeing the promotion path. This builds the gated progression directly into the pipeline structure. It is the Azure Pipelines concept that enforces ordered, validated promotion.

   Why the other options are wrong

   • APipeline caching speeds up builds by reusing files and has nothing to do with enforcing the order in which environments are deployed.
   • BPipeline triggers with branch filters control when a run starts based on the branch, not whether lower environments succeeded before production.
   • CArtifact semantic versioning labels builds but does not enforce that a build was validated in lower environments before reaching production.
6. Question 6Develop a Security and Compliance Plan

   Adventure Works wants to implement static application security testing (SAST) in their Azure Pipelines for a C# application. The scan results should be visible within Azure DevOps. Which approach should the DevOps engineer take?

   • AUse Azure Policy to scan source code for security vulnerabilities
   • BInstall and configure a SAST tool extension (such as SonarCloud or Microsoft Security DevOps) as a pipeline task that publishes results to Azure DevOpsCorrect
   • CConfigure Azure Sentinel to monitor the source code repository for security issues
   • DRely on code review by developers to identify all security vulnerabilities
   ✓ Correct answer: B

   Static Application Security Testing (SAST) tools analyze source code without executing it, identifying vulnerabilities like hardcoded credentials, injection flaws, and unsafe coding patterns. By installing a SAST extension in Azure Pipelines and configuring it as a task in the build pipeline, you automate security scanning for every build. Publishing results to Azure DevOps makes findings visible within the platform where developers already work, enabling them to remediate issues quickly. Tools like SonarCloud and Microsoft Security DevOps integrate seamlessly with Azure Pipelines and provide comprehensive C# analysis.

   Why the other options are wrong

   • AUse Azure Policy to scan source code for security vulnerabilities is incorrect because Azure Policy is for compliance and governance at the infrastructure level, not for source code analysis.
   • CConfigure Azure Sentinel to monitor the source code repository for security issues is incorrect because Azure Sentinel is a SIEM designed for security monitoring, not source code scanning.
   • DRely on code review by developers to identify all security vulnerabilities is incorrect because manual code review cannot reliably catch all security issues and is not a systematic approach.
7. Question 7Develop a Security and Compliance Plan

   A development team runs GitHub Actions workflows that require access to an Azure subscription to deploy resources. The workflows currently use a service principal with a client secret stored as a GitHub Actions secret. The secret expires in 30 days, and the team frequently forgets to rotate it, causing deployment failures. How should you resolve this?

   • AIncrease the client secret expiration to 24 months
   • BCreate an Azure Automation runbook that rotates the secret monthly and updates the GitHub secret via the API
   • CConfigure GitHub Actions OIDC integration with Microsoft Entra ID workload identity federation, eliminating the need for stored secrets entirelyCorrect
   • DStore the client secret in Azure Key Vault and fetch it at the start of each workflow run
   ✓ Correct answer: C

   GitHub Actions OIDC integration with Microsoft Entra ID (formerly Azure AD) enables workload identity federation, allowing GitHub Actions workflows to obtain short-lived access tokens without storing long-lived secrets. When a workflow runs, GitHub generates an OIDC token that is exchanged for an Azure access token through federated identity. This eliminates the need for a stored client secret, removing the rotation burden entirely and improving security posture. The OIDC token is short-lived and unique per workflow run, providing strong security guarantees. This approach aligns with modern zero-trust security principles and is the recommended solution for authenticating cloud workflows. Unlike other options, this provides both automatic credential management and completely eliminates stored secrets.

   Why the other options are wrong

   • AIncrease the client secret expiration to 24 months is incorrect because longer expiration windows increase the window of exposure if the secret is compromised and do not address the root problem of credential rotation.
   • BCreate an Azure Automation runbook that rotates the secret monthly is incorrect because while this helps, it is more complex and still maintains stored secrets; OIDC is simpler and more secure.
   • DStore the client secret in Azure Key Vault and fetch it at runtime is incorrect because while this is better than storing in GitHub secrets, it still requires secret rotation and is more complex than OIDC.
8. Question 8Implement an Instrumentation StrategySelect all that apply

   You are designing an instrumentation strategy for a microservices application. Which TWO telemetry types should you collect to enable effective troubleshooting of distributed transactions? (Select two.)

   • ACPU utilization metrics of the host machines only
   • BDistributed traces with correlation IDs across all servicesCorrect
   • CStructured logs with correlation context (trace ID, span ID) in each serviceCorrect
   • DDisk space utilization alerts
   ✓ Correct answer: B, C

   Both distributed traces and structured logs are essential for troubleshooting microservices transactions. Distributed traces with correlation IDs create the transaction chain showing how requests flow through services, revealing latency bottlenecks and where failures occur. Structured logs with trace and span IDs in each service provide detailed operational context (database operations, cache hits, business logic decisions) that explains why a service behaved as it did. Together, they enable engineers to reconstruct complete request flows and identify root causes in complex distributed transactions.

   Why the other options are wrong

   • ACPU utilization metrics of the host machines only is incorrect because host-level metrics show resource consumption but provide no visibility into distributed request flow or whether services succeeded or failed in completing the transaction.
   • DDisk space utilization alerts is incorrect because disk metrics measure infrastructure capacity but have no correlation with transaction execution, service failures, or request flow.
9. Question 9Design and Implement Build and Release Pipelines

   When implementing Build practices in Design and Implement Build and Release Pipelines, which approach is recommended?

   • ABack up data only when a convenient window is available
   • BConduct regular backup testing and disaster recovery drillsCorrect
   • CTest recovery procedures only after an actual incident occurs
   • DAssume the cloud provider handles all backup and recovery
   ✓ Correct answer: B

   Regular backup testing and disaster recovery drills validate that backup processes work correctly and that recovery procedures can restore systems within required timeframes. Testing identifies issues before a real disaster occurs and ensures team familiarity with recovery procedures. This proactive approach is essential for business continuity.

   Why the other options are wrong

   • ABack up data only when a convenient window is available is incorrect because convenient windows often don't exist in continuous deployment environments; backups must be scheduled consistently.
   • CTest recovery procedures only after an actual incident occurs is incorrect because discovering backup failures during real incidents results in data loss and extended downtime.
   • DAssume the cloud provider handles all backup and recovery is incorrect because while cloud providers manage infrastructure, application data backup and recovery is the application owner's responsibility.
10. Question 10Design and Implement Source ControlSelect all that apply

    A consultant is reviewing the GitFlow vs trunk-based development configuration at Contoso Ltd. Which two actions should be performed to optimize the implementation? (Choose two.)

    • Asquash mergeCorrect
    • Bcode review workflows
    • CDisable GitFlow vs trunk-based development monitoring
    • Dshallow clonesCorrect
    • Epull request policies
    ✓ Correct answer: A, D

    Squash merge reduces commit complexity in trunk-based development by consolidating feature work into single commits, improving main branch clarity and easier rollback capability. Shallow clones optimize developer experience by reducing initial clone times and disk usage, which is particularly beneficial for trunk-based workflows where developers frequently integrate into main. Both optimizations support efficient continuous delivery practices.

    Why the other options are wrong

    • BCode review workflows is incorrect because code review is important but separate from GitFlow vs trunk-based optimization decisions.
    • CDisable GitFlow vs trunk-based development monitoring is incorrect because monitoring is essential for evaluating development strategy effectiveness.
    • EPull request policies is incorrect because while related to governance, they are not specific optimizations for comparing these development models.

AZ-400 practice exam FAQ