AZ-400 Develop a security and compliance plan 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.

• ✗

  Code scanning alerts in GitHub

  Why it's wrong here

  Code scanning alerts in GitHub (such as CodeQL) are tightly integrated with GitHub repositories and pull requests, but they do not extend to Azure Pipelines or Azure Repos. Even if you run a security scan in your pipeline, the alerts themselves are stored and displayed in GitHub's UI, not in Azure DevOps. To gate a merge in Azure Repos, you would need a status check reported by an Azure Pipelines build, not an alert from a separate GitHub feature. Therefore, this option cannot enforce the desired security scan before merging in an Azure Pipelines-based workflow.

• ✗

  Azure Policy for Pipelines

  Why it's wrong here

  Azure Policy is a governance service that evaluates compliance of Azure resources (e.g., VMs, storage accounts, subscriptions) against policy definitions at resource management time. Pipeline runs, builds, and PR validations are not Azure resources; they are ephemeral executions that Azure Policy cannot audit or gate. Even if you assign a policy that requires certain capabilities, it won't block a pull request or affect pipeline execution. Thus, Azure Policy is not a valid mechanism for enforcing a security scan as a merge condition.

• ✓

  Branch protection rule with required status check

  Why this is correct

  In Azure Repos, branch protection rules (often called branch policies) allow you to require that a specific status check succeeds before a pull request can be merged. You can create a pipeline that runs your security scan on PRs and publishes a status named 'security-scan,' then configure the branch policy to require that check. This creates a hard enforcement gate: merges are blocked until the status check passes, ensuring only scanned code is merged into the protected branch. This is the correct approach for integrating a security scan into the merge workflow.

• ✗

  Pipeline security gate

  Why it's wrong here

  While Azure Pipelines offers 'approvals and gates' for release stages, these gates operate before or after a deployment stage and evaluate conditions like work items, or call external APIs—they are not merge-time checks on branches. There is no built-in feature called a 'pipeline security gate' that runs as a pull request policy; the native way to enforce a check on PRs is a branch policy with a required status check. Confusing release gates with PR gates is a common error, but the former cannot control code merging in a branch. Therefore, this option does not exist as a practical security mechanism.

Go deeper

Related to this question