AZ-400 Configure processes and communications Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Configure a branch policy on the main branch that requires a successful build and security scan before merging, and use a single pipeline that includes the scan.

  Why it's wrong here

  This approach enforces a build and security scan via branch policy, but it fails to address the mandatory two-reviewer requirement from different teams, so the policy is incomplete. Embedding the scan inside the build validation also couples security checks with every compilation, making each pull request wait for a full scan and causing potential queue delays. Additionally, a single pipeline that runs both compile and scan is less flexible than running the scan early in the CI pipeline because the scan cannot be executed independently or on a cadence. Therefore, this option provides partial coverage but misses a critical governance requirement.

• ✓

  Integrate the security scan as a step early in the CI pipeline, and configure branch policies on the main branch to require two reviewers from different teams and a successful CI build including the scan. Document the process and use Copilot to generate commit messages that reference work items.

  Why this is correct

  This is the optimal solution because it embeds the security scan as an early CI step, ensuring vulnerabilities are detected immediately after code is pushed, and branch policies explicitly require two reviewers from different teams plus a successful pipeline run. Configuring the scan as part of the CI build avoids extra pipeline overhead and eliminates parallel wait times, while branch policies for reviewers are applied automatically on every pull request. Using Copilot to generate commit messages that reference work items enhances traceability without additional manual effort, ensuring that every change can be linked to a work item. This approach efficiently enforces both the scan and the review policy with minimal complexity.

• ✗

  Create a separate security scan pipeline triggered on pull request creation, and require its successful completion via branch policy. Then set up a separate PR policy requiring two reviewers.

  Why it's wrong here

  Creating a separate security scan pipeline triggered on pull request creation introduces unnecessary pipeline overhead and maintenance burden, as you now have two distinct pipelines to manage and monitor for each PR. While you can add multiple branch validation policies in Azure DevOps, this splits the governance across separate policies, increasing configuration drift and making it harder to audit compliance. The reviewers requirement is also enforced through a distinct PR policy, which could be combined into a single branch policy for clarity. Furthermore, the separate scan pipeline still needs to complete before merge, adding to the setup without any benefit over simply including the scan in the existing CI pipeline, which would run in the same PR context.

• ✗

  Add a manual approval gate in the release pipeline that requires the security officer to approve after the scan completes.

  Why it's wrong here

  This option places the security scan and approval gate in the release pipeline, which runs after code is merged to main, meaning vulnerabilities are not caught before the branch is updated. A manual approval gate adds a bottleneck, as the security officer must be available to approve, causing release delays and reducing automation, and it does not automatically enforce the two-reviewer policy. Since the gate is post-merge, it fails to protect the main branch from insecure code being integrated in the first place. Branch policies, not release gates, are the correct mechanism to enforce pre-merge checks and reviewer requirements in Azure Pipelines.

Go deeper

Related to this question