mediumMultiple ChoiceObjective-mapped
Google ACE Practice Question: Your Cloud Build pipeline needs to reference…
Your Cloud Build pipeline needs to reference environment-specific configuration: `PROJECT_ID`, `REGION`, and `IMAGE_TAG` (generated from the Git commit SHA). Where should you define these values in `cloudbuild.yaml`?
⚠ Common exam trap
Google Cloud often tests the distinction between built-in and custom substitutions, and the trap here is that candidates assume all environment-specific values must be hardcoded or stored in secrets, overlooking Cloud Build's native substitution mechanism for non-sensitive configuration.
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 built-in substitutions (`$PROJECT_ID`, `$COMMIT_SHA`) and define custom substitutions (`$_REGION`) in the trigger or `--substitutions` flag.
Cloud Build provides built-in substitutions like `$PROJECT_ID` and `$COMMIT_SHA` that automatically resolve to the current project ID and the Git commit SHA, respectively. Custom substitutions like `$_REGION` can be defined in the trigger configuration or passed via the `--substitutions` flag, allowing environment-specific values to be injected without hardcoding. This approach keeps the `cloudbuild.yaml` reusable across environments and avoids exposing sensitive or variable data in the build file.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Hardcode the values directly in each build step's `args` field.
Why it's wrong here
Hardcoding values directly in each build step's args field embeds environment-specific configuration into the pipeline definition, forcing you to maintain separate cloudbuild.yaml files for each environment or edit the file before every build. This defeats reusability and increases the risk of accidentally deploying dev configuration to production. Substitutions exist precisely to parameterize these values, so hardcoding is redundant and error-prone.
- ✓
Use built-in substitutions (`$PROJECT_ID`, `$COMMIT_SHA`) and define custom substitutions (`$_REGION`) in the trigger or `--substitutions` flag.
Why this is correct
Cloud Build provides built-in substitutions like $PROJECT_ID and $COMMIT_SHA that are automatically populated for every build, while custom substitutions such as $_REGION are defined in the trigger configuration or passed via the --substitutions flag. This allows a single cloudbuild.yaml to remain environment-agnostic, with environment-specific values injected at build runtime, enabling the same pipeline to promote across dev/staging/prod without code changes. Because these substitutions are a native Cloud Build feature, they are evaluated before each step executes, making them reliable and auditable.
- ✗
Store all values in Cloud Secret Manager and retrieve them in each build step.
Why it's wrong here
Cloud Secret Manager is intended for confidential data such as passwords, private keys, and API tokens, not for non-sensitive configuration like region names or project IDs. Retrieving all values from Secret Manager in every build step adds unnecessary latency, complexity, and cost, and requires additional IAM permissions for the build service account. Non-secret environment variables should use Cloud Build substitutions, while secrets should be referenced only in specific steps that need them.
- ✗
Use a `.env` file committed to the repository and source it in build steps.
Why it's wrong here
Committing a .env file to the repository is an anti-pattern because it mixes configuration with source code and risks leaking sensitive values like API keys or service account credentials if the repo is ever shared or made public. Sourcing .env files in build steps also requires extra shell logic and does not integrate with Cloud Build's substitution mechanism, making it harder to override values per environment or trigger. The native approach is to use built-in and custom substitutions, which are designed for this exact purpose.
Visual reference
Go deeper
Related to this question
Learn chapter
Google Cloud Platform Overview
Key term
Region
A region is a distinct geographic location where a cloud provider operates multiple data centers that are connected by low-latency networks and provide cloud services.
Key term
Cloud Build
Cloud Build is a managed service that compiles source code into deployable artifacts, often used in continuous integration and continuous delivery pipelines.
About these practice questions
This ACE question is part of Courseiva's 769-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This ACE practice question is part of Courseiva's free Google Cloud certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the ACE exam.