AZ-400 Question 112
Single answerYou are a DevOps Engineer at Contoso. You maintain an Azure DevOps release pipeline that deploys microservices to an Azure Kubernetes Service (AKS) cluster. Leadership has mandated that no code with critical security vulnerabilities or failing code-quality checks can be deployed to production. Additionally, a compliance officer must formally sign off before the production release can proceed. You want to design a solution that automatically checks code quality (e.g., via SonarQube) and performs security scanning (e.g., via Microsoft Defender for Cloud), blocking deployments on critical findings, and then requires a manual sign-off from the compliance officer. Which configuration best meets these requirements for security and governance gates in Azure DevOps?
- A
Integrate all policy checks in the build pipeline and rely on separate triggered release pipelines for environment approvals.
- B
Configure post-deployment conditions in your production environment with release gates that fail on critical findings, followed by manual approval from the compliance officer.
- C
Use exclusively manual approvals in the QA stage to meet compliance requirements and skip automated gating in production.
- D
Implement a custom script in the build pipeline that halts the pipeline upon scanning failures and proceeds automatically if no vulnerabilities are found.
Show answer and explanation
Correct answer: B
Explanation
In Azure DevOps, quality and release gates should be configured at the environment (release) stage where you can automatically check code quality (e.g., SonarQube) and security scanning results (e.g., Microsoft Defender for Cloud). If issues are detected, the environment gate fails and the release process is halted. Once these checks pass, a manual approval from a designated role (such as a compliance officer) ensures that security and governance requirements are met before the deployment proceeds to production. Refer to Azure DevOps documentation (Manage approvals and checks in Azure Pipelines) for best practices on configuring environment gates and manual approvals.
- A. Incorrect.
Option 1 is incorrect because while integrating policy checks in the build pipeline is helpful, relying solely on a separate release trigger doesn't ensure that the production environment is gated by critical vulnerability checks and a formal sign-off in the same process.
- B. Correct.
Option 2 is correct. Configuring gates in the production environment allows Azure DevOps to automatically check for code-quality metrics and security vulnerabilities. If any critical issues are detected, the release is blocked. After these automated checks, a manual approval can be configured for the compliance officer to provide final sign-off, satisfying both security and governance mandates.
- C. Incorrect.
Option 3 is incorrect because it relies solely on manual approvals in QA. This approach does not integrate automated gating checks in production. There is no guarantee that critical vulnerabilities won't slip past QA if they are not checked and enforced automatically before production.
- D. Incorrect.
Option 4 is incorrect because it halts the pipeline at the build stage without providing an environment-level gate or a manual compliance sign-off. Simply failing the build pipeline does not incorporate the final formal approval requirement in production.