Your team is building an automated incident triage service hosted outside Google Cloud that consumes alert notifications from Cloud Monitoring. The security team establishes the following technical requirements for the integration: The webhook endpoint must verify that incoming alert requests originate from an authorized configuration using a shared secret. Incident notification payloads and authentication credentials must be protected against eavesdropping in transit. The integration must use native Cloud Monitoring webhook notification channel capabilities without introducing intermediate proxy compute infrastructure. How should you configure the custom webhook notification channel in Cloud Monitoring and the receiving service?

Configure the notification channel with an HTTPS endpoint URL containing the shared secret as a query string parameter, and configure the receiving service to validate the token parameter against its stored secret.: ### What Token Authentication for Webhooks Is **Token-based authentication** for Cloud Monitoring webhooks is a mechanism where a unique shared secret token is passed directly within the endpoint URL's query string (for example, `https://monitoring-receiver.example.com/alerts?auth_token=SECRET_VALUE`). When Cloud Monitoring triggers an alert notification, it issues an HTTP POST request to this target URL, allowing the external receiving service to extract and validate the token parameter before processing the incident payload. ### How It Meets the Requirements * **Verify incoming alert requests:** The receiving application inspects the incoming request query parameters (such as `auth_token`), comparing the value against a securely stored secret key. If the token is missing or incorrect, the server rejects the request with an HTTP `401 Unauthorized` or `403 Forbidden` status code. * **Protect credentials in transit:** By enforcing an **HTTPS** endpoint, the entire HTTP request—including the full path, query string parameters, and incident payload body—is encrypted via TLS, preventing network eavesdroppers from intercepting the secret token or alert payload. * **Native capabilities without intermediate proxies:** Cloud Monitoring natively supports specifying custom query string parameters in webhook URLs when adding a Webhook notification channel in the Google Cloud console or via the Monitoring API. ### Key Advantages and Capabilities * **Direct and Lightweight:** Implements authentication without requiring custom middleware or complex API proxy layers. * **Encrypted Communication:** Standard TLS termination at the receiving endpoint ensures query strings and payload data remain confidential. * **Broad Compatibility:** Works with custom microservices, third-party ingestion endpoints, and serverless webhooks. * **Native Verification:** Can be immediately tested and verified using the **Test Connection** feature in Cloud Monitoring notification channels. ### Why This Is Optimal This design directly fulfills all security and architectural constraints using native Cloud Monitoring webhook functionality. Combining query-based token authentication with TLS provides confidentiality and origin verification with minimal operational overhead.

Secure Cloud Monitoring Custom Webhook Token Auth | Professional Cloud DevOps Engineer

Secure Cloud Monitoring Custom Webhook Token Auth

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 team is building an automated incident triage service hosted outside Google Cloud that consumes alert notifications from Cloud Monitoring. The security team establishes the following technical requirements for the integration:

The webhook endpoint must verify that incoming alert requests originate from an authorized configuration using a shared secret.
Incident notification payloads and authentication credentials must be protected against eavesdropping in transit.
The integration must use native Cloud Monitoring webhook notification channel capabilities without introducing intermediate proxy compute infrastructure.

How should you configure the custom webhook notification channel in Cloud Monitoring and the receiving service?

Configure the notification channel with HTTP Basic Authentication credentials, and configure the receiving service to accept the initial POST request without returning a 401 Unauthorized status code.

Configure the notification channel using an asymmetric HMAC digital signature in the custom payload schema, and configure the receiving service to verify the signature header.

Configure the notification channel with an HTTPS endpoint URL containing the shared secret as a query string parameter, and configure the receiving service to validate the token parameter against its stored secret.

Configure the notification channel with an plain HTTP endpoint URL containing the shared secret as a query string parameter, and configure the receiving service to validate the token parameter against its stored secret.

Professional Cloud DevOps Engineer

Secure Cloud Monitoring Custom Webhook Token Auth

Related questions