SOA-C02 Deployment, Provisioning, and 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 CodeCommit repositories in each account and trigger builds.

  Why it's wrong here

  Using CodeCommit repositories in each account only provides isolated source control and per-repository build triggers. A build trigger fires on commit events, but it does not orchestrate a sequential release across multiple accounts, nor does it assume cross-account IAM roles for deployment. This approach creates fragmented pipelines with no central visibility, and does not address the core requirement of coordinated, permission-based cross-account deployments.

• ✗

  Use AWS CLI scripts with cross-region replication.

  Why it's wrong here

  AWS CLI scripts leveraging cross-region replication are fundamentally mismatched because cross-region replication (CRR) is an S3 feature that asynchronously copies objects between buckets, not an application deployment mechanism. Running CLI scripts manually or via cron lacks CodePipeline's integration with IAM roles, approval gates, and failure handling, and CRR does not execute code or update resources in target accounts. This mistake confuses data replication with deployment orchestration and provides no secure, auditable path across accounts.

• ✓

  Use separate CodePipeline stages with cross-account actions using IAM roles.

  Why this is correct

  Separate CodePipeline stages with cross-account actions using IAM roles is the correct architecture because CodePipeline natively supports cross-account actions by assuming a role in the target account for each stage. The pipeline in the originating account uses a source stage, then invokes a deployment action that assumes an IAM role in the destination account, allowing you to deploy the same artifact to multiple accounts sequentially or in parallel. This design enforces least privilege, keeps the pipeline state centralized while distributing execution, and meets the requirement of deploying to multiple accounts without combining resources.

• ✗

  Create a single pipeline with all deployment stages in the same account.

  Why it's wrong here

  Creating a single pipeline with all deployment stages in the same account fails the explicit requirement to deploy into multiple accounts, and it also concentrates control and resources in one security boundary. If that account is compromised, the entire deployment pipeline and all target environments are at risk, violating best practices for environment isolation and blast-radius reduction. This approach cannot assume different IAM roles per account, so it offers no real cross-account permission model and is operationally inflexible.

Go deeper

Related to this question