DOP-C02 Security and Compliance Practice Question

A company uses AWS CodeBuild for CI/CD. The build project needs to access a private S3 bucket to download artifacts. What is the MOST secure way to grant access?

⚠ Common exam trap

DOP-C02 often tests whether candidates confuse 'convenient' credential storage (env vars, buildspec) with 'secure' credential storage (IAM roles), so any answer that hardcodes or stores static keys is a distractor.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Create an IAM role with read access to the bucket and attach it to the CodeBuild project.

Attaching an IAM role to the CodeBuild project allows CodeBuild to assume temporary credentials via the AWS STS service, eliminating the need to store any long-lived secrets. The role's policy can be scoped to only the specific S3 bucket and actions required, following least privilege. This is the AWS-recommended pattern for service-to-service authentication.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
Embed the access keys in the buildspec.yml file.
Why it's wrong here
Embedding access keys in buildspec.yml exposes long-lived credentials in source control and build logs, where they can be read and reused. Static keys suit external systems that cannot assume a role, but CodeBuild should use an IAM service role instead.
✓
Create an IAM role with read access to the bucket and attach it to the CodeBuild project.
Why this is correct
An IAM role attached to the CodeBuild project supplies temporary credentials scoped to the required S3 read permissions, avoiding long-lived access keys stored in buildspec or environment variables. This satisfies least-privilege access to the private bucket.
✗
Use an S3 bucket policy that grants public read access.
Why it's wrong here
A public-read bucket policy exposes the private artifacts to anyone on the internet, directly contradicting the requirement. Public buckets are appropriate only for intentionally shared static content such as website assets, never for private build artefacts.
✗
Store AWS access keys in CodeBuild environment variables.
Why it's wrong here
Long-lived access keys in environment variables are static credentials that leak through build logs and cannot be scoped to a single build, so rotation and audit become impossible. The tempting fit is simplicity for external tooling, but CodeBuild's native IAM service role supplies temporary, automatically rotated credentials.

Quick reference

AWS S3 Storage Class Comparison

Storage Class	Min Duration	Retrieval	Use Case
S3 Standard	None	Immediate	Frequently accessed data
S3 Standard-IA	30 days	Immediate	Infrequent access, rapid retrieval
S3 One Zone-IA	30 days	Immediate	Non-critical infrequent data
S3 Intelligent-Tiering	None	Immediate–hours	Unknown or changing access patterns
S3 Glacier Instant	90 days	Milliseconds	Archive with instant retrieval
S3 Glacier Flexible	90 days	Minutes–hours	Archive, flexible retrieval
S3 Glacier Deep Archive	180 days	Hours	Long-term compliance archive

Go deeper

DOP-C02 Security and Compliance Practice Question

Why each option matters

Option-by-option breakdown

AWS S3 Storage Class Comparison

Related to this question