PDE Ingesting and Processing the Data 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.

• ✗

  Export data from Teradata to CSV files, upload to GCS using gsutil, then load into BigQuery.

  Why it's wrong here

  This works but requires manual steps and is less efficient than the dedicated transfer service.

• ✗

  Use Dataproc to run a Spark job that reads from Teradata and writes to BigQuery.

  Why it's wrong here

  A Spark job on Dataproc would read the entire 50 TB dataset into intermediate storage and then write it to BigQuery, introducing an unnecessary distributed processing layer that adds latency and resource overhead. This approach is tempting because Dataproc is often used for complex ETL transformations on large datasets, making it a correct choice when the data requires cleansing or reshaping before loading. However, for a one-time, high-bandwidth migration of raw historical data, a direct bulk load via the `bq` command-line tool or Storage Transfer Service avoids this intermediate processing, maximising throughput over the 10 Gbps link.

• ✗

  Use Transfer Appliance to ship the data offline.

  Why it's wrong here

  Transfer Appliance requires days for physical shipping and manual racking, which contradicts the "one-time migration" and "high-speed network connection" (10 Gbps) in the stem — a direct network load can complete 50 TB in under 12 hours. It is tempting because Transfer Appliance is designed for very large datasets (hundreds of TB to PB) or low-bandwidth links, where shipping a physical device is the only viable path.

• ✓

  Use BigQuery Data Transfer Service for Teradata

  Why this is correct

  This service automates the transfer from Teradata to BigQuery, handling schema and data types.

Go deeper

Related to this question