Alderquay Media wants one BigQuery dataset carrying both its Google Ads performance data and the daily CSV extracts its billing system writes to a Cloud Storage bucket under a dated prefix. Both feeds must refresh every morning with no command run by hand, using Google-managed transfers with visible run history rather than the data team's scripts. What should you do?
- A.
Create two BigQuery Data Transfer Service configurations into the dataset: one for the Google Ads source, and one for Cloud Storage using a wildcard URI, each on a daily schedule.
- B.
Create a BigQuery Data Transfer Service configuration for the Google Ads source, and use Database Migration Service to replicate the billing system's CSV extracts into the dataset.
- C.
Deploy a Cloud Run job that calls the Google Ads API and streams rows in with the Storage Write API, and create a Storage Transfer Service job whose sink is the BigQuery dataset.
- D.
Create one Storage Transfer Service job for both feeds, with the BigQuery dataset as its sink, so that the Google Ads export and the daily CSV extracts land together.
Show answer
Answer: A
BigQuery Data Transfer Service has managed connectors for both Google Ads and Cloud Storage, so two scheduled transfer configurations cover both feeds with no code.
- A. Google Ads and Cloud Storage are both first-party BigQuery Data Transfer Service connectors, and the Cloud Storage one accepts a wildcard URI, so two scheduled configurations cover both feeds with per-run history and no code.
- B. Database Migration Service migrates relational database instances; it has no notion of loading CSV files from a bucket into BigQuery.
- C. A custom Cloud Run job reimplements an existing managed connector, and Storage Transfer Service sinks are object stores, so it cannot load rows into a BigQuery table at all.
- D. Storage Transfer Service moves objects between storage systems and cannot write into BigQuery, and it has no Google Ads source at all.
