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.

• ✗

  Encrypt secrets with AWS KMS and store the encrypted value in the source code

  Why it's wrong here

  Storing a KMS-encrypted secret in source code is not a secure practice because the same codebase must contain a means to reference or retrieve the decryption key, and any principal with the ability to call KMS Decrypt on that key can recover the plaintext. Ciphertext committed to a repo is also permanent in history, so even if you delete it later, an attacker who gains access to the key can decrypt old commits. This approach also lacks rotation and centralized audit, and it violates the principle that secrets should be stored in a purpose-built service, not in code.

• ✓

  Store secrets in AWS Secrets Manager

  Why this is correct

  AWS Secrets Manager is the correct choice because it natively stores secrets as encrypted objects with fine-grained IAM policies, automatic rotation for both AWS and custom secrets, and direct integration with services like CodeBuild, RDS, and Lambda. The pipeline retrieves a reference to the secret at build time, so the material value never appears in source control, buildspec files, or logs. Secrets Manager also logs every retrieval via CloudTrail, enabling security auditing and immediate revocation if a secret is compromised.

• ✓

  Use IAM roles to grant the CI/CD service access to secrets

  Why this is correct

  Assuming an IAM role for the CI/CD service, such as via an OpenID Connect audit provider, allows the pipeline to obtain short-lived temporary credentials and call AWS APIs like Secrets Manager GetSecretValue without ever embedding an access key pair. This role-based access enforces least privilege, as the policy only grants access to the specific secret ARNs needed, and it ensures that any stolen token quickly expires rather than remaining valid indefinitely. It also separates the authentication of the pipeline from the secret itself, meaning a single credential is not the direct key to the secret.

• ✗

  Store secrets in plaintext in the buildspec file

  Why it's wrong here

  Storing secrets in plaintext in a buildspec file is an immediate vulnerability because the buildspec is often committed to a Git repository and copied to every build artifact, exposing the secret to any developer, third-party tool, or CI log that has access to the repository. Buildspec files are not designed as secret storage and are frequently displayed during build reviews or artifact dumping, so credential leakage is both broad and difficult to reverse. This also makes the secret permanently available in version history, and there is no rotation or access control at the secret level.

• ✗

  Pass secrets as environment variables in the build

  Why it's wrong here

  Passing secrets as environment variables in the build is risky because the plaintext value becomes visible in the build environment's process list and is inherited by all child processes, making it accessible to any script, dependency, or tool running in the same build phase. Environment variables are also commonly captured in diagnostic output, debugging commands, and third-party build plugins, leading to accidental exposure in CI/CD logs. Additionally, a malicious dependency could read these variables without needing any extra permissions, which is why secrets should be fetched just-in-time and only in the exact command that consumes them.

Go deeper

Related to this question