AZ-400 - Design and Implement Build and Release Pipelines (53% of the exam) - 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.

Exam traps in Design and Implement Build and Release Pipelines

Answers that look right on this material and are not. Each one is a distractor from a different question in the AZ-400 bank for this domain.

  • A gate guarantees separation of duties by ensuring the person who triggered the run cannot be the one whose automated query approves it.

    Why it is wrong: Separation of duties between author and approver is an approval-side control, not something an automated gate evaluates, so attributing it to a gate confuses two distinct mechanisms.

  • A required reviewers check on the environment so a change manager approves each deployment after inspecting the ticket.

    Why it is wrong: A required reviewers check is plausible for change management, but it introduces a standing human approver, which the scenario explicitly rules out in favour of automated checks.

  • A required reviewer approval check on the environment, so a named on-call engineer inspects the dashboards for ten minutes and approves the run before it is allowed to continue.

    Why it is wrong: An approval check is tempting because it also pauses the run, but it requires a human decision, whereas the requirement is an automated telemetry-driven gate with nobody clicking when metrics are healthy.

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