Deployment Pipeline Design and Orchestration
This domain covers how the pipeline itself is structured: stage ordering, parallelism, gates, pipeline-as-code, and traceability. The exam asks you to reason about feedback latency and where verification belongs, not to memorise a specific CI product's syntax.
Ordering by cost and likelihood
Put the cheapest, most-likely-to-fail checks first: compile and lint, unit tests, contract tests, package, deploy to an ephemeral environment, acceptance/E2E, non-functional scans (performance, security), then production. Fail fast and stop the line so a broken commit never consumes expensive resources.
Fan-out, parallelism and fan-in
Independent suites run concurrently and fan in before the next stage. Parallelism reduces wall-clock time but not risk; measure the critical path before adding runners, because sharding an 8-minute stage saves little while sharding a 90-minute stage is transformative.
Pipeline as code
Jenkinsfile, .gitlab-ci.yml, Tekton, GitHub Actions workflows live in the same repository as the application and are reviewed like application code. Shared libraries or reusable templates beat copy-paste, which lets stages drift between services.
Gates, retries and traceability
A manual approval is a decision gate (ship to production, accept a risk), never a substitute for automated verification. Every run should record commit SHA, artifact digest, environment, approver and outcome. Deployment steps must be idempotent, retried with bounded backoff, and time-boxed.
Worked example
A pipeline runs 3 h 40 m. E2E runs serially for 90 min; unit tests take 4 min. Splitting E2E into six shards brings it to about 18 min and removes roughly 72 min from the critical path. Parallelising unit tests further saves 3 min. The rule: optimise the longest stage on the critical path first, and only then look at the rest.
Traps that cost marks
- Serialising every stage "to be safe", producing multi-hour feedback that developers route around.
- Re-running a whole pipeline after a flaky failure instead of quarantining and fixing the test.
- Placing approvals before checks that would have caught the defect automatically.
- Letting hotfix branches skip stages - exactly the path where risk concentrates.
- Pipelines defined by hand in a UI, so the definition is neither reviewed nor versioned.