Lesson 355 · AWS Learning Path

AWS 355: CodePipeline

Anil Jalela · Published Jun 15, 2026 · 6 min read

Why this lesson matters

CodePipeline coordinates release actions; it does not compile code, prove tests, or make deployment safe by itself. A trustworthy pipeline preserves revision and artifact identity, separates roles, controls concurrent executions, records approvals, and makes failure/rollback ownership explicit.

This lesson designs and diagnoses a pipeline without creating one. You will understand V1/V2, stages/actions, artifacts, variables, triggers, execution modes, stage conditions, approvals, cross-account delivery, observability, and cost.

Core model

source revision -> source action -> immutable artifact
 -> build/test actions -> deploy candidate -> approval/conditions
 -> production action -> runtime validation

execution ID + revision + artifact digest + action evidence + deployment ID

A pipeline is the orchestration control plane. Providers such as CodeBuild, CloudFormation, CodeDeploy, ECS, Lambda, or third parties perform work. An action role lets CodePipeline invoke a provider; the provider's service role governs what that provider can do. Conflating them leads to excessive privilege and confusing denials.

Pipeline anatomy

Actions with the same run order can run concurrently; the next run order waits. Parallelism is not dependency discovery. Model every action's input artifact, output artifact, variable namespace, role, timeout, and acceptance.

V1 versus V2

Choose from requirements and current pricing, not “newer is always better.” V1 supports standard pipelines and action-level variables. V2 adds capabilities including pipeline-level variables, tag-based Git triggers, source revision override, queued/parallel modes, stage conditions, and stage rollback. Adding a V2-only field makes the pipeline V2 and changes its pricing model.

Create a decision table with required feature, V1/V2 support, execution frequency, expected monthly cost, operational effect, and migration test. Use the official pricing calculator/page at design time; do not embed one global price in architecture.

Execution modes

Execution mode determines what happens when a newer change arrives before the prior release finishes:

• SUPERSEDED: newer execution can supersede older work at stage boundaries; useful when only latest state matters, dangerous for ordered database/migration releases.
• QUEUED (V2): executions proceed in order; useful where each revision must deploy serially, but backlog age becomes a reliability signal.
• PARALLEL (V2): executions run independently; useful for independent ephemeral work, unsafe if they mutate one shared environment.

Mode changes have cancellation/state implications, and parallel mode has feature restrictions such as rollback-condition behavior. Write scenario tests for two commits arriving during build, approval, and deployment. State which execution must reach each environment.

Revision and artifact integrity

Record source provider, repository, exact commit/revision, trigger event ID, pipeline execution ID, source output digest, build output digest, and deployment identifier. Never deploy “latest.”

Build once and promote the same immutable artifact. If each environment rebuilds from source, dependencies, base images, and tools can differ. Encryption protects artifact confidentiality; a trusted digest and provenance connect content to a reviewed source/build.

Artifact stores need S3 access controls, KMS authorization when customer-managed keys are used, version/lifecycle/retention choices, cross-account policies, and prevention of workload-admin substitution. Pipeline variables are metadata, not a secret manager.

Triggers and duplicate executions

Events can be duplicated, delayed, filtered incorrectly, or coexist with polling/manual starts. Define branch/tag/path filters, provider connection ownership, manual start authority, and deduplication/observability. A release tag trigger needs protected immutable tags and proof of the peeled commit.

Do not let untrusted fork code enter a privileged release path. Separate validation from trusted release triggers.

Conditions, approvals, and rollback

Stage entry/on-success/on-failure conditions can evaluate rules and produce outcomes supported by the pipeline type/mode. Treat a condition as policy code: version, review, least privilege, test failure, timeout, and audit.

Manual approval needs decision scope, artifact/revision/digest, evidence links, expiration, authorized approvers, notification, and rejection behavior. Never put secrets in approval text or links. Approval means this artifact may proceed under stated evidence; it does not prove runtime health.

Stage rollback returns a stage to a prior successful execution where supported. It cannot reverse database writes, external payments, messages, or incompatible state. Define application rollback/roll-forward, data reconciliation, and decision owner separately.

IAM and cross-account flow

Trace principal transitions:

1. Event service/provider connection starts pipeline.
2. CodePipeline assumes its service role.
3. Action assumes configured role or invokes provider.
4. Provider assumes its own service role.
5. Artifact S3/KMS policies authorize each required read/write/decrypt/encrypt.
6. Target account role authorizes bounded deployment.

For cross-account delivery, establish trust, external/account conditions, artifact access, KMS key policy, and target role. The management pipeline account should not obtain unrestricted target administrator access. Test both allowed deployment and denied out-of-scope action.

Read-only inventory

With approved credentials:

aws sts get-caller-identity --output json
aws codepipeline list-pipelines --region ap-south-1 --output table
aws codepipeline get-pipeline --name PIPELINE_NAME --region ap-south-1
aws codepipeline get-pipeline-state --name PIPELINE_NAME --region ap-south-1
aws codepipeline list-pipeline-executions --pipeline-name PIPELINE_NAME --max-results 10 --region ap-south-1

Replace placeholders. Redact account IDs, role ARNs, repository names, artifact locations, variables, and execution details before sharing. get-pipeline describes a definition; get-pipeline-state is a current summary; execution/action details are needed for causality.

Observability and diagnosis

Correlate source event, pipeline execution, action execution, provider/build/deployment ID, artifact digest, and runtime release marker. Use EventBridge notifications, CloudTrail management events, provider logs, CloudWatch metrics/alarms, and application telemetry with retention and ownership.

Never retry an action until you know whether the provider partially changed state.

Design exercise

Design a two-account delivery pipeline for the AWS354 inventory package with Source, Validate, Build, Staging, Approval, Production, and Verify stages. Include:

• V1/V2 and execution-mode decision;
• exact artifacts/variables and namespaces;
• role/trust/KMS/S3 flow;
• trigger and duplicate-event handling;
• offline tests and protected live validation;
• immutable digest promotion;
• stage conditions and approval evidence;
• deployment/data rollback boundary;
• event/log/metric correlation;
• cost drivers, retention, and cleanup;
• ten failures: duplicate trigger, source outage, build timeout, secret scan fail, artifact mismatch, KMS deny, wrong account guard, stale approval, superseded release, and failed runtime verification.

Acceptance

Submit pipeline diagram, stage/action contract, artifact/provenance manifest, V1/V2 and mode ADR, IAM sequence, trigger table, condition/approval policy, rollback state machine, telemetry map, cost model, ten failure records, and residual risks.

Pass requires immutable revision-to-artifact-to-deployment linkage, least-privilege role separation, no secrets in variables, tested concurrency semantics, non-zero failure for incomplete work, and explicit data-aware rollback.

Official sources

• CodePipeline concepts
• V1 and V2 pipeline planning
• Execution modes
• Stage conditions
• CodePipeline security