GCP Professional Data Engineer Practice Question

Your team maintains a Java Apache Beam pipeline packaged as a Dataflow Flex Template. You need to introduce CI/CD with Cloud Build so that when code is merged to the main branch it

compiles and unit-tests the code, builds a container image, pushes it to Artifact Registry, and writes a versioned Flex Template to a central Cloud Storage bucket;
automatically launches the template in the development project;
promotes exactly the same template to production only after an explicit human approval, passing prod-specific --parameters values without rebuilding the image or template. How should you design the Cloud Build implementation to satisfy these requirements with minimal duplicate work?

Create a single Cloud Build trigger on main whose build steps deploy to dev, then pause for a Cloud Build approval in the middle of the build before continuing to deploy the same template to prod.
Define two Cloud Build triggers: the first runs on main, builds and pushes the image, creates the versioned Flex Template, and launches it in the dev project; the second trigger starts only after the template version is available, requires manual approval, and then launches the same template in the prod project with prod-specific parameters.
Use Cloud Build only to package a JAR and push it to Cloud Storage; orchestrate template creation and deployments for both dev and prod in a Cloud Composer DAG, sending a manual email confirmation before the prod run.
Adopt Cloud Deploy release pipelines that rebuild the container image and Flex Template separately for dev and prod tracks, inserting a manual promotion gate for production.

Report Issue

Answer Description

Use two Cloud Build triggers that share the same repository. The first trigger fires automatically on merges to main, runs Maven tests, builds and pushes the container image, executes gcloud dataflow flex-template build to a versioned path in a shared Cloud Storage bucket, and immediately launches the template in the development project. It records the template URL (or writes a release tag/metadata file) so that it can be reused later. A second trigger starts only when that version identifier appears (for example, via a Git tag or a file-change trigger) and has the "Require approval" option enabled. After an approver clicks Approve, this build simply runs gcloud dataflow flex-template run in the production project, supplying prod-specific --parameters and referencing the previously built template. Because the image and template already exist, no rebuild is performed. This approach gives automatic dev deployment, gated prod promotion, and complete artifact re-use while staying within Cloud Build's native capabilities.

Ask Bash

Bash is our AI bot, trained to help you pass your exam. AI Generated Content may display inaccurate information, always double-check anything important.