DOP-C02 SDLC Automation Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Create an IAM role in the target account with permissions for the pipeline service role to assume, and use that role in the deployment action.

  Why this is correct

  Create an IAM role in the target account with a trust policy that allows the CodePipeline service role in the originating account to assume it via sts:AssumeRole. Then configure the deployment action (e.g., ECS, CloudFormation, S3) to use that role's ARN so the pipeline can perform resource operations in the target account without long-lived credentials. This follows least privilege and avoids hard-coding keys, and it is the canonical pattern documented by AWS for cross-account CodePipeline deployments.

• ✗

  Create separate pipelines in each account and trigger them via SNS from a master pipeline.

  Why it's wrong here

  Creating separate pipelines in each account and triggering them via SNS fails to provide a single, unified pipeline for sequential deployments and integrated manual approvals across multiple AWS accounts. CodePipeline natively supports cross-account deployments within a *single* pipeline definition, utilising IAM roles to assume permissions in target accounts for artefact deployment and actions. Triggering via SNS is suitable for orchestrating independent, decoupled workflows or fan-out scenarios where multiple pipelines need to start concurrently or asynchronously based on an event, rather than a linear, multi-stage deployment process.

• ✗

  Use CodePipeline with cross-account actions by specifying the target account ID and region.

  Why it's wrong here

  CodePipeline does not accept a bare target account ID and region as an action parameter to magically run an action in another account. Actions execute in the account where the pipeline is created, using the pipeline's service role, unless an action explicitly specifies a different IAM role ARN that was created in the target account and trusts the pipeline's role. Merely specifying an account ID would still have the pipeline's role trying to access target resources, which will fail IAM permission checks because the service role has no cross-account grants.

• ✗

  Use a single pipeline in the management account with different stages for each account.

  Why it's wrong here

  A single pipeline in the management account cannot deploy sequentially to multiple accounts simply by adding different stages, because every stage executes under the same service role and therefore has the same AWS account context. Stages define ordering and actions; they do not change the permission boundary or the target account for resource deployment. To deploy across accounts, you must either use cross-account roles in actions (as in the correct answer) or maintain separate pipelines per account; otherwise the management account pipeline's role lacks permissions to modify resources in other accounts.

Go deeper

Related to this question