Exams / DOP-C02 / Study guide / Build and deployment secrets

Build and deployment secrets: DOP-C02 study notes and practice questions

What to know about Build and deployment secrets for the DOP-C02 exam, from the SDLC Automation domain (22% of the exam guide), then 1 free question to test it. Part of the DOP-C02 study guide.

Last verified October 2026 against current AWS documentation ·How we write our questions

What to know for the exam

These questions ask where a pipeline should get its secrets and how to stop them leaking.

Where secrets come from

Place	How
CodeBuild	`env: secrets-manager:` and `parameter-store:` in the buildspec, or project environment variables of type SECRETS_MANAGER or PARAMETER_STORE
ECS tasks	`secrets` in the container definition reference Secrets Manager or Parameter Store; the task execution role reads them at startup
EKS pods	Secrets Store CSI driver with the AWS provider, or External Secrets
Lambda	Read at runtime with the Parameters and Secrets extension, with caching
CloudFormation	Dynamic references such as `{{resolve:secretsmanager:prod/db:SecretString:password}}`; or `ManageMasterUserPassword` on RDS so the secret is never in the template
CodePipeline actions	Pipeline secret variables resolved from Secrets Manager

Use roles instead of keys

Pipelines and builds use IAM service roles; no access keys in variables.
External CI (such as GitHub Actions) uses OIDC federation to assume a role with short-lived credentials.
Cross-account deploys assume deployment roles in target accounts.

Keeping secrets safe

Grant secretsmanager:GetSecretValue only on the needed secret, plus kms:Decrypt on its key.
CodeBuild masks values from Secrets Manager and Parameter Store in logs, but don’t echo them.
Never write secrets into artifacts, images or templates.
Rotate secrets on a schedule; apps should re-read on authentication failure.
Scan repositories for committed secrets.

Common traps

Plaintext environment variables in the CodeBuild project or task definition.
NoEcho parameters treated as secure storage; the value still sits in the stack’s inputs. Use dynamic references.
The task role instead of the task execution role for startup secrets on ECS.

Try the 1 practice question

Practice Build and deployment secrets Take the free practice exam

Question 1

Easier ·Link to this question

A SaaS startup builds its API with an AWS CodeBuild project. The build runs unit tests that need a read-only database password, and then it pushes an image to Amazon ECR.

The password is stored in AWS Secrets Manager under a secret named prod/reporting/readonly. The developers want the password available as an environment variable during the build, without writing it into the buildspec file or into the project's environment settings in plaintext. Security also requires that the password never appear in build logs.

Which approach meets these requirements?

Choose one answer.

A. Add the password as a plaintext environment variable on the CodeBuild project, and set the variable type to Plaintext so that the build can read it without extra permissions.
B. Commit the password to the repository in a .env file, exclude that file from the Docker image, and read it in the install phase of the buildspec.
C. In the buildspec env section, add a secrets-manager entry that maps the variable name to the secret, and give the CodeBuild service role permission to read that secret.
D. Copy the password into an S3 object that the build downloads with an unsigned request, and delete the object at the end of each build.

Show the answer and explanation

Answer: C

A. Wrong: Plaintext project variables are visible to anyone who can view the project, and a build that echoes them writes the value to its logs. The requirement is to keep the password out of plaintext project settings.
B. Wrong: A password committed to source control stays in the repository history even after the file is deleted. Anyone with read access to the repository could recover it.
C. Right: Correct. CodeBuild resolves the secret at build time and exposes it as an environment variable, so the password never appears in the buildspec or the project settings. The service role needs read access to that one secret and nothing more. Learn more: Build specification reference for CodeBuild (opens in a new tab)
D. Wrong: Unsigned requests need a bucket policy that allows public reads, which exposes the password to anyone who knows the object key. Deleting the object afterward does not undo that exposure. Learn more: Blocking public access to your Amazon S3 storage (opens in a new tab)

Explanation

CodeBuild reads Secrets Manager values through the buildspec env section and exposes them as environment variables during the build. This keeps the password out of the buildspec and the project settings, and the service role needs only read access to that secret. Plaintext variables, committed files and public objects all expose the value to people who should not see it.

Study

Want more on Build and deployment secrets? The 5 full-length practice sets have 5 more Build and deployment secrets questions, 375 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets

Study Build and deployment secrets

Build specification reference for CodeBuild