Multi-account pipelines and deployments: DOP-C02 study notes and practice questions
What to know about Multi-account pipelines and deployments for the DOP-C02 exam, from the SDLC Automation domain (22% of the exam guide), then 2 free questions to test it. Part of the DOP-C02 study guide.
These questions ask how a pipeline in one account can deploy into others securely.
The pattern
The pipeline lives in a central tooling (CI/CD) account.
Each target account has a deployment role whose trust policy names only the tooling account (or the pipeline role), and whose permissions cover only what the deployment needs.
The pipeline’s action assumes the role in the target account (set RoleArn on the action).
For CloudFormation actions, a separate CloudFormation execution role in the target account creates the resources.
Artifacts and encryption
The artifact bucket is in the tooling account; its bucket policy grants the target account roles read access.
Artifacts must be encrypted with a customer managed KMS key whose key policy allows the target account roles, because AWS managed keys can’t be shared across accounts.
Cross-Region deployments need a bucket and key in each Region.
Other tools
CDK: bootstrap each target account with --trust for the tooling account, which creates the asset buckets and deployment roles; CDK Pipelines builds multi-account pipelines.
CloudFormation StackSets deploy the same stack to many accounts and Regions.
ECR repository policies allow pulls from other accounts.
Approval actions before production stages.
Security points
Keep production deploy permissions in the production account; developers don’t need direct access.
Use SCPs to stop accounts from removing deployment roles.
Log all role assumptions in CloudTrail.
Common traps
The default AWS managed key for cross-account artifacts.
Access keys for the target accounts stored in the pipeline.
Trusting the entire tooling account when only the pipeline role needs to assume the deployment role.
A regional bank keeps its CI/CD tooling in a shared-services account. Its payments API is deployed by an AWS CodePipeline pipeline into a separate production account, and the pipeline's artifact bucket is encrypted with a KMS key.
The first cross-account run failed at the deploy stage, because the production account's deployment role could not decrypt the input artifact. The bank's security policy forbids giving other accounts access to any key that the company does not control.
Each cross-account action must run under a role in the production account that holds only the permissions the deployment needs, and the artifact encryption must keep working across accounts.
Which change meets these requirements?
Choose one answer.
AA. Change the artifact bucket to use the AWS managed key for S3, and grant the production account's deployment role s3:GetObject on the bucket, so that the deploy stage can read the artifacts.
BB. Give the production account's deployment role kms:Decrypt on the shared-services account's AWS managed key for S3, and add that role to the key policy so that the deploy stage can read the artifacts.
CC. Replace the default artifact encryption with a customer managed KMS key whose key policy lets the production account use it, and grant the production deployment role kms:Decrypt on that key.
DD. Store the artifacts unencrypted in a separate bucket that the production account can read, and enable default SSE-S3 encryption on that bucket once the deploy stage has completed.
C. Right: Correct. Cross-account pipelines need a customer managed key whose key policy trusts the other account, and the role in that account also needs decrypt permission. The deploy stage then reads artifacts with a role limited to what it needs. Learn more: Allowing users in other accounts to use a KMS key (opens in a new tab)
A cross-account pipeline's artifacts are encrypted with a key that both accounts must use. AWS managed keys cannot be shared with another account, so the bank needs a customer managed key whose key policy and the production role's permissions both allow decryption. Unencrypted storage and edits to an AWS managed key do not meet the bank's requirements.
A university runs its student-information system in three accounts: development, test and production. A central tooling account holds the AWS CodePipeline pipeline, and the team deploys CloudFormation stacks into each target account.
The current pipeline uses one service role that has administrator access in every target account, and the security office has rejected it. Each deployment should run under a role that exists only in the account it deploys to, carrying only the permissions that the stack needs.
The team also wants a single pipeline with one approval gate before production, and no copies of the pipeline definition for each account.
Which change meets these requirements?
Choose one answer.
AA. Create a deployment role in each target account that trusts the tooling account's pipeline role, and set the role ARN of each cross-account deploy action to the matching target account role.
BB. Give the tooling account's pipeline role the AdministratorAccess managed policy, and add that role to a trust list in each target account, so that one role can deploy everywhere with fewer roles to manage.
CC. Create three pipelines, one per account, each with its own copy of the template and its own approval gate, and run them in sequence with a Lambda function that starts the next pipeline.
DD. Attach a deployment policy to each target account as a service control policy, so that the tooling account's role gains deploy rights in that account without any role being created.
B. Wrong: Administrator access is the problem the security office rejected. A shared administrator role also lets any pipeline stage change any account.
C. Wrong: This separates the roles, but the team would maintain three definitions and a Lambda chain. The request was for a single pipeline with one approval gate.
D. Wrong: Service control policies restrict permissions and do not grant them, so they cannot give the pipeline access. Access still needs a role in the target account that trusts the tooling account. Learn more: Service control policies (SCPs) (opens in a new tab)
Explanation
A cross-account CodePipeline action assumes a role in the target account, so each account keeps its own deployment role. The role's trust policy names only the tooling account, and its permissions cover only what the stack needs. Shared administrator roles and copied pipelines break the security rule or add upkeep, and service control policies restrict access without granting any.
Want more on Multi-account pipelines and deployments? The 5 full-length practice sets have 9 more Multi-account pipelines and deployments questions, 375 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets →