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.

• ✗

  Cloud Monitoring, which provides metric dashboards and alerting

  Why it's wrong here

  Cloud Monitoring is designed for telemetry-collecting numeric metrics like CPU utilization, memory pressure, request latency, and uptime from monitored resources, and then visualizing them on dashboards or triggering alerting policies based on thresholds or anomaly detection. While it can use certain log data to generate log-based metrics, its core purpose is not to allow interactive, text-based searching of individual log entries for error strings or specific error messages across an organization's logging streams. The question specifically asks for searching across logs for matching error entries, which is a logging function, not a monitoring function.

• ✓

  Cloud Logging, which centralizes logs from all Google Cloud services and projects and supports powerful filtering and search queries across an organization

  Why this is correct

  Cloud Logging is the correct answer. It aggregates logs from all sources (Compute Engine, Cloud Run, GKE, App Engine, etc.) across all projects into a centralized store. Its query language allows searching for specific text strings, error levels, time ranges, and resource attributes across the entire organization.

• ✗

  BigQuery, by exporting logs to a dataset and running SQL queries to find matching error entries

  Why it's wrong here

  BigQuery is a powerful analytics warehouse, and it can indeed query log data exported from Cloud Logging via sinks into a BigQuery dataset. However, this approach is asynchronous—logs are exported in batch, so there is an inherent delay before entries are available for querying, making it unsuitable for real-time incident investigation. Moreover, the native Cloud Logging interface (Log Explorer) provides direct, low-latency text search across live logs from all projects without needing to pre-configure exports or write SQL joins, which is why BigQuery is not the primary tool for this scenario.

• ✗

  Cloud Trace, which provides distributed request tracing for latency analysis

  Why it's wrong here

  Cloud Trace is a distributed tracing service that captures end-to-end latency information for requests as they propagate through services, showing spans and timing details to help pinpoint performance bottlenecks. It does not provide a queryable search across raw log entries, nor does it filter on arbitrary text strings within error messages or log payloads. Trace's scope is limited to request traces and latency analysis, so it would not enable an engineer to search for a specific error signature across all projects' logs—that capability belongs to Cloud Logging's Log Explorer.

Go deeper

Related to this question