Your DevOps team manages an enterprise application in Google Cloud and is implementing an automated CI pipeline using Cloud Build connected to an external Git repository. The pipeline must satisfy the following architectural requirements: Automatically trigger builds whenever release tags matching semantic versions (such as v1.2.3, but excluding pre-release tags like v1.2.3-alpha) are pushed. Allow an external vulnerability scanner to invoke builds via an HTTP POST request, extracting dynamic metadata (scan_id and severity_score) from the incoming JSON payload into build parameters. Ensure user-defined parameter keys strictly comply with Cloud Build substitution variable conventions. How should you configure Cloud Build to meet these requirements?

Create a Push Tag trigger with the regex `^v[0-9]+\.[0-9]+\.[0-9]+$`, create a Webhook trigger authenticated with Secret Manager that maps `_SCAN_ID: $(body.scan_id)` and `_SEVERITY_SCORE: $(body.severity_score)`, and reference the variables in the build configuration.: What the Solution Is This solution properly combines Cloud Build Push Tag triggers using RE2 regular expression filtering with Webhook triggers that leverage Secret Manager for authentication and dynamic JSON payload extraction into user-defined substitution variables. How It Meets the Requirements Tag Filtering: Cloud Build tag triggers evaluate Git tags against regular expressions. The RE2 pattern ^v[0-9]+\.[0-9]+\.[0-9]+$ matches standard semantic version tags (e.g., v1.0.0, v2.4.12) while strictly excluding pre-release suffixes (such as -alpha, -beta, or -rc1). Webhook Ingestion: Cloud Build Webhook triggers allow external systems (such as third-party security scanners) to trigger builds via HTTP requests. A secret stored in Secret Manager is used to authenticate incoming webhook requests. Dynamic Payload Mapping: Webhook triggers use payload bindings with the syntax $(body.path.to.field) to extract values directly from the incoming JSON body into build substitution variables. Substitution Variable Conventions: In Cloud Build, all user-defined substitution variables must begin with an underscore (e.g., _SCAN_ID and _SEVERITY_SCORE), whereas system-defined variables (such as $BRANCH_NAME or $TAG_NAME) do not use leading underscores. Key Advantages and Capabilities Precise Event Filtering: Regex-based tag filters prevent unwanted development or release candidate tags from initiating production builds. Secure External Integration: Webhook triggers protect CI entry points by validating incoming payloads using Secret Manager tokens. Decoupled Architecture: Enables external tools to pass runtime parameters dynamically without hardcoding values in build scripts. Standardized Configuration: Adheres to Google Cloud's strict naming rules for user substitutions, preventing build validation errors. Why This Is Optimal This configuration uses native Cloud Build trigger mechanisms without requiring intermediary compute layers (such as Cloud Functions or Cloud Run), providing a serverless, highly secure, and maintenance-free CI integration.

StudyCerts

Professional Cloud DevOps Engineer

Advanced

Prepare and test your skills

Track Readiness

Set Exam Goal

Advanced

Prepare and test your skills

Track Readiness

Set Exam Goal

Configure Cloud Build Webhook Tag Triggers

Section: Continuous integration (CI) with Cloud Build

Your DevOps team manages an enterprise application in Google Cloud and is implementing an automated CI pipeline using Cloud Build connected to an external Git repository. The pipeline must satisfy the following architectural requirements:

Automatically trigger builds whenever release tags matching semantic versions (such as v1.2.3, but excluding pre-release tags like v1.2.3-alpha) are pushed.
Allow an external vulnerability scanner to invoke builds via an HTTP POST request, extracting dynamic metadata (scan_id and severity_score) from the incoming JSON payload into build parameters.
Ensure user-defined parameter keys strictly comply with Cloud Build substitution variable conventions.

How should you configure Cloud Build to meet these requirements?

Create a Webhook trigger that maps _SCAN_ID: ${body.scan_id} with Cloud KMS key wrapping, and configure a Cloud Source Repositories mirror to trigger builds using a commit_message: 'v*' filter.

Create a Manual trigger with custom substitutions _SCAN_ID and _SEVERITY_SCORE, and deploy a Cloud Function that polls the external scanner API on a 5-minute schedule.

Create a Push Tag trigger with the regex ^v[0-9]+\.[0-9]+\.[0-9]+$, create a Webhook trigger authenticated with Secret Manager that maps _SCAN_ID: $(body.scan_id) and _SEVERITY_SCORE: $(body.severity_score), and reference the variables in the build configuration.

Create a Push Branch trigger using the pattern v*, create a Pub/Sub trigger that extracts parameters using SCAN_ID: $(body.scan_id) without underscores, and trigger the build via Cloud Scheduler.

Professional Cloud DevOps Engineer

Advanced

Prepare and test your skills

Track Readiness

Set Exam Goal

Advanced

Prepare and test your skills

Track Readiness

Set Exam Goal

Configure Cloud Build Webhook Tag Triggers

Section: Continuous integration (CI) with Cloud Build

Automatically trigger builds whenever release tags matching semantic versions (such as v1.2.3, but excluding pre-release tags like v1.2.3-alpha) are pushed.
Allow an external vulnerability scanner to invoke builds via an HTTP POST request, extracting dynamic metadata (scan_id and severity_score) from the incoming JSON payload into build parameters.
Ensure user-defined parameter keys strictly comply with Cloud Build substitution variable conventions.

How should you configure Cloud Build to meet these requirements?

Create a Webhook trigger that maps _SCAN_ID: ${body.scan_id} with Cloud KMS key wrapping, and configure a Cloud Source Repositories mirror to trigger builds using a commit_message: 'v*' filter.

Create a Manual trigger with custom substitutions _SCAN_ID and _SEVERITY_SCORE, and deploy a Cloud Function that polls the external scanner API on a 5-minute schedule.

Create a Push Branch trigger using the pattern v*, create a Pub/Sub trigger that extracts parameters using SCAN_ID: $(body.scan_id) without underscores, and trigger the build via Cloud Scheduler.

Explanations

What the Solution Is

This solution properly combines Cloud Build Push Tag triggers using RE2 regular expression filtering with Webhook triggers that leverage Secret Manager for authentication and dynamic JSON payload extraction into user-defined substitution variables.

How It Meets the Requirements

Tag Filtering: Cloud Build tag triggers evaluate Git tags against regular expressions. The RE2 pattern ^v[0-9]+\.[0-9]+\.[0-9]+$ matches standard semantic version tags (e.g., v1.0.0, v2.4.12) while strictly excluding pre-release suffixes (such as -alpha, -beta, or -rc1).
Webhook Ingestion: Cloud Build Webhook triggers allow external systems (such as third-party security scanners) to trigger builds via HTTP requests. A secret stored in Secret Manager is used to authenticate incoming webhook requests.
Dynamic Payload Mapping: Webhook triggers use payload bindings with the syntax $(body.path.to.field) to extract values directly from the incoming JSON body into build substitution variables.
Substitution Variable Conventions: In Cloud Build, all user-defined substitution variables must begin with an underscore (e.g., _SCAN_ID and _SEVERITY_SCORE), whereas system-defined variables (such as $BRANCH_NAME or $TAG_NAME) do not use leading underscores.

Key Advantages and Capabilities

Precise Event Filtering: Regex-based tag filters prevent unwanted development or release candidate tags from initiating production builds.
Secure External Integration: Webhook triggers protect CI entry points by validating incoming payloads using Secret Manager tokens.
Decoupled Architecture: Enables external tools to pass runtime parameters dynamically without hardcoding values in build scripts.
Standardized Configuration: Adheres to Google Cloud's strict naming rules for user substitutions, preventing build validation errors.

Why This Is Optimal

This configuration uses native Cloud Build trigger mechanisms without requiring intermediary compute layers (such as Cloud Functions or Cloud Run), providing a serverless, highly secure, and maintenance-free CI integration.

View source documentation

Professional Cloud DevOps Engineer

Configure Cloud Build Webhook Tag Triggers

Professional Cloud DevOps Engineer

Configure Cloud Build Webhook Tag Triggers

What the Solution Is

How It Meets the Requirements

Key Advantages and Capabilities

Why This Is Optimal

Related questions