4.2.2. Power Platform Pipelines
💡 First Principle: A pipeline turns "deployment" from a person's checklist into the platform's procedure: defined stages (dev → test → prod), one-click or fully automated promotion, environment-variable values collected at deploy time, and a history of who shipped what, where, when. Repeatability is the feature; the audit trail is the receipt.
Pipelines are configured centrally (a host managing which environments form which stages), then used by makers directly from where they build: pick the pipeline, deploy the solution to the next stage, supply environment-variable values and connections when prompted. Extending pipelines is where "implement and extend" in the syllabus points: deployment events can trigger additional logic — approval gates before production (the HITL pattern from 3.2.2 applied to deployment itself), validation steps, notifications — and unattended scenarios run under a service principal rather than a human account, which is the standard answer for CI/CD-grade automation.
The composition with 4.1 is the professional loop the exam wants you to see whole: build in dev → run the evaluation battery → deploy to test via pipeline → evaluate again against test's data → approval gate → prod. Testing gates shipping; shipping never outruns testing.
⚠️ Exam Trap: "Production deployments require sign-off" maps to extending the pipeline with an approval step — not to manually importing the solution on approval day. Manual import answers on pipeline questions are distractors almost by definition.
Reflection Question: Design the minimal pipeline for the AB-620 world: stages, where the evaluation battery runs, where the approval sits, and which identity performs the scheduled nightly deployment — then name the artifact that proves to an auditor what shipped last Tuesday.
