DOP-C02 Configuration Management and IaC 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.

• ✓

  Update the CodeDeploy deployment action to use a bucket policy and disable ACLs.

  Why this is correct

  The CodePipeline S3 deployment action assumes an IAM role and, when ACLs are enabled, attempts to set a canned ACL on each object it uploads. If the bucket denies ACL operations because Object Ownership is set to BucketOwnerEnforced, deployment fails; disabling ACLs in the action and granting the deployment role permissions (s3:PutObject, s3:PutObjectAcl) via a bucket policy provides a robust, secure authorization model. This is the AWS-recommended approach because bucket policies are centrally managed and do not rely on per-object ACLs.

• ✗

  Make the S3 bucket publicly accessible to allow CodeDeploy to write objects.

  Why it's wrong here

  Making the S3 bucket publicly accessible opens the website bucket to anonymous read and, more importantly, anonymous write if you allow s3:PutObject for everyone. The CodeDeploy/CodePipeline service role cannot automatically write to a public bucket without explicit IAM authorization; public access policies only apply to anonymous principals, not to the authenticated deployment role. This removes all access control and violates least privilege, making it both insecure and an ineffective fix.

• ✗

  Add a step in CodeBuild to copy the artifacts to the S3 bucket using the AWS CLI.

  Why it's wrong here

  Adding a CodeBuild step to copy artifacts with the AWS CLI sidesteps the S3 deployment action but does not resolve the underlying authorization failure that caused the pipeline to fail. It also introduces a new requirement to attach s3:PutObject permissions to the CodeBuild service role, so you still need a policy fix, and you lose CodePipeline's built-in deployment tracking. This is a workaround that obscures the root cause, not a correction to the deployment configuration.

• ✗

  Change the Object Ownership setting to 'ObjectWriter' to enable ACLs.

  Why it's wrong here

  Changing Object Ownership to ObjectWriter enables ACLs and makes the account that uploads an object the owner, but it does not grant CodeDeploy's role any permission to bypass the missing bucket policy or ACL. It also re-enables ACLs, which are considered a legacy permission mechanism and can create confusion when cross-account uploads occur. AWS recommends keeping Object Ownership at BucketOwnerEnforced and using bucket policies instead, so this change would be a security regression without fixing the deployment action.

Go deeper

Related to this question