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.

• ✗

  Generate an access key and secret key for the CodeBuild project to use in the buildspec

  Why it's wrong here

  Generating long-term IAM access keys and placing them in the CodeBuild buildspec is an anti-pattern because CodeBuild is designed to assume an IAM service role and automatically obtain temporary credentials via STS. Hard-coded access keys create a principal outside the IAM role model, introduce secrets management overhead, and violate least privilege. They are also unnecessary: CodeBuild's service role already provides the proper identity for authorizing S3 operations.

• ✓

  Add a bucket policy that explicitly allows access from the CodeBuild project's IAM role ARN

  Why this is correct

  Adding a bucket policy that explicitly grants the CodeBuild project's IAM role ARN the s3:GetObject action is a resource-based policy approach. It complements the identity-based policy attached to the role and ensures S3 evaluates the permission grant directly, which is required when the bucket account enforces resource policies or when the bucket resides in a different account. This explicit allow on the bucket side removes any dependency on implicit same-account authorization and is a secure, scoped way to permit object retrieval.

• ✗

  Configure the CodeBuild project to run in a VPC with an S3 VPC endpoint

  Why it's wrong here

  Configuring the CodeBuild project to run in a VPC with an S3 VPC endpoint only changes the network path used to reach S3—it does not grant or alter IAM permissions. S3 access from CodeBuild normally works over the public S3 service endpoint without a VPC, and the service manages the underlying network connectivity. A VPC endpoint would be relevant only if you need private network routing or are subject to a restrictive network policy, so it is not a required action for granting CodeBuild access to an S3 bucket.

• ✓

  Attach an IAM role to the CodeBuild project with s3:GetObject permissions for the bucket

  Why this is correct

  Attaching an IAM role to the CodeBuild project with a policy that allows s3:GetObject on the specific bucket is an identity-based permission. CodeBuild assumes this role at build runtime, and the temporary credentials it receives carry the permissions defined in the role's attached policies. This is the standard mechanism for granting CodeBuild access to any AWS resource, including downloading build artifacts or source code from S3, and it follows least-privilege by scoping the action and resource.

• ✗

  Make the S3 bucket publicly readable

  Why it's wrong here

  Making the S3 bucket publicly readable is both insecure and unnecessary because it exposes all objects to anyone on the internet, violating the principle of least privilege. Even for a bucket containing only build outputs, public read access removes all access control and bypasses the IAM role-based authorization that should govern sensitive or internal artifacts. The correct approach is to rely on IAM roles and resource policies so access remains attributable and auditable.

Go deeper

Related to this question