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.

• ✗

  Use AWS CloudFormation StackSets to deploy the stack across accounts.

  Why it's wrong here

  AWS CloudFormation StackSets manage stack resources across multiple accounts and Regions, but they are not integrated as a native CodePipeline deployment action. A pipeline can invoke StackSets via a custom action or Lambda, but the question requires a simple single-pipeline pattern; StackSets add complexity and don't natively operate as a deployment stage triggered by the pipeline. They also lack pipeline-level change approval and rollback semantics.

• ✗

  Create a separate pipeline in each account and trigger them manually.

  Why it's wrong here

  Creating a separate pipeline per account and triggering it manually fails the automation requirement and creates duplicated pipeline infrastructure to maintain. Without a central pipeline, you lose consistent delivery logic and introduce per-account drift; manual triggers are also error-prone because a deployment could be missed. A single pipeline in the management account with cross-account role assumption is the standard, repeatable pattern.

• ✓

  Use a single pipeline in the management account with IAM roles that assume cross-account roles.

  Why this is correct

  A single pipeline in the management account leverages CodePipeline's native cross-account support by assuming an IAM role in the target account for the deployment action. The pipeline uses KMS customer-managed keys to encrypt artifacts, and each target account's role restricts the pipeline to deploy only the intended stack. This centralizes visibility and approval while keeping every account's permissions scoped, making it the recommended pattern for multi-account infrastructure delivery.

• ✗

  Use an S3 bucket with cross-account access and Lambda to invoke CloudFormation.

  Why it's wrong here

  The S3-and-Lambda approach is an over-engineered workaround because CodePipeline already provides built-in cross-account deployment via dynamic IAM role assumption. This custom solution requires maintaining Lambda functions, additional S3 bucket policies, and manual KMS/artifact handling, and it bypasses CodePipeline's native stage status and approval tracking. It also introduces more failure modes and doesn't scale as predictably as the first-class pipeline role mechanism.

Go deeper

Related to this question