DOP-C02 Security and Compliance Practice Question

A DevOps engineer is configuring AWS CodeBuild to build a project that requires access to an Amazon RDS database password stored in AWS Secrets Manager. The build must not expose the password in logs or environment variables. Which approach should the engineer use?

⚠ Common exam trap

The trap here is believing that marking an environment variable as sensitive in CodeBuild hides it completely, when it only masks the value in logs and still stores it in plaintext.

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

✓

Use the CodeBuild environment variable type SECRETS_MANAGER to reference the secret, and grant the service role permission to retrieve it.

CodeBuild's SECRETS_MANAGER environment variable type retrieves the secret at runtime and injects it securely, avoiding storage in the project configuration. The service role must have permission to access the secret. This approach keeps the password out of logs and static environment variables, meeting the security requirement while simplifying secret management.

Answer analysis

Option-by-option breakdown

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

✗
Store the password as a plaintext environment variable in the CodeBuild project and mark it as sensitive.
Why it's wrong here
Marking an environment variable as sensitive only masks its value in logs; it is still stored in plaintext in the project configuration and visible to anyone with access to the project. This does not meet the requirement to avoid exposing the password in environment variables. Secrets Manager integration is the secure method.
✗
Embed the password directly in the buildspec.yml file and encrypt the file with AWS KMS.
Why it's wrong here
Embedding the password in buildspec.yml, even if encrypted, exposes it to anyone who can read the file and decrypt it. CodeBuild does not automatically decrypt buildspec files. This approach is insecure and does not meet the requirement. Secrets Manager integration is the proper method.
✓
Use the CodeBuild environment variable type SECRETS_MANAGER to reference the secret, and grant the service role permission to retrieve it.
Why this is correct
CodeBuild supports a SECRETS_MANAGER environment variable type that fetches the secret value at build time and injects it as an environment variable without storing it in the project configuration. The service role must have secretsmanager:GetSecretValue permission. This satisfies the requirement to avoid exposing the password in logs or static environment variables.
✗
Store the password in an Amazon S3 bucket with server-side encryption and have the build download it.
Why it's wrong here
Downloading a password from S3 requires additional permissions and still exposes the secret to the build environment. It also lacks the auditing and rotation features of Secrets Manager. This method is more complex and less secure than using the native Secrets Manager integration in CodeBuild.

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