Cloud Digital Leader Google Cloud Products and Services 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 Spanner

  Why it's wrong here

  Cloud Spanner is a globally distributed relational database that provides strong consistency and ACID transactions across regions, but its architecture is optimized for transactional workloads, not for high-throughput append-heavy time-series reads. While Spanner can scale horizontally, it is not designed to deliver single-digit millisecond point lookups at millions of QPS for IoT sensor data; its latency and cost profile are better suited for applications requiring relational integrity and cross-row transactions. Using Spanner for time-series would force schema over-engineering and incur unnecessary overhead, making Bigtable the more appropriate choice.

• ✓

  Cloud Bigtable

  Why this is correct

  Cloud Bigtable is a fully managed, wide-column NoSQL database built specifically for large-scale analytical and operational workloads, including time-series and IoT sensor data. It stores data as sparse rows keyed by a row key (typically device ID and timestamp), enabling single-digit millisecond read/write latency at massive scale. Bigtable scales horizontally by adding nodes to handle millions of queries per second without downtime, and its native integration with Cloud BigQuery, Dataflow, and Pub/Sub makes it the ideal choice for petabyte-scale sensor data ingestion and retrieval.

• ✗

  BigQuery

  Why it's wrong here

  BigQuery is a serverless, columnar data warehouse optimized for running complex analytical SQL queries over petabytes of data, with query latency typically ranging from seconds to minutes. It is not designed for low-latency point lookups or high-QPS operational reads; each query scans a large amount of data and incurs a fixed overhead that makes millisecond response times impossible. While BigQuery can be used to analyze time-series data after it is stored elsewhere, it cannot serve as a real-time storage layer for millions of IoT sensor reads per second.

• ✗

  Firestore

  Why it's wrong here

  Firestore is a flexible, document-oriented NoSQL database designed primarily for mobile and web app development, with real-time sync and offline support. It stores data in hierarchical documents and collections, and while it scales automatically, its write throughput is limited to roughly 10,000 writes per second per database, far below the millions of QPS required for petabyte-scale IoT workloads. Firestore also lacks native time-series optimizations like compaction or compression of timestamp-ordered data, making it unsuitable for high-volume sensor data storage and retrieval.

Go deeper

Related to this question