Develop a security and compliance plan →easyMultiple ChoiceObjective-mapped

AZ-400 Develop a security and compliance plan Practice Question

You need to ensure that only approved users can deploy to production from Azure Pipelines. What should you implement?

⚠ Common exam trap

A common mix-up: candidates confuse pipeline approval gates (which are checks like monitoring or security scans) with environment-level required approvers (which are manual approval steps), leading them to select option A instead of C.

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

✓

Environment checks with required approvers

Azure Pipelines environment checks with required approvers allow you to enforce that only specific users or groups can approve deployments to a production environment. This is a native Azure DevOps feature that integrates with pipeline stages to gate deployments based on manual approval, ensuring that unauthorized users cannot trigger or approve production releases.

Answer analysis

Option-by-option breakdown

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

✗
Pipeline approval gates
Why it's wrong here
While Azure Pipelines supports automated quality gates that evaluate external signals, a generic 'pipeline approval gate' is not a distinct built-in feature for human sign-off. The term is often confused with pre-deployment approvals, but those are implemented as the Approvals check on an environment, not as a standalone gate object. Relying on an unnamed approval gate would not, by itself, enforce that only approved users can deploy to production, because gates like Azure Monitor or even the 'pre-deployment approvals' are configured specifically as environment checks, not as an independent gate control.
✗
Microsoft Entra ID Conditional Access policies
Why it's wrong here
Microsoft Entra ID Conditional Access policies operate at the authentication and session level—they evaluate signals such as user risk, device compliance, or location to either block access or require MFA when a user signs in to Azure DevOps. They do not integrate with a release pipeline's deployment stages, nor do they provide a per-deployment approval workflow that ensures only authorized personnel can authorize a release to a specific environment. Even if Conditional Access grants a user access to the organization, it cannot substitute for a human approval step inside a pipeline, because it never evaluates the deployment event itself.
✓
Environment checks with required approvers
Why this is correct
In Azure Pipelines, an environment acts as a container for deployment targets and supports checks that control entry before a job executes. Adding an Approvals check to the Production environment lets you designate specific users or groups as required approvers; when a pipeline tries to deploy to that environment, the run pauses until one of those approvers explicitly approves or rejects the deployment. This is the native, supported mechanism that ensures only approved users can authorize releases to production, and it can be combined with other checks like branch control or time windows.
✗
Branch protection rules in GitHub
Why it's wrong here
GitHub branch protection rules require pull request reviews and status checks before merging code; they do not gate the deployment of an already-built artifact to an Azure Pipelines environment and cannot enforce an approval step during release.

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