Professional Cloud DevOps Engineer
Prepare and test your skills
Prepare and test your skills
Worked example. The correct answer is already marked and every option is explained below, so there is nothing to select here. To answer questions yourself, start the free trial.
Keep the momentum going with these hand-picked practice scenarios
Want more questions like this?
Get a free certification question every week.
Last updated
Your team is building a continuous integration pipeline in Cloud Build to package and publish Python libraries to Google Cloud Artifact Registry across different deployment environments (such as staging and production).
You need to create a reusable cloudbuild.yaml configuration that dynamically targets different repository locations and names without hardcoding values, while relying on Cloud Build's default variables for the project ID.
Which configuration and submission command should you use?
Define ${_LOCATION}, ${_REPOSITORY}, and ${_PROJECT_ID} as mandatory custom substitutions in cloudbuild.yaml, and pass all three parameters in the --substitutions flag during gcloud builds submit.
Define user-defined substitutions with leading underscores (${_LOCATION} and ${_REPOSITORY}) in cloudbuild.yaml with the default $PROJECT_ID variable, and submit using --substitutions=_LOCATION="us-east1",_REPOSITORY="my-repo".
Define user-defined substitutions without underscores (${LOCATION} and ${REPOSITORY}) in cloudbuild.yaml, and submit using --substitutions=LOCATION="us-east1",REPOSITORY="my-repo".
Use container-level environment variables (env) inside the cloudbuild.yaml steps instead of substitutions, and pass variable overrides via the --build-arg flag in gcloud builds submit.
Define ${_LOCATION}, ${_REPOSITORY}, and ${_PROJECT_ID} as mandatory custom substitutions in cloudbuild.yaml, and pass all three parameters in the --substitutions flag during gcloud builds submit.
Define user-defined substitutions with leading underscores (${_LOCATION} and ${_REPOSITORY}) in cloudbuild.yaml with the default $PROJECT_ID variable, and submit using --substitutions=_LOCATION="us-east1",_REPOSITORY="my-repo".
This solution uses Cloud Build user-defined substitutions (which require a leading underscore, such as ${_LOCATION} and ${_REPOSITORY}) alongside built-in default substitutions (such as $PROJECT_ID) to parameterize the target Artifact Registry repository URL dynamically.
StudyCerts
StudyCerts${_LOCATION} and ${_REPOSITORY}, the same cloudbuild.yaml file can publish packages to different Artifact Registry repositories or regions without modifying the pipeline definition file.$PROJECT_ID with the active Google Cloud project ID running the build or executing the trigger.gcloud builds submit command specifies the parameter values using the --substitutions flag with matching leading underscores (_LOCATION="...",_REPOSITORY="...").twine directly with Artifact Registry's HTTPS repository endpoints (https://${_LOCATION}-python.pkg.dev/$PROJECT_ID/${_REPOSITORY}/).Cloud Build strictly distinguishes between default environment variables provided by the service runtime and custom variables passed by the user. Using leading underscores for custom variables ensures correct parsing during build execution.
Define user-defined substitutions without underscores (${LOCATION} and ${REPOSITORY}) in cloudbuild.yaml, and submit using --substitutions=LOCATION="us-east1",REPOSITORY="my-repo".
Use container-level environment variables (env) inside the cloudbuild.yaml steps instead of substitutions, and pass variable overrides via the --build-arg flag in gcloud builds submit.