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.

• ✓

  BigQuery

  Why this is correct

  BigQuery is the correct choice because it is a serverless, highly scalable cloud data warehouse that supports standard ANSI SQL. It can query external datasets directly from Cloud Storage using external tables, where you define a table schema pointing to files (CSV, JSON, Parquet, Avro, ORC, etc.) without requiring an ETL pipeline. This makes it ideal for ad hoc SQL analysis on large datasets, since BigQuery automatically manages the underlying compute and parallelizes the query across the data, and you pay only for the data scanned. Additionally, BigQuery supports federated queries across other Google Cloud services, but querying Cloud Storage files is the most direct path for this scenario.

• ✗

  Dataflow

  Why it's wrong here

  Dataflow is wrong because it is a fully managed service for stream and batch data processing pipelines, not a SQL query engine for ad hoc analysis. It is designed around the Apache Beam programming model, where you write pipeline code (in Java, Python, or Go) to define transformations, and the service handles execution scaling and fault tolerance. While Dataflow can read from and write to Cloud Storage, you cannot simply issue a SQL query; you must specify the entire data flow logic as a pipeline graph, making it cumbersome for exploratory analytics. Furthermore, Dataflow's pricing is based on rental of processing workers and execution time, which is not suited for occasional or interactive queries.

• ✗

  Cloud SQL

  Why it's wrong here

  Cloud SQL is wrong because it is a managed relational database service supporting MySQL, PostgreSQL, and SQL Server, optimized for online transaction processing (OLTP) workflows. It does not have the capability to directly query external files stored in Cloud Storage without first importing that data into the database using tools like `gcloud sql import` or the console. Even if you imported the data, Cloud SQL has storage and query performance limitations compared to BigQuery, and its cost model charges for the database instance and persistent disk, making it expensive and inefficient for running large, ad hoc analytical queries over a data lake. Therefore, Cloud SQL is not the right tool for directly analyzing large external datasets.

• ✗

  Cloud Dataproc

  Why it's wrong here

  Cloud Dataproc is wrong because it is a managed Apache Spark and Hadoop service that requires provisioning a cluster of virtual machines before you can run any jobs. To run SQL queries, you would need to use Spark SQL or Hive, but you must first create the cluster, configure dependencies, and then submit jobs, which introduces startup latency and operational overhead that undermines the purpose of ad hoc analysis. Unlike BigQuery's serverless model, Dataproc bills for the cluster's uptime regardless of active queries, so keeping a cluster running just for occasional SQL is costly, and shutting it down adds delay for each new query. While Dataproc can process data in Cloud Storage via Spark's native connectors, it is not designed for direct interactive SQL querying and instead targets complex batch or streaming data processing workloads.

Go deeper

Related to this question