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.

• ✗

  Use log sinks to route logs to a BigQuery dataset

  Why it's wrong here

  Routing logs to BigQuery via a log sink enables powerful SQL-based analytics and real-time insights, but BigQuery is fundamentally a data warehouse optimized for query performance rather than archival storage. Its storage costs per GB are significantly higher than Cloud Storage, and repeated querying incurs additional costs, making it costly for long-term retention of high-volume logs. While this approach does aggregate logs, it fails to address the primary need of economical, durable retention across many projects.

• ✗

  Enable VPC Flow Logs

  Why it's wrong here

  Enabling VPC Flow Logs only captures metadata about IP traffic flowing through your VPC networks, such as source/destination addresses, ports, and packet counts. This is a subset of network telemetry and does not include application logs, system logs, audit logs, or access logs from individual services. Consequently, it cannot serve as a unified aggregation mechanism for all logs generated across your organization's portfolio of projects.

• ✗

  Use Cloud Logging's aggregation view

  Why it's wrong here

  Cloud Logging's aggregation view is a console feature that lets you query and inspect log entries from multiple selected projects in a single, unified UI. It does not copy, export, or persist any log data to a new storage destination, so if a log is not retained by the original log bucket, it simply disappears from the view after its retention period. This makes it a convenient observability tool, not a solution for centralizing logs for durable storage or compliance-driven retention.

• ✓

  Use log sinks to route logs to a Cloud Storage bucket in a central project

  Why this is correct

  Configuring a log sink with a Cloud Storage bucket in a central project is the recommended pattern for long-term, cross-project log aggregation. Log sinks can be defined at the organization, folder, or project level with `includeChildren` set, automatically routing all matching log entries from every child project into a single Cloud Storage bucket, which provides durable, low-cost, and immutable object storage. Combined with lifecycle policies to transition logs to colder storage classes, this minimizes cost while satisfying audit and retention requirements.

Go deeper

Related to this question