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.

Configure Cloud Build Webhook Tag Triggers | Professional Cloud DevOps Engineer

Configure Cloud Build Webhook Tag Triggers

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 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.

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 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 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

Configure Cloud Build Webhook Tag Triggers

Related questions