Develop a security and compliance plan →mediumMultiple SelectObjective-mapped

AZ-400 Develop a security and compliance plan Practice Question

Which TWO actions should you take to ensure that only approved pipelines can deploy to production in Azure DevOps? (Choose two.)

⚠ Common exam trap

Test-takers frequently confuse branch policies (which control code merging) with deployment controls (which control release execution), leading them to incorrectly select options like limiting pipeline counts or disabling parallel jobs instead of recognizing that approval gates and branch policies are the two distinct mechanisms for securing production deployments.

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

✓

Configure a pipeline approval gate on the production environment.

Configuring a pipeline approval gate on the production environment ensures that every deployment to production requires explicit approval from designated reviewers, preventing unauthorized or unapproved pipelines from deploying. Option C is correct because setting branch policies to require a pull request before merging to the main branch enforces code review and validation, ensuring that only approved changes reach the main branch, which is typically the source for production deployments.

Answer analysis

Option-by-option breakdown

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

✗
Disable parallel jobs for the project.
Why it's wrong here
Disabling parallel jobs for the project only restricts the number of concurrent pipeline executions, which affects performance and resource utilization but does nothing to enforce a workflow approval. It is not a governance control, so it cannot satisfy the requirement for an approval step before production deployment.
✓
Configure a pipeline approval gate on the production environment.
Why this is correct
Configuring an approval gate on the production environment adds a pre-deployment check that requires designated approvers to manually review and approve the deployment before it proceeds. This directly satisfies the need for an explicit approval process, and in Azure Pipelines it can be set as an environment check.
✓
Set branch policies to require a pull request before merging to the main branch.
Why this is correct
Branch policies that require a pull request before merging to the main branch mandate code review and successful validation before changes are integrated. This is a strong source-control control, but it does not directly gate the production deployment itself; it only ensures that reviewed code is available for release.
✗
Limit the number of pipelines that can deploy from the main branch.
Why it's wrong here
Azure Pipelines does not provide a native setting to literally limit the number of pipelines that can deploy from the main branch; instead you would use permissions, protected pipelines, or approval checks. Even if you restrict pipeline runs, this action has no mechanism to enforce a manual approval step for production releases.
✗
Use a single agent pool for all pipelines.
Why it's wrong here
Using a single agent pool simply routes all pipeline jobs to the same set of machines, which has no effect on approval policies. Approvals are defined on environments or stages, and the agent pool is purely an infrastructure execution context, so this action cannot ensure an approval gate.

Go deeper

AZ-400 Develop a security and compliance plan Practice Question

Why each option matters

Option-by-option breakdown

Related to this question