Cloud Digital Leader Trust and security with Google Cloud Practice Question

A security team wants to ensure that only container images built by their approved CI/CD pipeline can run in their GKE cluster. Images built outside the approved process — even by internal engineers — should be blocked. Which Google Cloud security feature enforces this?

⚠ Common exam trap

Watch out — candidates often confuse access control (IAM) with image provenance enforcement, mistakenly thinking that restricting who can create pods (Option C) is sufficient to block unauthorized images, when in reality a CI/CD service account could still deploy an unsigned image if not prevented by Binary Authorization.

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

✓

Binary Authorization — requiring cryptographic attestations for container images before they can be deployed to GKE.

Binary Authorization is the correct answer because it enforces deployment-time policy by requiring that container images have a valid cryptographic attestation (e.g., from a trusted CI/CD pipeline) before they can be scheduled on GKE. This ensures that only images built and signed by the approved process are allowed to run, blocking all others regardless of who built them.

Answer analysis

Option-by-option breakdown

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

✗
Cloud Armor — it blocks unauthorized container images at the load balancer.
Why it's wrong here
Cloud Armor protects applications at the HTTP(S) load balancer edge, filtering traffic via IP lists, geographic restrictions, and OWASP-tuned WAF rules. It has no visibility into the container image payload embedded in a Kubernetes deployment request, nor does it run as an admission controller inside GKE, so it cannot block an unauthorized image from being scheduled.
✓
Binary Authorization — requiring cryptographic attestations for container images before they can be deployed to GKE.
Why this is correct
Binary Authorization integrates with GKE admission control to require that every container image deployed carries a valid cryptographic attestation, typically issued by your CI/CD pipeline using Cloud KMS keys. If an image lacks a signed attestation, or the attestor isn't authorized, the deployment is rejected at admission time—before the pod is created. This is specifically build provenance enforcement, not vulnerability checking.
✗
Cloud IAM — restricting `container.pods.create` permission to only the CI/CD service account.
Why it's wrong here
Cloud IAM manages who can call specific Google Cloud APIs, such as the permission to create pods in a GKE cluster. Even if you scope container.pods.create to a single CI/CD service account, a compromised or misused service account could still request a pod with an arbitrary image — a manual build or an image from a non-approved registry — because IAM never inspects the image contents or its provenance. Binary Authorization enforces the admission-time check independent of identity, ensuring only attested images can run.
✗
Artifact Registry vulnerability scanning — blocking images with CVEs from being deployed.
Why it's wrong here
Artifact Registry vulnerability scanning proactively identifies known CVEs in stored images and can be combined with policies to block deployments of images that exceed a CVE severity threshold. However, that check hinges solely on the vulnerable code present in the image, not on whether a hardened CI/CD pipeline produced the image. It would therefore accept a cleanly scanned but manually built or tampered image if it lacks CVEs, whereas Binary Authorization enforces provenance via cryptographic attestation.

Go deeper

Cloud Digital Leader Trust and security with Google Cloud Practice Question

Why each option matters

Option-by-option breakdown

Related to this question