You are architecting a data transformation solution for BigQuery. Your developers are proficient with SQL and want to use the ELT development technique. In addition, your developers need an intuitive

Question

Options

• AUse Dataform to build, manage, and schedule SQL pipelines.
• BUse Dataflow jobs to read data from Pub/Sub, transform the data, and load the data to BigQuery.
• CUse Data Fusion to build and execute ETL pipelines.
• DUse Cloud Composer to load data and run SQL pipelines by using the BigQuery job operators.

• A
  84% (31)
• B
  3% (1)
• C
  3% (1)
• D
  11% (4)

Explanation

Dataform (A) is purpose-built for ELT workflows in BigQuery - it lets developers write SQL with version control, dependency management, and scheduling, providing exactly the "SQL as code" environment the question describes.

Dataflow (B) is wrong because it uses Apache Beam (Java/Python), not SQL, and follows an ETL pattern where transformation happens outside the warehouse - the opposite of what ELT requires.

Data Fusion (C) is a visual ETL tool aimed at no-code/low-code pipelines; it emphasizes GUI-based development rather than SQL-as-code, and is ETL (not ELT) focused.

Cloud Composer (D) is an orchestration tool (managed Apache Airflow) for scheduling and coordinating workflows - it can trigger BigQuery jobs but doesn't provide a coding environment for building or managing SQL transformation logic.

Memory tip: Think of Dataform as "dbt on GCP" - if the question mentions BigQuery + ELT + SQL as code + developer-friendly, Dataform is always the answer. Any mention of streaming or Beam points to Dataflow; visual/GUI pipelines point to Data Fusion; pure orchestration points to Composer.

No community discussion yet for this question.