An enterprise is planning its multi-year data architecture on Google Cloud to handle projected data growth across three critical business workloads: Workload 1: A globally distributed transaction processing system that requires strict ANSI SQL compliance, ACID guarantees, and horizontal scaling across multiple regions. Workload 2: A high-velocity IoT telemetry ingestion engine storing petabytes of single-keyed time-series events that requires predictable sub-10ms read and write latencies. Workload 3: An enterprise data warehouse expected to scale storage to dozens of petabytes while dynamically allocating compute resources without manual cluster resizing. Which combination of Google Cloud storage and database services best satisfies the scalability and architectural requirements of these workloads?

Workload 1: Cloud Spanner; Workload 2: Cloud Bigtable; Workload 3: BigQuery: ### What the Cloud Spanner, Bigtable, and BigQuery architecture is This architecture pairs Google Cloud's premier managed storage engines to their exact workload strengths: **Cloud Spanner** for globally scalable relational transactions, **Cloud Bigtable** for high-throughput NoSQL time-series data, and **BigQuery** for serverless, petabyte-scale analytical querying. ### How it meets the requirements - **Workload 1 (Global ACID & Horizontal Scaling):** **Cloud Spanner** is a fully managed, globally distributed SQL database that provides external consistency and ACID transactions across regions while scaling compute and storage horizontally without downtime. - **Workload 2 (Low Latency IoT Time-Series at Scale):** **Cloud Bigtable** is a sparsely populated, distributed key-value store specifically optimized for large-scale time-series and IoT workloads. It scales linearly by adding nodes and provides sub-10ms read and write latencies for single-row key lookups. - **Workload 3 (Independent Storage and Compute Analytical Scaling):** **BigQuery** decouples compute (slots) from columnar storage (Google's distributed file system), allowing data to scale seamlessly to dozens of petabytes without provisioning dedicated cluster hardware. ### Key advantages and capabilities - **Independent compute and storage elasticity:** BigQuery allows storage volume to grow indefinitely without requiring extra computational resources until queries are executed. - **Linear NoSQL performance:** Bigtable clusters scale throughput linearly with node counts, supporting millions of requests per second with built-in autoscaling. - **Global relational scalability:** Spanner eliminates traditional single-primary bottlenecks while retaining full SQL support and multi-region replication. - **Operational efficiency:** All three platforms are fully managed, eliminating operating system maintenance and hardware lifecycle management. ### Why this is optimal This combination aligns each workload with a purpose-built system designed to support exponential data growth while maintaining predictable latencies, high availability, and optimal cost-performance trade-offs.

StudyCerts

Evaluating Google Cloud Storage Scalability Limits | Intrigued by the art of cloud architecture? Discover how to design, develop, and manage robust, secure, scalable, and dynamic solutions on Google Cloud as you prepare for the Professional Cloud Architect exam! | StudyCerts

Professional Cloud Architect

Intrigued by the art of cloud architecture? Discover how to design, develop, and manage robust, secure, scalable, and dynamic solutions on Google Cloud as you prepare for the Professional Cloud Architect exam!

Intermediate

Prepare and test your skills

Track Readiness

Set Exam Goal

Intermediate

Prepare and test your skills

Track Readiness

Set Exam Goal

Evaluating Google Cloud Storage Scalability Limits

Section: Data growth planning

Worked example. The correct answer is already marked and every option is explained below, so there is nothing to select here. To answer questions yourself, start the free trial.

An enterprise is planning its multi-year data architecture on Google Cloud to handle projected data growth across three critical business workloads:

Workload 1: A globally distributed transaction processing system that requires strict ANSI SQL compliance, ACID guarantees, and horizontal scaling across multiple regions.
Workload 2: A high-velocity IoT telemetry ingestion engine storing petabytes of single-keyed time-series events that requires predictable sub-10ms read and write latencies.
Workload 3: An enterprise data warehouse expected to scale storage to dozens of petabytes while dynamically allocating compute resources without manual cluster resizing.

Which combination of Google Cloud storage and database services best satisfies the scalability and architectural requirements of these workloads?

Workload 1: Cloud Spanner; Workload 2: BigQuery; Workload 3: Cloud Bigtable

Workload 1: Cloud SQL; Workload 2: Cloud Spanner; Workload 3: BigQuery

Workload 1: Cloud Bigtable; Workload 2: Cloud Spanner; Workload 3: Cloud Storage with external tables

Workload 1: Cloud Spanner; Workload 2: Cloud Bigtable; Workload 3: BigQuery

Professional Cloud Architect

Evaluating Google Cloud Storage Scalability Limits

Related questions