Configure processes and communications →hardMultiple ChoiceObjective-mapped

AZ-400 Manual validation task Practice Question

Your Azure DevOps pipeline deploys to multiple environments. You want to require manual approval before production deployment, but only if the deployment originated from a branch other than 'main'. How can you implement this?

⚠ Common exam trap

The trap is to use the condition `eq` instead of `ne`, which would require approval on main branches instead of non-main branches. Pre-deployment approvals (option A) are unconditional and cannot be scoped to branch conditions.

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

✓

Add a manual validation task with a condition: ne(variables['Build.SourceBranch'], 'refs/heads/main')

To require manual approval only for non-main branches, add a manual validation task to the production deployment job with a condition checking that the source branch is not main: `ne(variables['Build.SourceBranch'], 'refs/heads/main')`. This pauses the pipeline and waits for approval. Pre-deployment approvals (A) cannot be conditional on branch, and deployment groups (B) are not for manual approval. Branch policies (C) do not apply to pipeline stages.

Answer analysis

Option-by-option breakdown

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

✗
Set a pre-deployment approval on the production environment
Why it's wrong here
A pre-deployment approval on the production environment creates an unconditional gate: every deployment attempt, regardless of source branch, will pause for manual sign-off. In YAML pipelines, environment checks such as 'Approvals' are evaluated for all runs that target that environment, and you cannot embed a condition that checks Build.SourceBranch directly into the approval definition. This would over-approve or over-block deployments, failing the requirement to only require approval for non-main branches.
✗
Configure a deployment group with approval gates
Why it's wrong here
Deployment groups are designed for registering on-premises target machines and are used primarily in classic release pipelines for agent-based deployment, not for environment-level approvals. The approval gates available on deployment groups are static and cannot evaluate pipeline variables like Build.SourceBranch to conditionally trigger approval. Therefore, this approach does not satisfy the requirement of conditional approval based on the source branch.
✗
Use a branch policy that requires approval for non-main branches
Why it's wrong here
Branch policies are a repository-level mechanism that enforce review requirements on pull request merges, not on pipeline release execution. They have no influence over a YAML pipeline's stages or environment approvals after a build completes, and they cannot read Build.SourceBranch to conditionally pause a deployment. Consequently, while this may control how code enters main, it does nothing to gate deployments from non-main branches to production.
✓
Add a manual validation task with a condition: ne(variables['Build.SourceBranch'], 'refs/heads/main')
Why this is correct
Add a manual validation task with a condition: This is the correct method. However, the condition in the option uses `eq` instead of `ne`, which would trigger approval for main branches. When corrected to `ne(variables['Build.SourceBranch'], 'refs/heads/main')`, it pauses the pipeline for approval only when the source branch is not main, fulfilling the requirement.

Go deeper

AZ-400 Manual validation task Practice Question

Why each option matters

Option-by-option breakdown

Related to this question