Google PCA Designing for Security and Compliance Practice Question

A company wants to use Binary Authorization to enforce that only images signed by their internal CI/CD pipeline can be deployed to their GKE clusters. They have set up Cloud Build to sign images. Which THREE steps are required to configure this? (Choose 3)

⚠ Common exam trap

PCA often tests the three required components of attestation-based Binary Authorization — candidates add optional hardening steps like Cloud HSM key storage or IAM role grants, mistaking them for mandatory configuration steps.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Create an attestation for each container image using Cloud Build

Option C is correct because Binary Authorization requires an attestor resource, which defines the cryptographic key pair (via Cloud KMS) and is used to verify attestations; without creating an attestor, no attestation can be validated. Option A is correct because the CI/CD pipeline (Cloud Build) must create a signed attestation for each container image after building it, proving the image was produced by the trusted pipeline. Option B is correct because a Binary Authorization policy must be configured to require attestations from that attestor for the GKE cluster, otherwise the cluster will not enforce the signature requirement. Option D is not required: signing keys can be managed in Cloud KMS, and Cloud HSM is only an optional key protection level, not a mandatory step. Option E is not required: roles/container.deployer is unrelated to Binary Authorization enforcement and does not configure attestation verification.

Answer analysis

Option-by-option breakdown

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

✓
Create an attestation for each container image using Cloud Build
Why this is correct
Cloud Build must generate a cryptographic attestation (a signed note stored in Artifact Registry) for each image, proving it passed the pipeline. Binary Authorization then verifies this attestor signature at admission time, satisfying the constraint that only CI/CD-signed images deploy to GKE.
✓
Create a Binary Authorization policy that requires attestations for the GKE cluster
Why this is correct
A Binary Authorization policy defines the attestor requirements that admission control enforces at deploy time, so it is the mechanism that actually blocks unsigned images. Without this policy, attestations signed by Cloud Build are collected but never evaluated, leaving the cluster's admission webhook permissive and the CI/CD signing constraint unenforced.
✓
Create an attestor in Binary Authorization
Why this is correct
Creating an attestor in Binary Authorization establishes the trusted authority whose cryptographic signature the admission controller verifies at deploy time. Without it, the policy has no signer identity to match against, so Cloud Build's attestations cannot satisfy the cluster's enforcement requirement.
✗
Store the signing keys in Cloud HSM
Why it's wrong here
Cloud HSM stores keys but Binary Authorization verifies signatures against public keys held in Artifact Registry or a KMS key reference; where signing keys physically reside is irrelevant to the attestor configuration. Cloud HSM would be the choice when regulation demands hardware-backed key custody for the signing operation itself.
✗
Grant the GKE service account the roles/container.deployer role
Why it's wrong here
roles/container.deployer governs deploying workloads via the Kubernetes API, not Binary Authorization attestation. Enforcement needs an attestor, a policy referencing it, and IAM permitting the attestor to verify signatures. Granting deployer would be relevant for CI pipelines pushing manifests to GKE.

Go deeper

Google PCA Designing for Security and Compliance Practice Question

Why each option matters

Option-by-option breakdown

Related to this question