Google ACE Practice Question: A team's Cloud Build pipeline must: (1) run unit…

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Define all three steps in a single `steps` list — they run sequentially by default and stop on failure

  Why this is correct

  Defining all three steps in a single `steps` list is the idiomatic Cloud Build approach because each step runs as its own container sequentially, in the order they appear. The build automatically stops at the first step that exits with a non-zero status, so a failing test prevents the build and push steps from ever executing. This implicit sequential ordering and fail-fast behavior exactly enforces the test-before-build-before-push dependency without any extra configuration.

• ✗

  Use `waitFor` with step IDs to create a dependency graph between all three steps

  Why it's wrong here

  `waitFor` is designed to declare explicit dependencies when you want steps to run in parallel or to break the default sequential order. For three steps that must run one after another, those dependencies already exist implicitly, so adding `waitFor` is redundant and adds maintenance overhead. If you included `waitFor` on every step you would essentially be re-implementing the default behavior; it doesn't change the fact that steps stop on failure, and it introduces a risk of referencing an incorrect step ID. A simple ordered list is simpler and less error-prone.

• ✗

  Define the steps in three separate cloudbuild.yaml files and chain them with Cloud Composer

  Why it's wrong here

  Chaining three separate `cloudbuild.yaml` files with Cloud Composer is a heavy-handed solution that introduces an external orchestration service where none is needed. Each build invocation runs in a separate workspace, so you would have to explicitly persist and retrieve artifacts across builds, duplicating state and adding failure points. Cloud Build steps in one file already share a `/workspace` volume, letting the test step's results and the build step's outputs remain available to the next step without any export/import. For a linear sequence, a single file is simpler, cheaper, and more reliable.

• ✗

  Set `parallel: false` at the top level of cloudbuild.yaml to enforce sequential execution

  Why it's wrong here

  There is no top-level `parallel: false` field in the `cloudbuild.yaml` schema; Cloud Build steps are sequential by default, so the field is unnecessary and would be rejected by the schema validation. If you want parallel execution, you opt in by using `waitFor` to define a dependency graph; otherwise, the engine runs steps in array order. Trying to set this non-existent property can break your build configuration, and it indicates a misunderstanding of the execution model. The correct way to enforce the desired order is simply to list the steps in order in the `steps` array.

Go deeper

Related to this question