1.1 Multi-Stage & Multi-Account CodePipeline Design

AWS Certified DevOps Engineer – Professional Exam

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: CI/CD Pipeline Architecture & Source Integration

1.1 Multi-Stage & Multi-Account CodePipeline Design 1.2 CodeBuild Projects, Build Environments & Pipeline Secrets 1.3 Source Control Workflows, Webhooks & Branching Models

2 Chapter 2: Automated Testing, Test Gates & Quality Verification

2.1 Automated Unit, Integration & Acceptance Testing in Pipelines 2.2 Load Testing, Performance Benchmarking & Synthetic Canaries 2.3 Security Scanning, SAST/DAST & Approval Gates

3 Chapter 3: Artifact Management & Multi-Platform Deployment Strategies

3.1 Artifact Lifecycle Management with CodeArtifact, ECR & S3 3.2 Automated Image Baking with EC2 Image Builder 3.3 In-Place, Rolling & Immutable Deployments on EC2 3.4 Blue/Green & Canary Deployments for ECS, EKS & Lambda

4 Chapter 4: CloudFormation, CDK & Reusable IaC Components

4.1 Advanced CloudFormation: Nested Stacks, Change Sets & Custom Resources 4.2 Cross-Account & Multi-Region StackSets & Drift Detection 4.3 Modern IaC: AWS CDK, SAM & Service Catalog Governance

5 Chapter 5: Multi-Account Architecture, Organizations & Control Tower

5.1 AWS Organizations Hierarchy, OUs & Account Provisioning 5.2 Service Control Policies (SCPs) & Multi-Account Guardrails 5.3 AWS Control Tower, Account Factory & Landing Zone Automation

6 Chapter 6: Systems Manager & Large-Scale Fleet Configuration

6.1 SSM Agent, Hybrid Activation & Session Manager 6.2 Systems Manager Run Command, State Manager & Associations 6.3 Patch Manager, Parameter Store vs Secrets Manager & AppConfig

7 Chapter 7: High Availability & Multi-Region Resiliency

7.1 Designing Resilient Multi-AZ & Multi-Region Architectures 7.2 Route 53 Traffic Flow, Health Checks & DNS Failover 7.3 Data Replication: Aurora Global DB, DynamoDB Global Tables & S3 CRR

8 Chapter 8: Scalability, Auto Scaling & Disaster Recovery Automation

8.1 EC2 Auto Scaling Policies, Lifecycle Hooks & Warm Pools 8.2 Container & Serverless Scalability: ECS Capacity Providers, EKS & API Gateway 8.3 Disaster Recovery Strategies: RTO, RPO & Architecture Tiers 8.4 Automated Backup & Recovery with AWS Backup & Elastic Disaster Recovery

9 Chapter 9: CloudWatch Metrics, Agent Collection & Log Aggregation

9.1 CloudWatch Metrics, Dimensions, Metric Math & High Resolution 9.2 Unified CloudWatch Agent & Custom Metric Collection 9.3 Centralized Log Aggregation, Retention & Cross-Account Subscriptions

10 Chapter 10: Log Analysis, Dashboards & Distributed Tracing with X-Ray

10.1 CloudWatch Logs Insights, Filter Syntax & Query Optimization 10.2 CloudWatch Dashboards, Composite Alarms & Anomaly Detection 10.3 Distributed Tracing with AWS X-Ray & Service Maps

11 Chapter 11: Automated Observability & Event-Driven Monitoring

11.1 Application & Infrastructure Health Checks with Route 53 & ALB 11.2 Centralized Observability with Amazon OpenSearch & Athena 11.3 Synthetic Monitoring with CloudWatch Synthetics Canaries

12 Chapter 12: Event-Driven Incident Detection & Notification Pipelines

12.1 AWS Health, CloudTrail Events & Operational Notification 12.2 EventBridge Event Routing, Patterns & Multi-Account Buses 12.3 Asynchronous Event Processing: SNS, SQS Queues & Dead-Letter Handling

13 Chapter 13: Automated Remediation & Deployment Troubleshooting

13.1 AWS Config Managed Rules & Automated Remediation with SSM 13.2 Event-Driven Infrastructure Self-Healing with Lambda & Step Functions 13.3 Troubleshooting CI/CD Pipeline & Deployment Failures 13.4 Root Cause Analysis for Auto Scaling & Container Failures

14 Chapter 14: Identity, Access Management & Secrets at Scale

14.1 IAM Policy Evaluation Logic, NotAction & Explicit Denies 14.2 IAM Permissions Boundaries & Delegated Administration 14.3 IAM Identity Center, Cross-Account Roles & STS Session Policies 14.4 Automated Secrets Management & Secret Rotation with Secrets Manager

15 Chapter 15: Security Automation, Data Protection & Compliance Auditing

15.1 Network Security Automation: Security Groups, NACLs, Network Firewall & WAF 15.2 Cryptographic Controls & Key Management with AWS KMS & ACM 15.3 Automated Threat Detection: GuardDuty, Inspector & Security Hub 15.4 Continuous Compliance Auditing & Log Integrity with CloudTrail & Config

1.1 Multi-Stage & Multi-Account CodePipeline Design

Key Takeaways Explain This Topic AI

AWS CodePipeline organizes software releases into sequential or parallel stages (Source, Build, Test, Deploy) triggered reactively by Amazon EventBridge rules rather than legacy polling.

Cross-account deployments require hosting CodePipeline, an S3 artifact bucket, and an AWS KMS Customer Managed Key (CMK) in a central Tools/Shared-Services account; AWS-managed S3 keys (aws/s3) cannot be used across accounts.

Target account deployment actions assume dedicated IAM cross-account execution roles via roleArn, requiring mutual trust between the Tools account CodePipeline service role and target account role policies.

The centralized S3 artifact bucket policy must grant s3:GetObject*, s3:PutObject*, and s3:ListBucket permissions to target account roles, while the KMS key policy must delegate decrypt capabilities to target account principals.

Dynamic pipeline variables (#{Namespace.Variable}) extract runtime values like Git commit IDs or container image tags from upstream actions and inject them directly into downstream CloudFormation parameter overrides.

Last updated: September 2026

Core Anatomy of AWS CodePipeline

AWS CodePipeline is a fully managed continuous delivery service that automates release pipelines for fast, reliable application and infrastructure updates. CodePipeline orchestrates the workflow of code changes through distinct stages , each containing one or more actions that execute sequentially or in parallel.

Stage Progression and Action Categories

A production-grade pipeline is divided into logical stages that enforce quality gates before software reaches end users:

Source Stage : Fetches code from source control repositories (such as GitHub, Bitbucket, or AWS CodeCommit) or artifact repositories (such as Amazon S3 or Amazon ECR). Every execution begins with a source revision.

Build Stage : Compiles code, runs unit tests, analyzes code quality, and packages deployment artifacts using AWS CodeBuild or third-party build systems.

Test Stage : Executes automated integration tests, load tests, compliance checks, and synthetic canaries in an isolated pre-production environment.

Deploy Stage : Deploys artifacts to target hosting platforms, including AWS Elastic Beanstalk, Amazon ECS, AWS Fargate, AWS Lambda, Amazon EC2/on-premises via AWS CodeDeploy, or provisions infrastructure using AWS CloudFormation.

Actions inside a stage can be configured with execution order integers ( runOrder ). Actions sharing the same runOrder execute in parallel , reducing cycle time. Actions with higher runOrder values execute sequentially only after earlier actions succeed.

Execution Triggers: EventBridge vs. Polling

Historically, CodePipeline periodically polled source repositories every few minutes to detect changes. Modern AWS architectures require event-driven triggers powered by Amazon EventBridge :

Trigger Type Latency API Overhead Event Filtering Capability

EventBridge (Recommended) Near-real-time (best effort; no sub-second SLA) No scheduled polling calls Granular filtering by branch, tag, repository, and event type

Polling (Legacy) 1–5 minutes Periodic GetCommit or ListObjects API calls None; checks all branch heads periodically

When a developer pushes a commit or updates a reference, the source provider emits an event that matches an EventBridge rule. EventBridge routes the matching event to the CodePipeline API ( codepipeline:StartPipelineExecution ) without scheduled source polling. Delivery is best effort, so architecture decisions must not assume a guaranteed sub-second end-to-end latency.

Enterprise Cross-Account Pipeline Architecture

In enterprise AWS Organizations, security and governance best practices require strict boundary isolation between environments. A common topology establishes dedicated AWS accounts:

Tools / Shared Services Account (Account A - 111111111111 ) : Hosts the CodePipeline pipeline, the primary Amazon S3 artifact bucket, and the AWS KMS Customer Managed Key (CMK).

Development Account (Account B - 222222222222 ) : Hosts development application workloads and development CloudFormation stacks.

Staging / QA Account (Account C - 333333333333 ) : Hosts pre-production validation environments.

Production Account (Account D - 444444444444 ) : Hosts business-critical live production workloads.

Deploying across accounts requires a coordinated triad of permissions: IAM AssumeRole , S3 Bucket Policies , and KMS Customer Managed Key (CMK) Policies . [ Tools Account (111111111111) ]

• CodePipeline Service Role
• │
• ├─ 1. Assumes Role ──> [ Target Account (444444444444) ]
• │ CrossAccountDeployRole
• │ │
• ├─ 2. Encrypts Artifact ├─ 3. Reads & Decrypts Artifact
• ▼ ▼
• [ S3 Artifact Bucket ] <─────────── [ KMS CMK (Tools Account) ]
• (Bucket Policy Allows (Key Policy Allows
• Target Account Access) Target Account Access)
• The KMS Customer Managed Key (CMK) Requirement

Important

DOP-C02 Exam Trap : You cannot use the default AWS-managed S3 key ( aws/s3 ) for cross-account CodePipeline deployments! The key policy of an AWS-managed key cannot be modified to add cross-account permissions. You must create an AWS KMS Customer Managed Key (CMK) in the Tools account and configure its key policy to explicitly grant cryptographic operations to the target accounts.

The KMS key policy in the Tools account must grant access to the target account root principal or specific deployment roles: {

• "Version": "2012-10-17",
• "Id": "CrossAccountKmsPolicy",
• "Statement": [
• {
• "Sid": "EnableTargetAccountUsage",
• "Effect": "Allow",
• "Principal": {
• "AWS": [
• "arn:aws:iam::222222222222:root",
• "arn:aws:iam::444444444444:root"
• ]
• },
• "Action": [
• "kms:DescribeKey",
• "kms:GenerateDataKey*",
• "kms:Encrypt",
• "kms:ReEncrypt*",
• "kms:Decrypt"
• ],
• "Resource": "*"
• }
• ]
• }
• Cross-Account S3 Artifact Bucket Policy

The central S3 artifact bucket located in the Tools account must permit target account IAM roles to retrieve and upload pipeline artifacts: {

• "Version": "2012-10-17",
• "Statement": [
• {
• "Sid": "AllowCrossAccountArtifactAccess",
• "Effect": "Allow",
• "Principal": {
• "AWS": [
• "arn:aws:iam::222222222222:role/CrossAccountDeployRole",
• "arn:aws:iam::444444444444:role/CrossAccountDeployRole"
• ]
• },
• "Action": [
• "s3:GetObject*",
• "s3:PutObject*",
• "s3:ListBucket"
• ],
• "Resource": [
• "arn:aws:s3:::central-pipeline-artifacts-111111111111",
• "arn:aws:s3:::central-pipeline-artifacts-111111111111/*"
• ]
• }
• ]
• }
• Target Account IAM Deployment Role

In each target account (e.g., Production 444444444444 ), an IAM role named CrossAccountDeployRole must be created. This role has two components:

Trust Policy : Allows the Tools account CodePipeline service role to assume it via AWS Security Token Service (STS): {

• "Version": "2012-10-17",
• "Statement": [
• {
• "Effect": "Allow",
• "Principal": {
• "AWS": "arn:aws:iam::111111111111:role/CodePipelineServiceRole"
• },
• "Action": "sts:AssumeRole"
• }
• ]
• }

Permissions Policy : Grants permissions to deploy target resources (e.g., CloudFormation, ECS, Lambda) and access the Tools account S3 bucket and KMS CMK: {

• "Version": "2012-10-17",
• "Statement": [
• {
• "Sid": "ToolsAccountKmsAndS3Access",
• "Effect": "Allow",
• "Action": [
• "kms:Decrypt",
• "kms:DescribeKey",
• "s3:GetObject*",
• "s3:ListBucket"
• ],
• "Resource": [
• "arn:aws:kms:us-east-1:111111111111:key/12345678-1234-1234-1234-123456789012",
• "arn:aws:s3:::central-pipeline-artifacts-111111111111/*",
• "arn:aws:s3:::central-pipeline-artifacts-111111111111"
• ]
• },
• {
• "Sid": "LocalDeploymentPermissions",
• "Effect": "Allow",
• "Action": [
• "cloudformation:*",
• "ecs:*",
• "iam:PassRole"
• ],
• "Resource": "*"
• }
• ]
• }

In CodePipeline, the deployment action specifies roleArn: arn:aws:iam::444444444444:role/CrossAccountDeployRole . When the action executes, CodePipeline calls sts:AssumeRole , obtains temporary credentials for Account D, fetches and decrypts the artifact from Account A's S3 bucket, and executes the deployment locally in Account D.

Governance, Approvals, and Execution Controls

Enterprise release pipelines require strict operational governance before promoting code into higher environments.

Manual Approval Actions with Amazon SNS

To prevent unvalidated code from reaching production, insert a Manual Approval Action between Staging and Production stages. The action configuration connects to an Amazon SNS Topic :

Notification : CodePipeline publishes an approval request to the SNS topic, triggering email notifications, SMS alerts, or invoking a webhook (such as an AWS Lambda function posting to Slack or Microsoft Teams).

Context : The action includes CustomData (e.g., "Verify Staging smoke test results before approving release 2.4.0") and an ExternalEntityLink (e.g., linking directly to Datadog/CloudWatch staging metrics dashboards).

Authorization : The approver must have the codepipeline:PutApprovalResult IAM permission to approve or reject the transition, passing an ApprovalResult containing Status ( Approved or Rejected ) and summary notes.

Disabling and Enabling Stage Transitions

Stage transitions can be enabled or disabled dynamically without modifying the pipeline definition:

Freezing Deployments : During operational freeze windows (e.g., peak retail events or infrastructure migrations), engineers disable the transition into the Production stage and supply a human-readable reason string.

Execution Behavior : Disabling a transition does not stop currently executing actions inside a stage; it simply prevents new pipeline executions from crossing the stage boundary.

Resuming Flow : When the transition is re-enabled, the most recent execution waiting at the boundary advances automatically.

Pipeline Variables and Dynamic Parameter Overrides

CodePipeline supports Pipeline Variables that dynamically pass runtime metadata between stages without requiring intermediate S3 storage.

Declaring and Consuming Variables

Producing Variables : In an action (such as CodeBuild or Source), declare a namespace . For example, setting namespace: BuildVariables in a CodeBuild action makes all exported environment variables available under that namespace.

Default System Variables : Source actions automatically produce variables such as #{SourceVariables.CommitId} , #{SourceVariables.BranchName} , and #{SourceVariables.AuthorDate} .

Downstream Consumption : Subsequent actions reference variables using the #{Namespace.VariableName} syntax.

CloudFormation Parameter Overrides

When deploying a containerized application, CodeBuild compiles the code, tags the Docker image with the Git commit hash, and exports IMAGE_TAG . The downstream CloudFormation deployment action dynamically overrides template parameters: {

• "ActionTypeId": {
• "Category": "Deploy",
• "Owner": "AWS",
• "Provider": "CloudFormation",
• "Version": "1"
• },
• "Name": "DeployToProd",
• "Configuration": {
• "ActionMode": "CREATE_UPDATE",
• "StackName": "ProductionMicroserviceStack",
• "TemplatePath": "BuildOutput::template.yml",

"ParameterOverrides": "{\"ContainerImageTag\": \"#{BuildVariables.IMAGE_TAG}\", \"GitCommit\": \"#{SourceVariables.CommitId}\"}",

• "RoleArn": "arn:aws:iam::444444444444:role/CrossAccountDeployRole"
• },
• "InputArtifacts": [
• {
• "Name": "BuildOutput"
• }
• ],
• "RunOrder": 1
• }
• Cross-Account Troubleshooting & Watchouts

Symptom Root Cause Remediation

AccessDenied on S3 GetObject in Deploy stage S3 bucket uses default aws/s3 KMS key, or S3 bucket policy omits the target account role Switch S3 bucket encryption to a Customer Managed Key (CMK) and add target role to S3 bucket policy

KMS.AccessDeniedException during artifact download KMS CMK key policy does not delegate permissions to the target account ID Update KMS key policy in the Tools account to include target account root ARN ( arn:aws:iam::<AccountID>:root )

AssumeRole failed: Not authorized to perform sts:AssumeRole Target account deployment role trust policy does not list Tools account CodePipeline service role Update target role trust policy Principal block to include arn:aws:iam::<ToolsAccountID>:role/CodePipelineServiceRole

Pipeline fails immediately on commit EventBridge rule pattern does not match the repository or branch reference Verify EventBridge event pattern detail.referenceName matches the exact branch name (e.g., main or master )

Loading diagram... Cross-Account CodePipeline Architecture