A team is migrating a classic release pipeline in "Azure DevOps" to a multi-stage YAML pipeline. In the classic release, each deployment stage targets a named deployment environment and gathers a pre-deployment approval before the deployment proceeds. They want the YAML pipeline to preserve those per-stage approvals when it deploys. Which YAML construct carries the approval behaviour that the classic stage approval provided?
- AA "variable group" linked to the deployment stage, which stores the approver list and gates the stage until an approver releases it.
- BA pipeline "trigger" condition on the stage that waits for an approver to push a tag before the deployment stage runs.
- CA deployment job that targets an "environment", with an approval check configured on that environment so the deployment waits for sign-off. Correct
- DA "task group" referenced by the stage that bundles the deployment steps together with the approver list as one reusable unit.
Why A is wrong: A variable group shares configuration values and holds no approval logic, so it cannot gate a deployment on a sign-off even though it is linked to a stage.
Why B is wrong: Triggers decide when a pipeline or stage starts based on events, not on human sign-off, so this is a tempting but incorrect place to put an approval.
Why C is correct: In YAML, the classic stage approval is reproduced by an approval check on an environment that a deployment job targets, so the run pauses for sign-off before deploying just as the classic stage approval did.
Why D is wrong: Task groups bundle reusable steps in classic pipelines and have no role in YAML approvals, so naming them here confuses a classic authoring aid with an approval gate.