Cloud Digital Leader Scaling with Google Cloud operations Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Query logs using Logging Query Language

  Why it's wrong here

  Logging Query Language is a filtering and querying syntax used in Cloud Logging to search and analyze log entries, not a mechanism for collecting or evaluating metric data. While logs and metrics can be correlated through logs-based metrics, the query language itself operates on log records, not on the time-series data managed by Cloud Monitoring. Therefore, using it would address log analysis, not metric collection or alerting.

• ✗

  Automatically remediate incidents with Cloud Functions

  Why it's wrong here

  Cloud Functions can be used to automate incident response, but only as an external webhook target configured within an alerting policy's notification channel. Cloud Monitoring itself does not directly invoke or orchestrate remediation; it only sends notifications to channels such as HTTPS webhooks. Thus, automatic remediation with Cloud Functions is a downstream integration you build, not a built-in capability of the Monitoring service.

• ✓

  Define custom metrics via the Monitoring API

  Why this is correct

  The Monitoring API exposes a `timeSeries.create` method that enables you to write custom metrics, such as application-specific counters, gauges, or histograms, into Cloud Monitoring. These custom metrics then appear in dashboards and can be referenced in alerting policies alongside system metrics. This is a core extension point for monitoring anything not automatically collected by Google Cloud's built-in integrations.

• ✓

  Set up alerting policies based on metric thresholds

  Why this is correct

  Alerting policies in Cloud Monitoring let you define conditions that trigger notifications when a metric crosses a threshold, falls below it, or deviates in other specified ways. These conditions use monitoring filters to select metric time series, set comparison operators and duration windows, and route alerts to notification channels. This is a fundamental, built-in feature for turning raw metric data into actionable incidents.

• ✓

  Create uptime checks for external URLs

  Why this is correct

  Uptime checks are a Cloud Monitoring feature that periodically sends HTTP, HTTPS, or TCP requests to external URL endpoints from multiple geographic locations to verify service availability and latency. The resulting success/failure data is stored as a metric, viewable on dashboards, and can be used in alerting policies to notify you when a public service is unreachable. This provides synthetic monitoring of user-facing endpoints without requiring agents or instrumentation.

Go deeper

Related to this question