A DevOps engineer is designing a secure CI/CD pipeline using Cloud Build and Artifact Registry. The security policy mandates two key requirements: Container images must be scanned for operating system and language package vulnerabilities within the build pipeline prior to release. Event-driven notifications must be published to Pub/Sub so downstream services can immediately process build status updates, vulnerability results, and trigger automated remediation workflows. Which approach should the DevOps engineer implement to satisfy these requirements?

Incorporate a Cloud Build step that invokes the On-Demand Scanning API to scan container images during execution, and configure a Pub/Sub subscription on the build notification topic to trigger downstream event-driven remediation services.: What the solution is This approach integrates shifting security left with event-driven automation. By invoking the On-Demand Scanning API within the Cloud Build pipeline, container images are scanned for vulnerabilities before they are deployed or promoted. Downstream services leverage Pub/Sub build notifications to act instantly upon build completion and vulnerability reports. How it meets the requirements In-pipeline vulnerability scanning: The On-Demand Scanning API allows Cloud Build steps to extract package metadata and scan local container images for known OS and language package vulnerabilities before they are pushed or deployed. Real-time event-driven alerts: Cloud Build automatically publishes build status events (such as SUCCESS, FAILURE, or step metadata) to the cloud-builds Pub/Sub topic. Downstream subscribers—such as Cloud Functions, Cloud Run, or custom Cloud Build notifiers—can listen to these messages to execute immediate automated remediation. Key advantages and capabilities Shift-Left Security: Detects vulnerabilities early in the build phase, preventing flawed artifacts from entering production repositories. Decoupled Architecture: Pub/Sub enables asynchronous, scalable delivery of build and scanning events to multiple subscribers without tightly coupling pipeline steps. Automated Remediation: Triggers immediate downstream webhooks, Slack alerts, or policy evaluation engines upon build status updates. SLSA Alignment: Keeps security scanning inside managed, isolated Cloud Build workers rather than relying on unvetted local developer environments. Why this is optimal Using the native On-Demand Scanning API combined with Pub/Sub event streams provides end-to-end automation, low latency, and adherence to Google Cloud supply chain security best practices.

Cloud Build On-Demand Scan with Pub/Sub

Scanning Cloud Build Images with Pub/Sub Notifications

A DevOps engineer is designing a secure CI/CD pipeline using Cloud Build and Artifact Registry. The security policy mandates two key requirements:

Container images must be scanned for operating system and language package vulnerabilities within the build pipeline prior to release.
Event-driven notifications must be published to Pub/Sub so downstream services can immediately process build status updates, vulnerability results, and trigger automated remediation workflows.

Which approach should the DevOps engineer implement to satisfy these requirements?

Configure Cloud Scheduler to poll Artifact Registry every 30 minutes, invoke an external third-party vulnerability scanner over HTTP, and directly email engineers when issues are found.

Incorporate a Cloud Build step that invokes the On-Demand Scanning API to scan container images during execution, and configure a Pub/Sub subscription on the build notification topic to trigger downstream event-driven remediation services.

Execute vulnerability scanning by running ad-hoc scripts on developer workstations prior to commit, and export Cloud Logging audit logs to BigQuery using scheduled hourly queries to alert the remediation team.

Rely exclusively on post-deployment GKE runtime scanning, disabling pipeline build steps, and use Cloud Monitoring log-based metrics to trigger synchronous webhook alerts directly to Slack.

Explanations

Configure Cloud Scheduler to poll Artifact Registry every 30 minutes, invoke an external third-party vulnerability scanner over HTTP, and directly email engineers when issues are found.

What the option is

This design uses a periodic cron trigger via Cloud Scheduler to poll repositories in Artifact Registry, trigger external scanning APIs, and send static email alerts.

Why it doesn't meet the requirements

Lacks in-pipeline scanning: Scanning only occurs after artifacts are already pushed, leaving a time window where vulnerable images could be pulled or deployed before the polling interval triggers.
Lacks event-driven Pub/Sub architecture: Polling on a timer introduces blind spots between intervals and bypasses the decoupled Pub/Sub messaging model needed for immediate event streaming.

Key characteristics and limitations

Polling inefficiency: Generates unnecessary API calls when no new images have been built and adds delay when images are created right after a poll cycle.
No pipeline gate: Cannot fail a specific Cloud Build execution automatically if critical vulnerabilities are discovered during compilation.

This answer would be correct if

The goal was periodic compliance auditing of dormant, long-stored legacy container images rather than active CI/CD gating and real-time build alerting.

View source documentation

Incorporate a Cloud Build step that invokes the On-Demand Scanning API to scan container images during execution, and configure a Pub/Sub subscription on the build notification topic to trigger downstream event-driven remediation services.

What the solution is

This approach integrates shifting security left with event-driven automation. By invoking the On-Demand Scanning API within the Cloud Build pipeline, container images are scanned for vulnerabilities before they are deployed or promoted. Downstream services leverage Pub/Sub build notifications to act instantly upon build completion and vulnerability reports.

How it meets the requirements

In-pipeline vulnerability scanning: The On-Demand Scanning API allows Cloud Build steps to extract package metadata and scan local container images for known OS and language package vulnerabilities before they are pushed or deployed.
Real-time event-driven alerts: Cloud Build automatically publishes build status events (such as SUCCESS, FAILURE, or step metadata) to the cloud-builds Pub/Sub topic. Downstream subscribers—such as Cloud Functions, Cloud Run, or custom Cloud Build notifiers—can listen to these messages to execute immediate automated remediation.

Key advantages and capabilities

Shift-Left Security: Detects vulnerabilities early in the build phase, preventing flawed artifacts from entering production repositories.
Decoupled Architecture: Pub/Sub enables asynchronous, scalable delivery of build and scanning events to multiple subscribers without tightly coupling pipeline steps.
Automated Remediation: Triggers immediate downstream webhooks, Slack alerts, or policy evaluation engines upon build status updates.
SLSA Alignment: Keeps security scanning inside managed, isolated Cloud Build workers rather than relying on unvetted local developer environments.

Why this is optimal

Using the native On-Demand Scanning API combined with Pub/Sub event streams provides end-to-end automation, low latency, and adherence to Google Cloud supply chain security best practices.

View source documentation

Execute vulnerability scanning by running ad-hoc scripts on developer workstations prior to commit, and export Cloud Logging audit logs to BigQuery using scheduled hourly queries to alert the remediation team.

What the option is

This configuration relies on individual developers executing manual scan scripts on their local laptops and uses scheduled BigQuery queries against exported Cloud Logging audit logs to identify security anomalies.

Why it doesn't meet the requirements

Fails automated pipeline scanning: Local scanning is inconsistent across developer environments, does not enforce security gates inside the Cloud Build pipeline, and violates SLSA level 2 requirements for hermetic, automated build environments.
Fails real-time alerting: Running batch queries on an hourly schedule in BigQuery introduces a significant delay (up to 60 minutes), failing the requirement for immediate, real-time event-driven notifications.

Key characteristics and limitations

High configuration drift: Individual developer machines may have different scanners, package versions, or omitted execution steps.
Batch latency: Scheduled analytical queries in BigQuery are optimized for historical reporting, not near real-time operational triggering.

This answer would be correct if

The organization required long-term historical vulnerability analytics across multi-year audit logs rather than automated in-pipeline gating and real-time event dispatching.

View source documentation

Rely exclusively on post-deployment GKE runtime scanning, disabling pipeline build steps, and use Cloud Monitoring log-based metrics to trigger synchronous webhook alerts directly to Slack.

What the option is

This approach defers vulnerability analysis until after container images are actively deployed to runtime clusters (e.g., Google Kubernetes Engine) and relies on log metrics to send synchronous notifications.

Why it doesn't meet the requirements

Fails in-pipeline scanning: Disabling scanning in the Cloud Build pipeline violates the core shift-left security requirement, allowing vulnerable container images to enter production runtime environments unchecked.
Bypasses Pub/Sub messaging: Direct synchronous webhook alerting lacks the buffering, retry capabilities, and multi-consumer fan-out provided by a Pub/Sub event backbone.

Key characteristics and limitations

Production exposure: Vulnerabilities are only detected after workloads are already running and potentially exposed to threats.
Tight coupling: Synchronous webhook alerts fail if the endpoint is temporarily unavailable, lacking the delivery guarantees of message queues.

This answer would be correct if

The requirement focused strictly on post-deployment runtime anomaly detection rather than securing the build and artifact generation lifecycle in CI/CD.

View source documentation

Last updated August 28, 2026Validated August 28, 2026

Scanning Cloud Build Images with Pub/Sub Notifications

A DevOps engineer is designing a secure CI/CD pipeline using Cloud Build and Artifact Registry. The security policy mandates two key requirements:

Container images must be scanned for operating system and language package vulnerabilities within the build pipeline prior to release.
Event-driven notifications must be published to Pub/Sub so downstream services can immediately process build status updates, vulnerability results, and trigger automated remediation workflows.

Which approach should the DevOps engineer implement to satisfy these requirements?

Configure Cloud Scheduler to poll Artifact Registry every 30 minutes, invoke an external third-party vulnerability scanner over HTTP, and directly email engineers when issues are found.

Rely exclusively on post-deployment GKE runtime scanning, disabling pipeline build steps, and use Cloud Monitoring log-based metrics to trigger synchronous webhook alerts directly to Slack.

Explanations

Configure Cloud Scheduler to poll Artifact Registry every 30 minutes, invoke an external third-party vulnerability scanner over HTTP, and directly email engineers when issues are found.

What the option is

This design uses a periodic cron trigger via Cloud Scheduler to poll repositories in Artifact Registry, trigger external scanning APIs, and send static email alerts.

Why it doesn't meet the requirements

Lacks in-pipeline scanning: Scanning only occurs after artifacts are already pushed, leaving a time window where vulnerable images could be pulled or deployed before the polling interval triggers.
Lacks event-driven Pub/Sub architecture: Polling on a timer introduces blind spots between intervals and bypasses the decoupled Pub/Sub messaging model needed for immediate event streaming.

Key characteristics and limitations

Polling inefficiency: Generates unnecessary API calls when no new images have been built and adds delay when images are created right after a poll cycle.
No pipeline gate: Cannot fail a specific Cloud Build execution automatically if critical vulnerabilities are discovered during compilation.

This answer would be correct if

The goal was periodic compliance auditing of dormant, long-stored legacy container images rather than active CI/CD gating and real-time build alerting.

View source documentation

Incorporate a Cloud Build step that invokes the On-Demand Scanning API to scan container images during execution, and configure a Pub/Sub subscription on the build notification topic to trigger downstream event-driven remediation services.

What the solution is

How it meets the requirements

In-pipeline vulnerability scanning: The On-Demand Scanning API allows Cloud Build steps to extract package metadata and scan local container images for known OS and language package vulnerabilities before they are pushed or deployed.
Real-time event-driven alerts: Cloud Build automatically publishes build status events (such as SUCCESS, FAILURE, or step metadata) to the cloud-builds Pub/Sub topic. Downstream subscribers—such as Cloud Functions, Cloud Run, or custom Cloud Build notifiers—can listen to these messages to execute immediate automated remediation.

Key advantages and capabilities

Shift-Left Security: Detects vulnerabilities early in the build phase, preventing flawed artifacts from entering production repositories.
Decoupled Architecture: Pub/Sub enables asynchronous, scalable delivery of build and scanning events to multiple subscribers without tightly coupling pipeline steps.
Automated Remediation: Triggers immediate downstream webhooks, Slack alerts, or policy evaluation engines upon build status updates.
SLSA Alignment: Keeps security scanning inside managed, isolated Cloud Build workers rather than relying on unvetted local developer environments.

Why this is optimal

Using the native On-Demand Scanning API combined with Pub/Sub event streams provides end-to-end automation, low latency, and adherence to Google Cloud supply chain security best practices.

View source documentation

Execute vulnerability scanning by running ad-hoc scripts on developer workstations prior to commit, and export Cloud Logging audit logs to BigQuery using scheduled hourly queries to alert the remediation team.

What the option is

Why it doesn't meet the requirements

Fails automated pipeline scanning: Local scanning is inconsistent across developer environments, does not enforce security gates inside the Cloud Build pipeline, and violates SLSA level 2 requirements for hermetic, automated build environments.
Fails real-time alerting: Running batch queries on an hourly schedule in BigQuery introduces a significant delay (up to 60 minutes), failing the requirement for immediate, real-time event-driven notifications.

Key characteristics and limitations

High configuration drift: Individual developer machines may have different scanners, package versions, or omitted execution steps.
Batch latency: Scheduled analytical queries in BigQuery are optimized for historical reporting, not near real-time operational triggering.

This answer would be correct if

The organization required long-term historical vulnerability analytics across multi-year audit logs rather than automated in-pipeline gating and real-time event dispatching.

View source documentation

Rely exclusively on post-deployment GKE runtime scanning, disabling pipeline build steps, and use Cloud Monitoring log-based metrics to trigger synchronous webhook alerts directly to Slack.

What the option is

Why it doesn't meet the requirements

Fails in-pipeline scanning: Disabling scanning in the Cloud Build pipeline violates the core shift-left security requirement, allowing vulnerable container images to enter production runtime environments unchecked.
Bypasses Pub/Sub messaging: Direct synchronous webhook alerting lacks the buffering, retry capabilities, and multi-consumer fan-out provided by a Pub/Sub event backbone.

Key characteristics and limitations

Production exposure: Vulnerabilities are only detected after workloads are already running and potentially exposed to threats.
Tight coupling: Synchronous webhook alerts fail if the endpoint is temporarily unavailable, lacking the delivery guarantees of message queues.

This answer would be correct if

The requirement focused strictly on post-deployment runtime anomaly detection rather than securing the build and artifact generation lifecycle in CI/CD.

View source documentation

Last updated August 28, 2026Validated August 28, 2026

Scanning Cloud Build Images with Pub/Sub Notifications

Explanations

Configure Cloud Scheduler to poll Artifact Registry every 30 minutes, invoke an external third-party vulnerability scanner over HTTP, and directly email engineers when issues are found.

What the option is

Why it doesn't meet the requirements

Key characteristics and limitations

This answer would be correct if

Incorporate a Cloud Build step that invokes the On-Demand Scanning API to scan container images during execution, and configure a Pub/Sub subscription on the build notification topic to trigger downstream event-driven remediation services.

What the solution is

How it meets the requirements

Key advantages and capabilities

Why this is optimal

Execute vulnerability scanning by running ad-hoc scripts on developer workstations prior to commit, and export Cloud Logging audit logs to BigQuery using scheduled hourly queries to alert the remediation team.

What the option is

Why it doesn't meet the requirements

Key characteristics and limitations

This answer would be correct if

Rely exclusively on post-deployment GKE runtime scanning, disabling pipeline build steps, and use Cloud Monitoring log-based metrics to trigger synchronous webhook alerts directly to Slack.

What the option is

Why it doesn't meet the requirements

Key characteristics and limitations

This answer would be correct if

Try 10 interactive questions like this one, free

Related questions

Artifact Analysis On-Demand vs Continuous Scanning

Binary Authorization Attestation With Artifact Analysis

Cloud Build User-Specified Service Account

Predictive Autoscaling with Initialization Period

Ops Agent Logging Pipeline Configuration

Uniform Bucket-Level Access

Scanning Cloud Build Images with Pub/Sub Notifications

Explanations

Configure Cloud Scheduler to poll Artifact Registry every 30 minutes, invoke an external third-party vulnerability scanner over HTTP, and directly email engineers when issues are found.

What the option is

Why it doesn't meet the requirements

Key characteristics and limitations

This answer would be correct if

Incorporate a Cloud Build step that invokes the On-Demand Scanning API to scan container images during execution, and configure a Pub/Sub subscription on the build notification topic to trigger downstream event-driven remediation services.

What the solution is

How it meets the requirements

Key advantages and capabilities

Why this is optimal

Execute vulnerability scanning by running ad-hoc scripts on developer workstations prior to commit, and export Cloud Logging audit logs to BigQuery using scheduled hourly queries to alert the remediation team.

What the option is

Why it doesn't meet the requirements

Key characteristics and limitations

This answer would be correct if

Rely exclusively on post-deployment GKE runtime scanning, disabling pipeline build steps, and use Cloud Monitoring log-based metrics to trigger synchronous webhook alerts directly to Slack.

What the option is

Why it doesn't meet the requirements

Key characteristics and limitations

This answer would be correct if

Try 10 interactive questions like this one, free

Related questions

Artifact Analysis On-Demand vs Continuous Scanning

Binary Authorization Attestation With Artifact Analysis

Cloud Build User-Specified Service Account

Predictive Autoscaling with Initialization Period

Ops Agent Logging Pipeline Configuration

Uniform Bucket-Level Access