Cloud Digital Leader Practice Question: Google Cloud products, services, and solutions

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 SQL, Google Cloud's managed relational database service

  Why it's wrong here

  Cloud SQL is a fully managed relational database service for MySQL, PostgreSQL, and SQL Server, architected for transactional (OLTP) workloads with row-based storage and B-tree indexes optimized for point lookups and short-lived transactions. It runs on a single instance or a small regional cluster, with storage limits that fall far short of petabyte scale. Analytical queries that scan huge tables would incur massive I/O and memory overhead, causing query times to balloon and degrading performance for concurrent OLTP users. Its fundamental design— row stores, connection limits, and node-based scaling—makes it unsuitable for data-warehouse-style reporting over billions of rows.

• ✓

  BigQuery, Google Cloud's serverless data warehouse for petabyte-scale analytical SQL

  Why this is correct

  BigQuery is precisely designed for this use case. Its serverless architecture, columnar storage format, and distributed query engine make it ideal for analysts running complex SQL against massive datasets. The weekly report workload is a canonical BigQuery use case.

• ✗

  Cloud Bigtable, Google's NoSQL wide-column database

  Why it's wrong here

  Cloud Bigtable is a NoSQL, wide-column database built on the same underlying storage as Google's internal Bigtable, designed for high-throughput, low-latency key/value access in scenarios like IoT streams, ad-tech bid logs, and time-series data. It exposes a key-value API (HBase-compatible) and does not support SQL, join operations, or complex aggregation; analytical SQL queries are not even an option. Even if you could press SQL into it via custom connectors, Bigtable lacks the columnar compression, partition pruning, and distributed execution engine needed for interactive analysis over petabytes—it optimizes for write-heavy, key-based reads, not in-depth reporting. Its scaling model is about throughput and capacity, not about accelerating complex analytical queries across many columns and billions of rows.

• ✗

  Firestore, Google Cloud's serverless NoSQL document database

  Why it's wrong here

  Firestore is a serverless, mobile-first NoSQL document database that stores JSON-like documents in collections, synchronized in real time to client SDKs via listeners. It is built for rapid reads/writes of small, individual documents in mobile/web apps (e.g., chat, presence, user profiles), not for scanning vast analytical datasets. Firestore does not support SQL—queries are limited to field-based filters and simple ordering, with no GROUP BY, aggregate functions, or joins across collections. Moreover, its query engine is designed for low-latency path lookups within a single project, and its performance degrades if you try to fetch or scan large ranges of data, which would be required for a weekly report across petabyte-scale datasets. It is fundamentally a transactional, real-time database for application state, not a data warehouse.

Go deeper

Related to this question