Cloud Digital Leader Trust and security with Google Cloud Practice Question
A technology company runs its containerized microservices on Google Kubernetes Engine (GKE). The development team frequently pushes new container images to Container Registry, and those images are deployed to a production cluster. The security team recently discovered that a few running containers have critical vulnerabilities from outdated base images. They want to enforce a policy that only vulnerability-scanned and approved images can be deployed in the production cluster. The team uses Cloud Build for CI/CD and Container Analysis for vulnerability scanning. Which solution should they implement to meet this requirement?
⚠ Common exam trap
Candidates often confuse scanning images (which only identifies vulnerabilities) with enforcing a policy that blocks deployment of vulnerable images, leading them to choose a scanning-only option (like C) instead of the policy enforcement mechanism (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
✓
Enable Binary Authorization with a policy that requires attestations from Container Analysis for all deployments in the production cluster.
Binary Authorization enforces deployment-time policies that require signed attestations from trusted authorities (like Container Analysis) before an image can be deployed on GKE. By configuring a policy that mandates an attestation from Container Analysis (which performs vulnerability scanning), only images that have been scanned and approved can be deployed, directly meeting the requirement to block containers with critical vulnerabilities.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Use Cloud Security Scanner to scan the production cluster for vulnerabilities.
Why it's wrong here
Cloud Security Scanner is a black-box web application scanner that detects common OWASP Top-10 vulnerabilities (e.g., XSS, CSRF) on live endpoints, not a container image or infrastructure vulnerability scanner. It cannot inspect container image layers for CVEs, nor does it act as an admission controller that blocks deploys. Therefore, it cannot provide pre-deployment verification of the containerized microservices in the production cluster.
- ✗
Enable Cloud Asset Inventory to monitor image vulnerabilities across projects.
Why it's wrong here
Cloud Asset Inventory captures metadata about GCP resources and historical changes using asset feeds, but it does not scan image content for security vulnerabilities. While you could use its export stream to trigger other tools, the service itself has no notion of CVE severity or container layer analysis. Without an enforcement point (like an admission policy), enabling it only provides visibility, not prevention.
- ✗
Configure Cloud Build to run a vulnerability scan step before pushing images to Container Registry.
Why it's wrong here
Configuring Cloud Build to run a vulnerability scan step before pushing to Container Registry (or Artifact Registry) is a good CI checkpoint, but it only blocks the build pipeline in which that step runs. If images are built outside that pipeline, or if a previously built image is referenced, the deployment to the production cluster is not vetted. There is no reusable attestation or admission-control mechanism preventing an unscanned or vulnerable image from being deployed later.
- ✓
Enable Binary Authorization with a policy that requires attestations from Container Analysis for all deployments in the production cluster.
Why this is correct
Binary Authorization enforces a supply-chain policy at deployment time by requiring trusted attestations for every container image deployed to the GKE cluster. You can configure Container Analysis (e.g., on-demand scanning) to generate attestations for images that pass a vulnerability threshold, and an Attestor can be set to require those attestations. Because this is enforced by the Kubernetes admission controller in the cluster, any attempt to deploy an unverified image is blocked — providing the actual enforcement that the other options lack.
Go deeper
Related to this question
Learn chapter
Cloud Digital Transformation
Key term
Vulnerability
A vulnerability is a weakness in a system, network, or software that could be exploited by a threat to cause harm or unauthorized access.
Key term
Container registry
A container registry is a centralized storage and distribution system for container images, enabling developers to push, pull, and manage versions of application snapshots across environments.
About these practice questions
One of 829 original GCDL practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This GCDL practice question is part of Courseiva's free Google Cloud certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the GCDL exam.