Your organization requires that all Copilot Studio agent deployments to the Production environment receive explicit approval from a designated stakeholder before proceeding. How do you configure this in Power Platform Pipelines?
Select an answer to reveal the explanation.
![Portrait infographic titled 'Pre-Deployment Approval Gate in Power Platform Pipelines'. Pipeline stages: Dev → Test → [APPROVAL GATE icon with stop sign] → Production. Approval gate detail: Approver: Jane Smith (stakeholder icon), Status: Pending → Approved. Notification sent via Teams (Teams icon). Approval record shows timestamp and approver name. Pipeline resumes after approval. Red/yellow stop → green go color progression. Clean governance design.](/media/microsoft/ab-620/AB-620-e3-q041.webp)
Short Explanation
Pipeline stage settings include a pre-deployment approval slot — you drop in the approver's name or group, and the pipeline automatically pauses before deploying to Production and sends them an approval request. No email hacking or manual environment locks required.
Full Explanation
Power Platform Pipelines supports pre-deployment approvals as a native stage configuration option. When you configure the Production deployment stage, you can specify one or more required approvers (individuals or AAD groups). When a deployment is triggered to that stage, the pipeline pauses, sends an approval notification to the specified approvers (via Teams or email), and waits for approval or rejection before proceeding.
Approvers receive the approval request in the Power Platform Pipeline management interface and/or via Teams notification, where they can review deployment details and approve or reject with comments.
The condition-node approach that sends an email and waits for a reply is wrong because pipelines do not have 'condition nodes' like a flow canvas. Approval gates are stage-level configuration settings.
The read-only environment approach that manually unlocks Production for each deployment is wrong because it is a clunky workaround that bypasses proper governance. It does not provide an audit trail of who approved what.
The separate Power Automate flow approach triggered by pipeline deployment events is wrong because, while Power Automate can extend pipeline behavior, a separate approval flow is unnecessary because approval gates are a native pipeline feature. Adding an external flow for approvals that already exist natively adds complexity.
Exam caveat: pre-deployment approval = pipeline stage configuration. This creates an auditable approval record. Approvers, approval status, and timestamps are logged in the pipeline run history.