Google ACE Practice Question: A team uses Cloud Build to build Docker images…

Answer analysis

Option-by-option breakdown

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

• ✗

  Pass the API key as a build substitution variable in the gcloud builds submit command

  Why it's wrong here

  Passing the API key as a build substitution variable in the 'gcloud builds submit' command exposes the secret because substitution variables are passed as command-line arguments and are visible in the shell's process list and may be captured in command history. Cloud Build does not mask substitution variables, so the literal key is recorded in the build log and visible in the Cloud Build console to anyone with log access. These variables are designed for non-sensitive values like image tags or project names, not secrets, and using them violates the principle of least privilege.

• ✓

  Reference the API key from Secret Manager using the availableSecrets field in cloudbuild.yaml

  Why this is correct

  Cloud Build's availableSecrets.secretManager field is the recommended way to reference a Secret Manager secret at build time. The secret value is fetched by Cloud Build using the build service account's IAM permissions and injected as an environment variable only into the specific build step that declares it, so it never appears in the source repository. Because the value is not written to the build config or log, this approach protects the API key while keeping the build reproducible and auditable.

• ✗

  Store the API key in a Cloud Storage bucket and download it in a build step

  Why it's wrong here

  Storing the API key in a Cloud Storage bucket and downloading it in a build step is insecure because the downloaded file remains in the build workspace and can be typed to the logs by debug commands, failed steps, or subsequent shell operations like 'cat' or 'env'. Additionally, it requires granting the Cloud Build service account broad bucket-level IAM permissions, which is less fine-grained than Secret Manager's per-secret access roles. The key is also at rest in a bucket, which may not be encrypted with the same key management controls or have built-in secret rotation, making this pattern harder to audit and safer to avoid.

• ✗

  Hardcode the API key in the cloudbuild.yaml and store it in the source repository

  Why it's wrong here

  Hardcoding the API key in cloudbuild.yaml and storing it in the source repository is a critical security anti-pattern because the key becomes part of the repository's permanent version history, exposing it to every developer or service with read access, even after the key is removed. Once the key is exposed in a repo, it must be considered compromised and rotated, and the leaked key could be used by external parties if the repository is ever made public or a clone leaks. It also means rotating the key requires modifying the source file and re-running the pipeline, instead of centrally updating the secret in Secret Manager.

Go deeper

Related to this question