Google ACE Practice Question: Needs to ensure that only images from their…

Answer analysis

Option-by-option breakdown

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

• ✗

  A VPC firewall rule blocking pulls from unauthorized registries

  Why it's wrong here

  VPC firewall rules evaluate traffic based on IP addresses, ports, and protocols at the network layer. A registry pull is an HTTPS request to a hostname that resolves to an IP outside your VPC; a firewall rule could block that IP range entirely, but it would also block all internet egress and cannot inspect the HTTP path or image name. It cannot distinguish a pull from an authorized registry versus any other HTTPS endpoint, so it is the wrong tool for enforcing registry-level image provenance.

• ✓

  Binary Authorization with a policy requiring attestation from the approved registry

  Why this is correct

  Binary Authorization is a Google Cloud service that integrates with GKE to enforce deployment-time policy on container images. A policy can require that every image have a valid cryptographic attestation signed by a trusted authority, such as the approved registry, before the image is allowed to run on the cluster. If an image lacks the required attestation or the attestation fails verification, the deployment is denied. This provides automated, enforceable, and auditable control over which images can be deployed, directly addressing the need to block pulls/deployments from unauthorized registries.

• ✗

  Cloud Armor rules blocking container pull requests from external sources

  Why it's wrong here

  Cloud Armor is a web application firewall (WAF) that protects HTTP(S) load balancers from application-layer attacks like SQL injection or cross-site scripting. Container image pulls occur from a container registry via the registry's HTTPS API, not through your load balancer, so Cloud Armor never sees that traffic. Even if it did, Cloud Armor rules match on request attributes such as IP, headers, or URL paths, not on cryptographic attestations or the identity of the container image publisher; it cannot enforce a policy that only an approved registry's images may be deployed.

• ✗

  Manually reviewing all Docker images before deployment

  Why it's wrong here

  Manual review of Docker images is a human-driven, point-in-time process that quickly becomes impractical at scale, especially in CI/CD pipelines with frequent deployments. It cannot enforce a consistent, programmatic policy across teams or clusters, and a reviewer can miss subtle signs of tampering or provenance issues. This approach is also not integrated into the deployment pipeline, so it does not provide automatic enforcement or an audit trail, unlike Binary Authorization which rejects non-compliant images at deploy time in a repeatable way.

Go deeper

Related to this question