Your enterprise organization requires a secure CI/CD pipeline on Google Cloud for containerized microservices deployed to Google Kubernetes Engine (GKE). You need to implement a comprehensive supply chain security strategy that satisfies the following requirements: Shift-left vulnerability checking: Scan container images locally during the Cloud Build workflow and block the image from being pushed to Artifact Registry if CRITICAL or HIGH vulnerabilities are found. Continuous vulnerability monitoring: Automatically track newly discovered Common Vulnerabilities and Exposures (CVEs) on stored images within Artifact Registry without requiring manual rebuilds. Deployment policy enforcement: Prevent non-compliant or unverified images from being deployed to production GKE clusters. Which combination of actions should you implement?

In Cloud Build, use the On-Demand Scanning API to scan the locally built image and evaluate vulnerability severity prior to running docker push; enable automatic scanning via the Container Scanning API on Artifact Registry for continuous analysis; and configure Binary Authorization policies on the GKE cluster.: ### What the solution is This architecture integrates **Cloud Build**, **Artifact Analysis On-Demand Scanning**, **Artifact Registry continuous vulnerability scanning**, and **Binary Authorization** to deliver an end-to-end secure software supply chain. ### How it meets Requirement 1 (Shift-left vulnerability checking) By integrating the **On-Demand Scanning API** directly into `cloudbuild.yaml`, the pipeline runs `gcloud artifacts docker images scan` on the locally built image and inspects the output with `gcloud artifacts docker images list-vulnerabilities`. If `CRITICAL` or `HIGH` vulnerabilities are detected, the build step returns a non-zero exit code, immediately halting the pipeline before executing `docker push`. ### How it meets Requirement 2 (Continuous vulnerability monitoring) Enabling automatic scanning (`containerscanning.googleapis.com`) in **Artifact Registry** ensures that once an approved image is uploaded, **Artifact Analysis** continuously matches its package metadata against external CVE sources updated multiple times per day throughout the 30-day active monitoring window. ### How it meets Requirement 3 (Deployment policy enforcement) **Binary Authorization** acts as a Kubernetes admission controller on GKE. It enforces signature verification and attestations (such as vulnerability scan compliance and build provenance) before allowing container pods to deploy to the cluster. ### Key advantages - **Proactive prevention**: Keeps vulnerable images out of the artifact store entirely. - **Automated CVE updates**: Detects zero-day vulnerabilities in deployed images without manual re-scans. - **Strict runtime admission**: Guarantees cluster integrity via cryptographically verifiable attestations. - **Standardized tooling**: Leverages native Google Cloud services designed for SLSA supply chain frameworks.

Secure Cicd Pipeline Artifact Scanning Binary Authorization | Professional Cloud DevOps Engineer

Secure Cicd Pipeline Artifact Scanning Binary Authorization

Worked example. The correct answer is already marked and every option is explained below, so there is nothing to select here. To answer questions yourself, start the free trial.

Your enterprise organization requires a secure CI/CD pipeline on Google Cloud for containerized microservices deployed to Google Kubernetes Engine (GKE). You need to implement a comprehensive supply chain security strategy that satisfies the following requirements:

Shift-left vulnerability checking: Scan container images locally during the Cloud Build workflow and block the image from being pushed to Artifact Registry if CRITICAL or HIGH vulnerabilities are found.
Continuous vulnerability monitoring: Automatically track newly discovered Common Vulnerabilities and Exposures (CVEs) on stored images within Artifact Registry without requiring manual rebuilds.
Deployment policy enforcement: Prevent non-compliant or unverified images from being deployed to production GKE clusters.

Which combination of actions should you implement?

Execute Web Security Scanner inside the Cloud Build pipeline before pushing the container; disable the Container Scanning API to reduce overhead; and rely on Cloud Deploy manual release approvals for GKE rollout gating.

Configure Artifact Registry with on-push scanning only; write a Cloud Function triggered by Pub/Sub to delete non-compliant images after upload; and use IAM condition bindings on the GKE service account to block unauthorized workload deployments.

Set up a Cloud Scheduler cron job to pull and re-tag images every 7 days; invoke gcloud container images describe to parse CVE outputs into BigQuery; and use a custom Kubernetes mutating webhook to reject pods with unapproved tags.

In Cloud Build, use the On-Demand Scanning API to scan the locally built image and evaluate vulnerability severity prior to running docker push; enable automatic scanning via the Container Scanning API on Artifact Registry for continuous analysis; and configure Binary Authorization policies on the GKE cluster.

Professional Cloud DevOps Engineer

Secure Cicd Pipeline Artifact Scanning Binary Authorization

Related questions