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.
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?
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.
Keep the momentum going with these hand-picked practice scenarios
Want more questions like this?
Get a free certification question every week.