AZ-400 - Design and Implement Build and Release Pipelines - Section 3.9

Design and implement checks and approvals using YAML-based environments.

Configure YAML environments with approvals and checks to gate deployment jobs before they target production or staging resources, and use manual validation steps to insert human sign-off into automated pipelines. Understand how environment resources track deployment history and how checks differ from classic release gate queries.

YAML environmentsapprovals and checksdeployment jobsenvironment resourcesmanual validation

Practice question for this objective

Free sampleDesign and Implement Build and Release Pipelinesmedium

A multi-stage YAML pipeline in "Azure Pipelines" has a deployment job that targets a "production" environment. The release manager must personally sign off before any deployment to production proceeds, and this gate must apply to every pipeline that deploys there. Where should the sign-off requirement be configured so it always applies?

jobs:
  - deployment: DeployProd
    environment: production
    strategy:
      runOnce:
        deploy:
          steps:
  • AAdd a manual validation task as the first step of the deploy hook, so the deployment job pauses in the agent until the release manager resumes it from the pipeline run view.
  • BAdd a branch policy that requires the release manager as a reviewer on the main branch, so the pull request gate forces their sign-off before any code can deploy to production.
  • CAdd an approvals check to the "production" environment resource and name the release manager as an approver, so any deployment job targeting that environment waits for their sign-off. Correct
  • DAdd a "condition" expression on the deployment job that checks a manually set variable, so the job runs only after the release manager toggles that variable for the run.
Place a required human sign-off on an environment by adding an approvals check to the environment resource, not in per-pipeline YAML. Approvals are a check attached to an environment resource in Azure Pipelines, evaluated before any deployment job that names that environment can run. Because the check lives on the shared environment rather than in one pipeline's YAML, every pipeline deploying there inherits the gate and the approval is recorded against the run.

Why A is wrong: A manual validation task pauses a single pipeline's run but lives in YAML per pipeline, so it does not centrally protect the environment for every pipeline that deploys to it.

Why B is wrong: A branch policy gates merges into a branch, not deployments to an environment, so a deployment from an already-merged commit would proceed without the release manager approving the release.

Why C is correct: An approvals check on the environment resource gates every deployment job that targets it, so the release manager's sign-off is enforced centrally for all pipelines, which is exactly the requirement.

Why D is wrong: A condition on a variable can skip a job but offers no audited human approval step and must be repeated in every pipeline, so it neither centralises nor records the sign-off.

See more AZ-400 practice questions, answers explained.

More in this domain

Back to all Design and Implement Build and Release Pipelines objectives, or the AZ-400 cert hub.

Examworthy is not affiliated with or endorsed by Microsoft. Original, blueprint-aligned practice material only.