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.

• ✗

  Configure the S3 bucket to allow public access

  Why it's wrong here

  Configuring the S3 bucket for public access does not address the pipeline's inability to upload artifacts because the deploy stage uses the pipeline service role's identity, not bucket-level ACLs. Even if the bucket becomes publicly readable, the CodePipeline service role still lacks the required s3:PutObject permission to write deployment output. Additionally, enabling public access is a security risk, especially when the bucket may contain intermediate artifacts or unprocessed content, and it does not fix the underlying IAM authorization failure.

• ✓

  Add 's3:PutObject' permission to the CodePipeline service role

  Why this is correct

  The deploy stage of CodePipeline assumes the CodePipeline service role when it interacts with S3, so that role must have an IAM policy allowing s3:PutObject on the target bucket. This permission enables the pipeline to upload the artifact archive and any extracted files to the bucket that hosts the static website. Without it, the deploy action fails with a permissions error even if other roles, such as CodeBuild's, happen to have access to the same bucket.

• ✗

  Add an S3 bucket policy that grants the CodeBuild service role s3:PutObject access

  Why it's wrong here

  CodeBuild's service role is used during the build stage to run commands and produce output artifacts, but the subsequent deploy stage is executed by the CodePipeline service role, not by CodeBuild. Adding an S3 bucket policy that grants s3:PutObject to the CodeBuild role has no effect on the deployment because CodeBuild does not make the deploy-time call to S3. The failure occurs because the CodePipeline role lacks the required permission, so the bucket policy should instead be written to authorize the pipeline role or, more commonly, an IAM policy should be attached to the pipeline role.

• ✗

  Verify that the CodeCommit repository has the correct permissions for the pipeline

  Why it's wrong here

  Since the source stage succeeded and pulled the code from CodeCommit, the pipeline already has the necessary CodeCommit read permissions, and any repository-level access controls are satisfied. The error is occurring in the deploy stage, where the pipeline attempts to write to S3, so checking CodeCommit permissions is a misdiagnosis. Verifying CodeCommit would only be relevant if the source stage had failed, but the pipeline has already moved past it, indicating the issue lies squarely with S3 write access.

Go deeper

Related to this question