GCP Professional Cloud DevOps Engineer Practice Question 7: Binary Authorization Attestations
Google Cloud Professional Cloud DevOps Engineer · Test 1 · question 7 of 10
Security requires that only container images produced by the organization's own Cloud Build pipeline, and scanned for vulnerabilities, may run in the production GKE cluster. Several teams deploy to that cluster today and nobody is certain which of their images would fail the rule. The platform team must roll the control out without unexpectedly blocking a legitimate production deployment, and must retain a way to deploy during a Sev-1 when the control itself is in the way.
Which approach meets all of these requirements?
Show answer and explanation
Answer:
Binary Authorization is the deploy-time gate. Its policy is evaluated by the cluster's admission controller, and an attestation (a signed statement that a specific image digest completed a required stage, such as being built and scanned by the approved pipeline) is what proves provenance rather than merely asserting a name. Dry-run mode answers the "nobody is certain what would fail" problem: the policy is evaluated and violations are recorded in Cloud Audit Logs while deployments continue, so the team can find and fix non-compliant workloads before enforcing. Break-glass allows a deployment to proceed during an emergency while still recording the override in the audit logs. Artifact Analysis vulnerability findings can feed the same policy, tying the scanning requirement into the gate.
Option A controls who may *publish* but not what may *run*. A workload manifest can still reference an image from any public registry the nodes can pull from, and nothing stops a hand-built image being pushed from a workstation by an account that already holds the role.
Option B is a useful build-time control and a genuine part of the supply chain story, but it stops at the pipeline. It has no effect on an image that was never built by that pipeline, and it does not prevent a previously built, now-vulnerable image from being deployed later.
Option C checks a string, not a signature. Any image pushed into that repository by any means satisfies a hostname prefix rule, so it proves nothing about how the image was built or whether it was scanned, and the team would be maintaining custom admission webhook code that Binary Authorization already provides as a managed control with dry-run and break-glass built in.
Reference: Binary Authorization overview