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.

• ✗

  Include an AWS CLI command in the buildspec to update the bucket policy after the build.

  Why it's wrong here

  Running an AWS CLI command in the buildspec to modify the bucket policy is an imperative, ad-hoc approach. It requires the CodeBuild role to have s3:PutBucketPolicy permissions, is not idempotent, and can silently fail or overwrite changes if the policy document is not correctly parsed. It also bypasses version control and formal change management, making rollback and auditing difficult. CloudFormation instead declaratively manages the policy, enforcing consistency and automated rollback.

• ✓

  Use AWS CloudFormation to manage the S3 bucket and its policy, and update the stack as part of the pipeline.

  Why this is correct

  Using CloudFormation to manage the S3 bucket and its bucket policy is the recommended infrastructure-as-code practice. When the stack is updated as part of the CodePipeline execution, any policy changes are applied deterministically, with drift detection and automatic rollback on failure. This ensures the CloudFront origin access configuration and bucket policy remain in sync across every deployment, eliminating manual intervention and reducing the risk of misconfiguration.

• ✗

  Add a bucket policy statement in the S3 management console to grant CloudFront access.

  Why it's wrong here

  Manually adding a bucket policy statement in the S3 console is not automated and introduces human error. It requires someone to notice that the policy must change, then manually edit the JSON, which is error-prone and not repeatable across environments. This approach also lacks version control and rollback, so a mistyped principal or action could inadvertently lock out CloudFront or expose the bucket. In a CI/CD pipeline, such manual steps defeat the goal of fully automated, auditable deployments.

• ✗

  Use a CloudFront origin access identity (OAI) and configure it in the bucket policy.

  Why it's wrong here

  Configuring a CloudFront OAI and referencing it in the bucket policy is a valid static configuration, but it does not automate the policy update as part of the pipeline. The question specifically asks about updating the bucket policy during deployment — simply creating an OAI does not cause the pipeline to modify the policy when needed. If requirements change (e.g., switching to an origin access control or altering allowed HTTP methods), the policy must still be updated via a separate manual or automated process. CloudFormation provides that automation by tying the policy lifecycle to stack updates.

Go deeper

Related to this question