GCP Professional Data Engineer Practice Question

Your data engineering team stores Apache Beam code in Cloud Source Repositories and deploys the pipelines as Dataflow Flex Templates. You need a CI/CD workflow that satisfies these constraints:

A push to any feature branch must run unit tests but must not publish a template.
A merge to the main branch must build a container image, generate the Flex Template JSON spec, and upload the spec to a version‐stamped folder in a Cloud Storage bucket in the dev project.
Tagging a commit with the prefix prod- must promote exactly the same template artifact from the dev bucket to the production bucket without rebuilding the image or template.

Which Cloud Build design will meet all of the requirements while keeping artifacts immutable between environments?

Define three Cloud Build triggers (feature, main, prod) that all invoke the same cloudbuild.yaml. Each trigger always rebuilds the container image and template, but the prod trigger includes a manual approval step before the rebuild executes.
Define two Cloud Build triggers:
- A branch trigger matching ^main$ that builds the container image, generates the Flex Template spec, and uploads the spec to a commit-SHA folder in the dev bucket.
- A tag trigger matching ^prod-.*$ that retrieves the previously generated spec from the dev bucket and copies it unchanged to the prod bucket, without running any build steps that re-create the image or template.
Create one tag trigger that fires on tags beginning with prod-, rebuilds the container image and template, and uploads the artifacts to both the dev and prod buckets; run unit tests for feature branches using GitHub Actions outside Cloud Build.
Create a single Cloud Build trigger that fires on every branch. Use conditional logic inside cloudbuild.yaml to decide whether to publish to the dev or prod bucket, rebuilding the container image and template each time.

Report Issue

Answer Description

Using two Cloud Build triggers - one branch trigger for main and one tag trigger for prod-* - cleanly separates concerns and preserves immutability.

The main branch trigger executes cloudbuild.yaml steps that build the container image, create the Flex Template JSON spec, and upload both artifacts to a versioned (e.g., commit SHA) path in the dev Cloud Storage bucket. Feature-branch pushes are ignored by this trigger, so only unit-test‐only workflows run for those branches.
The prod- tag trigger runs a different cloudbuild.yaml (or the same file with conditional steps). It retrieves the already-built JSON spec and, if desired, the container image reference whose tag equals the commit SHA, then copies the spec to the production bucket (and optionally promotes the container image tag) without rebuilding anything. Because the prod trigger only moves immutable artifacts, the template used in production is byte-for-byte identical to what was validated in dev.
Alternatives that rebuild the image or template during the promotion step break immutability, while designs that rely on a single trigger or a manual approval step still rebuild artifacts or fail to satisfy the "feature-branch test only" constraint.

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.