DOP-C02 Security and Compliance 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.

• ✓

  Use encrypted environment variables in CodeBuild.

  Why this is correct

  CodeBuild allows you to define environment variables that are encrypted at rest with a customer-managed or AWS-managed KMS key and are never stored in buildspec or source control. These values are decrypted automatically in the build container at runtime, so the build commands can use them without exposing plaintext in the pipeline artifacts. Because CodeBuild also supports referencing Systems Manager Parameter Store or Secrets Manager values as environment variables, this approach centralizes secret access while retaining per-environment changes.

• ✗

  Store secrets in a parameter file in the source repository.

  Why it's wrong here

  Storing secrets in a parameter file checked into the source repository violates the core tenet of keeping credentials out of version control. Every user or CI tool with repository access can read the file, and even after deleting it, the secret remains in Git history and in any forks, caches, or mirror copies. This creates a permanent credential exposure that automated scanners may detect, and there is no central way to rotate or audit usage.

• ✗

  Hardcode secrets in CloudFormation template parameters.

  Why it's wrong here

  Hardcoding secrets as CloudFormation template parameters embeds sensitive data directly in the infrastructure-as-code artifact and any change set or stack template history. Although the NoEcho property can mask parameter values from console output, it does not encrypt them at rest or prevent them from appearing in API calls or logs, and the plaintext secret remains in the template body. This tightly couples credential management to stack deployment, making rotation and least-privilege controls difficult.

• ✗

  Use S3 bucket policies to restrict access to secret files.

  Why it's wrong here

  An S3 bucket policy only defines who can perform actions against the bucket; it is an authorization control, not an encryption mechanism. If secret files are stored in S3, the object data at rest is protected only if you separately configure server-side encryption, and requests to the bucket are still subject to transport-level risks unless you enforce HTTPS. Additionally, using S3 as a secrets repository requires you to build rotation and access auditing yourself, whereas purpose-built services handle those controls natively.

• ✓

  Store secrets in AWS Secrets Manager and retrieve them during the build.

  Why this is correct

  AWS Secrets Manager provides a dedicated, encrypted store for database credentials, API keys, and other sensitive values, with automatic rotation and fine-grained IAM policies to scope who can retrieve each secret. In a CodeBuild pipeline, you can reference the secret directly using the Secrets Manager environment variable type or run `aws secretsmanager get-secret-value` in the buildspec, and the value is fetched over the AWS API using the build role's permissions. CloudTrail records every retrieval, giving an auditable trail, and rotation can happen without modifying pipeline definitions.

Go deeper

Related to this question