AZ-400 Question 114
Single answerYou are implementing an Azure DevOps release pipeline for a microservices application. The security team requires that no critical or high-severity vulnerabilities be introduced into production. You already have an automated security scanning tool integrated into your build. Which approach should you take to block the release if new critical or high-severity vulnerabilities are detected?
- A
Configure a pre-deployment gate that references your scanning tool� results and fails the pipeline if critical or high-severity vulnerabilities are found.
- B
Set a manual approval step for each release that automatically approves the deployment if the build completes successfully.
- C
Use a branch policy in Git to require reviewers to look for security issues before merging code changes.
- D
Increase your code coverage threshold in the build to ensure higher test coverage and rely on that alone to catch security issues.
Show answer and explanation
Correct answer: A
Explanation
To enforce security and governance requirements in Azure DevOps, you can configure release gates that query external or internal services for specific compliance signals before deploying to production. In this scenario, linking your deployment pipeline to the security scanning results ensures critical or high-severity vulnerabilities automatically block the release. Refer to Microsoft� official documentation on 'Release gates in Azure Pipelines' for additional implementation details: https://docs.microsoft.com/azure/devops/pipelines/release/approvals/gates.
- A. Correct.
Correct: Configuring a pre-deployment gate that checks security scan results is the recommended approach. If critical or high-severity vulnerabilities are detected, the gate will fail, preventing the release from proceeding. This ensures real-time blocking based on the latest scan results and enforces governance policies.
- B. Incorrect.
Incorrect: A manual approval step automated by a successful build does not guarantee that security vulnerabilities are caught or prevented. It relies on humans noticing issues rather than an automated scan failing the process.
- C. Incorrect.
Incorrect: While branch policies are useful for code reviews, they do not automatically block releases based on new security scans. They are not a substitute for a dedicated release gate tied to vulnerability criteria.
- D. Incorrect.
Incorrect: Code coverage improvements do not inherently address security vulnerabilities. High test coverage is beneficial for functionality and quality, but it does not substitute for a specialized security scan or release gate.