Google ACE Practice Question: Your team uses Cloud Build to build and push…

Answer analysis

Option-by-option breakdown

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

• ✗

  Enable BinAuthz on the GKE cluster; Cloud Build automatically signs images when BinAuthz is enabled.

  Why it's wrong here

  Enabling Binary Authorization on a GKE cluster merely turns on admission control for the cluster; it does not alter Cloud Build's behavior. BinAuthz has no built-in integration that makes Cloud Build generate signatures. You still have to explicitly create an attestor and a Cloud KMS signing key, then inject a signing step into the build pipeline. With only BinAuthz enabled, the cluster will simply enforce the policy and block any image that does not carry a valid attestation.

• ✓

  Create a Cloud KMS key and attestor, configure Cloud Build to create attestations post-build, then set a BinAuthz policy requiring the attestation on the GKE cluster.

  Why this is correct

  The correct workflow is to provision a Cloud KMS asymmetric signing key, create a Container Analysis note, and define a Binary Authorization attestor that references both the note and the KMS key. After that, add a Cloud Build step (for example, using the `gcloud container binauthz attestations sign-and-create` command or the official attestation helper) to sign the image digest and create an attestation in Container Analysis. Finally, set the BinAuthz admission policy on the GKE cluster to require attestations from that attestor; the cluster then permits only images bearing a valid signature. This sequence maps the cryptographic trust chain to the actual enforcement point.

• ✗

  Use Artifact Registry vulnerability scanning; images that pass scanning are automatically trusted by GKE.

  Why it's wrong here

  Artifact Registry vulnerability scanning uses Artifact Analysis to list known CVEs in a container image, but that information is never translated into a Binary Authorization attestation. BinAuthz admission decisions only consult attestations from configured attestors; a scan result is not an attestor-approved signature. Even if an image has zero vulnerabilities, BinAuthz will not 'trust' it automatically unless a policy explicitly grants it an exemption. Therefore, enabling scanning has no effect on GKE's admission enforcement.

• ✗

  Add a Cloud Build step that runs `gcloud container binauthz attestations sign-and-create` without additional configuration.

  Why it's wrong here

  The `gcloud container binauthz attestations sign-and-create` command is a caller that expects fully provisioned infrastructure: a pre-created attestor, a Container Analysis note, a Cloud KMS keyring/key, and the appropriate IAM bindings. Running it in a Cloud Build step without first setting up these resources causes the command to fail when it tries to resolve the attestor or sign with the nonexistent key. Additionally, that command itself creates an attestation; it cannot create the attestor or note on your behalf. So simply adding the step to the build file is insufficient and will not produce a usable attestation.

Go deeper

Related to this question