Lesson 365 · AWS Learning Path

AWS 365: CodePipeline stages, artifacts, variables, roles, approvals, and cross-account actions

Anil Jalela · Published Jun 25, 2026 · 5 min read

Why this lesson matters

Advanced pipelines cross trust boundaries. A central tooling account may read source, build an artifact, ask humans for approval, and invoke deployment roles in staging and production accounts. Every artifact, variable, role assumption, KMS decrypt, and approval must remain tied to one execution and revision.

Stage/action contract

For each action record:

Actions sharing run order are parallel. Input artifacts must have unique names and valid producer relationships. A stage succeeds only according to its action results/conditions; runtime customer success needs separate verification.

Artifact stores and integrity

The pipeline has an artifact store in its Region; cross-Region actions require configured regional artifact stores. Use S3 access control and a customer-managed KMS key when cross-account authorization requires it. Preserve object/version/digest and restrict substitution.

Cross-account artifact movement has constraints: generally an action can consume an artifact when it is in the pipeline account, the artifact was created in the pipeline account for another-account action, or it was produced by a prior action in the same account. Design the graph rather than assuming arbitrary account-to-account passing.

KMS aliases are resolved in their owning account and are unsafe identifiers for ambiguous cross-account use; use the documented key ID/ARN approach and explicit key policy. Authorize pipeline role, target action role, S3 bucket policy, and KMS key separately.

Variables and namespaces

Action output variables become addressable through a namespace. Pipeline-level variables are a V2 feature. Define name, producer, format, allowed consumer, validation, and sensitivity.

Good variables include commit ID, build ID, artifact digest, image digest, deployment ID, and non-secret environment selector. Bad variables include passwords, tokens, private data, or an unvalidated account/role/stack name that controls authority.

Variables do not guarantee immutability. Verify that digest/ID matches the artifact actually consumed. Avoid namespace collisions and implicit defaults.

Role chain

source/event identity
 -> CodePipeline service role in tooling account
 -> per-action role (possibly target account)
 -> provider service role/execution role
 -> target resource policies and KMS/S3 authorization

Trust policy permits assumption; identity/resource/key policies permit actions. Use source-account/source-ARN or other supported confused-deputy conditions where applicable. Restrict iam:PassRole to exact provider roles and services. Never let a build role pass or assume arbitrary production roles.

Separate pipeline definition administration, source approval, artifact publishing, production approval, deployment execution, KMS administration, and audit. Include break-glass role with time-bound authorization and review.

Cross-account design sequence

1. Choose tooling and workload account ownership.
2. Create/version artifact stores and KMS keys per required Region.
3. Define target action role trust for pipeline role.
4. Grant target role only deployment operations for named resources.
5. Grant artifact read and KMS decrypt/encrypt as required.
6. Configure action roleArn, Region, provider, and artifacts.
7. Test allowed deployment and denied unrelated resource/account.
8. Correlate CloudTrail in tooling and target accounts.

The target role should validate environment/resource tags or names but not rely on tags alone when users can alter them.

Manual approval

Approval has a seven-day expiration in the standard manual approval behavior; verify current documentation and design reminders/escalation. Notification needs SNS access. Approval data must include execution, revision, artifact/image digest, target, evidence links, change/incident ID, risk, rollback boundary, and expiry without secrets.

The approver must see immutable evidence and have domain authority. The author cannot satisfy independent production approval where separation of duties is required. Approval after an artifact changes is invalid; downstream steps re-verify digest.

Reject, timeout, notification failure, unavailable approver, emergency override, and evidence-link outage all need explicit outcomes. Silence is not approval.

Conditions, retry, and rollback

V2 stage conditions can apply rules at entry/success/failure with supported results. Version and test policy code. A retry must understand whether a provider action already created a build/deployment/stack change. Prefer idempotency and status reconciliation to blind resubmission.

Stage rollback selects prior successful pipeline execution behavior where supported, but it does not reverse stateful side effects. Link CodePipeline rollback to CodeDeploy/CloudFormation/application rollback and data reconciliation.

Read-only evidence

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-action-executions --pipeline-name PIPELINE_NAME --max-results 50 --region ap-south-1

Redact names, ARNs, account IDs, artifact locations, KMS keys, commit/variables, approval links, and execution metadata.

Failure workshop

Trace 12 cases: artifact name mismatch, wrong namespace, secret variable, artifact overwritten, KMS alias resolves unexpectedly, key policy misses target role, bucket policy denies target, target trust too broad, PassRole escalation, approval applies to stale digest, notification fails, and provider changed state before retry.

For each identify exact evaluation layer, evidence in both accounts, containment, correction, rollback/data impact, and regression test.

Acceptance

Design Source, Validate, Build, Staging, Approval, Production, Verify across tooling/staging/production accounts. Submit action contracts, artifact graph/digests, variable schema, trust/permission/key/bucket policies, approval packet, CloudTrail correlation, condition/retry/rollback state model, 12 failures, cost/retention, and residual risks.

Pass requires exact revision and digest through all accounts, no secrets in variables, least-privilege role/pass-role design, KMS/S3 proof, independent approval bound to execution, denied out-of-scope test, and data-aware rollback.

Official sources

• CodePipeline action requirements
• Variables
• Manual approvals
• Cross-account pipelines
• Cross-Region actions