Develop a security and compliance plan →mediumMultiple ChoiceObjective-mapped

AZ-400 Develop a security and compliance plan Practice Question

You are designing a compliance strategy for Azure DevOps pipelines that deploy to production. The company policy requires that all production deployments must be reviewed by a security lead. Additionally, the deployment must use a specific release pipeline that has been pre-approved. How should you implement this?

⚠ Common exam trap

Test-takers frequently confuse branch policies (which control code changes) with deployment approvals (which control release execution), leading them to choose Option A instead of the environment-based approval check in Option B.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Define a 'production' environment in Azure DevOps and configure an approval check that requires the security lead. Have the pipeline deploy to that environment.

Azure DevOps environments allow you to define approval checks that must be satisfied before a deployment proceeds. By creating a 'production' environment and adding a pre-deployment approval check requiring the security lead, you enforce the mandatory review. The pipeline then deploys to that environment, ensuring only the pre-approved release pipeline is used.

Answer analysis

Option-by-option breakdown

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

✗
Create a branch policy that requires the security lead to approve the pull request before merging.
Why it's wrong here
Branch policies control code changes entering a branch, not runtime deployments. Even with a security lead's PR approval, the pipeline can still deploy without a separate post-merge review, so it fails to gate the actual production release.
✓
Define a 'production' environment in Azure DevOps and configure an approval check that requires the security lead. Have the pipeline deploy to that environment.
Why this is correct
Environment approval checks in YAML pipelines create a standardized, auditable manual gate before any deployment to the production environment. This integrates directly with pipeline runs, ensures the security lead explicitly approves each release, and provides full traceability, fulfilling the compliance requirement.
✗
Use a Classic release pipeline with a pre-deployment approval gate for the production stage.
Why it's wrong here
While Classic release pipelines do support pre-deployment approvals, Microsoft recommends YAML-based pipelines for new projects and they lack the same level of integration with modern features like environment checks and multi-stage YAML. Using a legacy pipeline would not align with current Azure DevOps best practices for compliance.
✗
Store the approved pipeline definition in a variable group and reference it in all pipelines.
Why it's wrong here
Variable groups in Azure DevOps are key-value stores used for configuration, not for enforcing workflow controls. Storing pipeline definitions in a variable group doesn't create any mandatory approval check, and pipelines referencing it can still run without a security review or deployment gate.

Visual reference

Go deeper

AZ-400 Develop a security and compliance plan Practice Question

Why each option matters

Option-by-option breakdown

Related to this question