What the Google Cloud Professional Data Engineer exam covers
- Designing Data Processing Systems154 questions
- Ingesting and Processing the Data195 questions
- Storing the Data156 questions
- Preparing and Using Data for Analysis147 questions
- Maintaining and Automating Data Workloads178 questions
Free Google Cloud Professional Data Engineer practice test questions
A sample of 10 questions with answers and explanations. Sign up free to practice all 830.
-
Which service is a serverless, petabyte-scale data warehouse for analytics?
- ABigQueryCorrect
- BCloud SQL
- CBigtable
- DCloud Spanner
✓ Correct answer: ABigQuery is Google Cloud's serverless, petabyte-scale data warehouse specifically designed for analytics workloads. It provides fully managed SQL query capabilities with automatic scaling and no infrastructure management. BigQuery uses columnar storage and parallel execution to achieve fast analytical queries on massive datasets.
Why the other options are wrong- BCloud SQL is a managed relational database for transactional (OLTP) workloads, not a serverless petabyte-scale analytics warehouse.
- CBigtable is a wide-column NoSQL store for high-throughput key lookups, not a SQL analytics warehouse.
- DCloud Spanner is a globally distributed relational database optimized for transactional consistency, not petabyte-scale analytical queries.
-
An ETL pipeline loads data into BigQuery. The team currently streams every record individually, but the data only needs to be available within a few hours and load volume is huge. Which change reduces cost while meeting the latency requirement?
- AUse batch load jobs (free of per-row streaming charges) on a schedule instead of streaming insertsCorrect
- BSwitch the destination to an external BigLake table so records are read in place without any load cost
- CKeep streaming every record but enable exactly-once delivery to reduce the per-row ingestion charge
- DIncrease the number of parallel streaming insert clients so the same volume completes in less time
✓ Correct answer: ABigQuery's streaming inserts API charges per gigabyte of data streamed, which becomes expensive at high volumes. BigQuery batch load jobs - using LOAD DATA or the bq load command - are free of per-row ingestion charges and are simply billed for storage and any subsequent queries. For workloads that only need data available within hours, scheduling periodic batch loads replaces streaming at a fraction of the cost without violating the latency SLA.
Why the other options are wrong- BAn external table changes where data is read, not how it is ingested, and does not meet the ETL-into-BigQuery loading need.
- CExactly-once delivery improves correctness but does not remove per-row streaming charges, so cost stays high.
- DMore streaming clients increases throughput but keeps the same per-row streaming cost, so it does not reduce spend.
-
An external (BigLake) table over Parquet files in Cloud Storage returns stale results after new files were added. The metadata is cached. How do you ensure fresh results while keeping query performance benefits?
- DUse automatic metadata caching with an appropriate staleness interval (or manually refresh the cache)Correct
- ARecreate the external table with a new schema definition after every file upload to force a fresh scan
- BSwitch the table to a BigQuery-managed native table by loading the Parquet files, losing in-place querying
- CIncrease the BigQuery slot reservation so queries re-list the bucket faster on every execution
✓ Correct answer: DBigLake external tables cache metadata about the underlying Cloud Storage files to avoid expensive file listing on every query. When new files are added, the cache becomes stale until it refreshes. BigQuery's automatic metadata caching allows you to configure a staleness interval - the maximum age of cached metadata before it is refreshed - balancing query performance (fewer listings) against data freshness. You can also manually invalidate the cache using the bq command-line tool when immediate freshness is required.
Why the other options are wrong- ARecreating the external table on every upload is heavy operational overhead and unnecessary; tuning or refreshing the metadata cache achieves freshness without dropping and redefining the table.
- BLoading the Parquet files into native storage abandons the in-place query benefit of an external/BigLake table and adds ingestion cost.
- CAdding slot capacity affects query compute, not whether cached file metadata is stale; it does not control freshness.
-
A nightly Dataflow batch job intermittently fails with transient errors and, on the rare success, sometimes produces duplicate output rows in BigQuery when Composer retries the task. Which TWO changes make the pipeline resilient and idempotent? (Choose TWO)
- AMake the load idempotent via a staging table then MERGECorrect
- BConfigure bounded Airflow retries with exponential backoffCorrect
- CAppend every run with WRITE_APPEND and skip all dedup logic
- DSet Airflow retries to zero so the failing task never reruns
✓ Correct answer: A, BFor a nightly Dataflow batch job that intermittently fails and can produce duplicates on retry, two independent fixes are required: the load step must be made idempotent - using WRITE_TRUNCATE on a partition or a MERGE into the target so that rerunning produces the same result rather than appending extra rows - and the Airflow task must be configured with a bounded retry count plus exponential backoff so transient infrastructure errors are recovered automatically without operator intervention.
Why the other options are wrong- CAppending every run with WRITE_APPEND and no dedup logic makes duplicates worse on retries, not better - each retry appends another copy of the same rows.
- DSetting Airflow retries to zero means the pipeline cannot self-recover from transient errors and requires manual restarts for every failure.
-
An organization wants a fully managed, code-free environment where non-engineering analysts can visually design batch and streaming integration pipelines by dragging connectors and transforms, with built-in lineage and a broad plugin ecosystem (CDAP-based). Which service should they adopt?
- ACloud Data Fusion, a managed, graphical data integration service built on the open-source CDAP projectCorrect
- BDataform, a Git-versioned SQL transformation framework that builds curated tables inside BigQuery through code
- CCloud Composer, a managed Apache Airflow service that orchestrates task dependencies defined in Python DAGs
- DCloud Dataproc, managed Hadoop and Spark clusters for running distributed jobs written in Spark, Hive, or Pig
✓ Correct answer: ACloud Data Fusion is Google's fully managed, code-free integration service built on open-source CDAP. It offers a drag-and-drop UI for batch and streaming pipelines, a broad library of connectors and transforms, built-in lineage, and a plugin ecosystem usable by non-engineers, matching the no-code requirement.
Why the other options are wrong- BDataform is a code-based SQL transformation framework, not a code-free drag-and-drop pipeline designer for non-engineers.
- CCloud Composer orchestrates tasks via Python Airflow DAGs, not a visual, connector-based integration studio with a plugin ecosystem.
- DDataproc runs cluster-based Hadoop and Spark jobs that require coding, not a code-free graphical builder with built-in lineage.
-
A Datastream-to-BigQuery CDC pipeline from a MySQL source stops replicating, and the DBA reports that the database's binary logs were purged before Datastream could read them. Which preventive configuration avoids recurrence?
- AIncrease the binary log retention on the source so logs persist long enough for Datastream to consume themCorrect
- BDisable binary logging on the source database entirely so there are no binary logs left to be purged before Datastream reads them
- CSwitch the BigQuery destination from flat-rate to on-demand pricing so the replicated changes are ingested and acknowledged faster
- DReduce the Datastream connection profile to read-only credentials only so the source retains its purged binary logs for longer
✓ Correct answer: ADatastream reads MySQL replication by consuming the binary log (binlog). If the source database purges binlogs before Datastream processes them - due to a short retention window or high write volume - the replication stream breaks and a full backfill is required to resync. Increasing the binlog retention period (via expire_logs_days or binlog_expire_logs_seconds) ensures logs remain available until Datastream confirms it has consumed them, preventing the gap.
Why the other options are wrong- BDisabling binary logging removes the change stream entirely, so Datastream would have nothing to replicate at all, which is worse than premature purging.
- CBigQuery pricing affects the destination's query/compute cost, not how long the source retains binary logs, so it cannot prevent premature purging.
- DRead-only credentials are about access permissions and do not change the source's binary log retention, so purging would still occur.
-
You are choosing operational stores for two workloads. Workload A needs single-key lookups at over 200,000 QPS with petabyte scale and key-based access; Workload B needs globally consistent multi-row relational transactions with ANSI SQL. Which TWO selections correctly pair each workload to the right service? (Choose TWO)
- AWorkload A: Cloud BigtableCorrect
- BWorkload B: Cloud SpannerCorrect
- CWorkload A: Cloud Spanner
- DWorkload B: Cloud Bigtable
✓ Correct answer: A, BCloud Bigtable is the correct match for Workload A because it is engineered for single-key and key-range lookups at hundreds of thousands to millions of QPS with petabyte-scale storage and single-digit-millisecond latency, accessed by key rather than SQL. Cloud Spanner is the correct match for Workload B because it uniquely combines ANSI SQL, external strong consistency, and horizontally scalable globally distributed relational transactions - none of which Bigtable provides.
Why the other options are wrong- CPairing Workload A with Cloud Spanner is incorrect because Spanner is optimized for strongly consistent relational transactions rather than the raw single-key throughput of 200,000+ QPS at petabyte scale that defines Workload A.
- DPairing Workload B with Cloud Bigtable is incorrect because Bigtable does not support multi-row ACID transactions, ANSI SQL, or the relational consistency model that Workload B requires.
-
A scheduled BigQuery query that powers a daily executive dashboard reprocesses the entire 8 TB fact table every night, even though only the most recent day of records changes. The cost is high. Which design reduces cost while keeping results current?
- AUse partitioned tables and an incremental MERGE/INSERT that processes only the latest partition instead of the whole tableCorrect
- BSwitch the executive dashboard's output format from an interactive Looker Studio report to a static nightly PDF so the query runs against less data
- CAdd several more columns to the SELECT list so BigQuery improves its cache hit rate and re-reads the eight-terabyte fact table more cheaply each night
- DRun the identical full-table aggregation query twice each night for redundancy so a failed run does not require reprocessing the fact table again
✓ Correct answer: AWhen only the most recent day of data changes, reprocessing the entire 8 TB table nightly scans far more data than necessary. Partitioning the fact table by date and running an incremental MERGE or INSERT that targets only the latest partition reduces the bytes processed from terabytes to gigabytes, aligning cost with the actual data change volume while keeping the aggregated results current for the daily dashboard.
Why the other options are wrong- BChanging the dashboard format does not reduce the bytes scanned by the nightly query, which still reprocesses the whole table.
- CAdding columns increases bytes scanned and cost, and does not limit processing to the changed partition.
- DRunning the full query twice doubles cost rather than reducing it and still reprocesses the entire table.
-
A platform team needs to report, per BigQuery job, the total bytes processed, slot-milliseconds consumed, and the principal who ran each query over the last 30 days, using SQL that does not depend on parsing raw audit log text. Which source is the most direct and supported way to obtain this?
- AQuery the INFORMATION_SCHEMA.JOBS_BY_PROJECT view, which exposes job-level metadata such as total_bytes_processed, total_slot_ms, and user_emailCorrect
- BEnable Data Access audit logs and manually parse the protoPayload text fields in Cloud Logging to reconstruct per-job bytes and slot usage
- COpen the per-table Details tab in the BigQuery console and copy each job's bytes, slot time, and user by hand into a spreadsheet
- DExport billing data to a Cloud Storage bucket and aggregate the exported CSV files with a scheduled Dataflow batch job to compute usage totals
✓ Correct answer: AINFORMATION_SCHEMA.JOBS_BY_PROJECT exposes structured, queryable metadata for every job in a project - total_bytes_processed, total_slot_ms, user_email, creation_time, and status - via standard SQL with no log parsing, and it retains 180 days of history. It is the first-class source for SQL cost and usage reports.
Why the other options are wrong- BParsing protoPayload text from Data Access logs is error-prone and lacks the structured SQL interface JOBS_BY_PROJECT already provides.
- CCopying job statistics by hand from the console is not scalable or automatable and cannot produce a 30-day aggregated report.
- DBilling exports only carry cost dimensions, not per-job slot_ms or user attribution, and add pipeline latency versus a direct SQL query.
-
A globally distributed Bigtable application has two clusters in a single instance for high availability. Most requests originate near cluster A, but a nightly batch analytics job must run against the same instance without disturbing the low-latency serving traffic. What is the BEST way to configure routing so the batch job reads from cluster B while serving traffic stays on cluster A?
- APut both the serving API and the nightly batch job on one multi-cluster routing app profile so Bigtable automatically balances every request to the nearest available healthy cluster
- BCreate two single-cluster routing app profiles - one pinned to cluster A for serving and one pinned to cluster B for batch - and have each workload connect with its own profileCorrect
- CUse table-level cluster assignment to pin the serving table to cluster A and a second analytics table to cluster B so the two workloads are stored on physically separate clusters
- DSubmit the batch job with a lower request-priority QoS flag and let Bigtable automatically drain those low-priority scans onto whichever cluster in the instance is least loaded right now
✓ Correct answer: BBigtable app profiles decide which cluster serves a request. Single-cluster routing pins each profile to one named cluster, so a batch profile targets cluster B while a serving profile targets cluster A. Replication keeps both clusters holding the full dataset, so B's scans cannot steal CPU from A's low-latency reads.
Why the other options are wrong- AMulti-cluster routing sends each request to the nearest available cluster for latency and availability; it gives no isolation, so a heavy batch scan can still land on cluster A and hurt serving latency.
- CBigtable does not support pinning individual tables to specific clusters; every cluster in an instance replicates all tables, so you cannot store serving and batch on separate clusters this way.
- DThere is no QoS flag that auto-drains a workload to the least-loaded cluster; request priority can throttle low-priority requests but does not reroute traffic to a different cluster.
Who this Google Cloud Professional Data Engineer practice exam is for
This practice set is for anyone preparing for the Google Cloud Professional Data Engineer exam at the advanced level - from first-time candidates building a foundation to experienced Google practitioners doing a final review before test day. If you learn best by working through realistic questions and reading why each answer is right or wrong, it is built for you.
How to use this Google Cloud Professional Data Engineer practice exam
- Start with the free sample questions above to gauge your current baseline.
- Read the full explanation on every question, including why each wrong option is wrong.
- Track your weak domains and focus your study where you are losing the most marks.
- Once you are scoring consistently well, take a timed, full-length mock exam.
- Use your readiness score to decide when you are ready to book the real Google Cloud Professional Data Engineer exam.
Related Google resources
- Google Cloud Professional Data Engineer study guideKey concepts
- Google practice examsAll Google
- Certification pathWhere this fits
- Certification exam guides & tipsBlog
- Plans & pricingFree & paid
- How these questions are written and reviewedMethodology
- Report a problem with a questionCorrections
- Google Cloud Professional Machine Learning Engineer practice examRelated
- Google Cloud Professional Security Operations Engineer practice examRelated
- Associate Google Workspace Administrator practice examRelated
Google Cloud Professional Data Engineer practice exam FAQ
How many questions are in the Google Cloud Professional Data Engineer practice exam on CertGrid?
CertGrid has 830 practice questions for Google Cloud Professional Data Engineer, covering 5 exam domains. The real Google Cloud Professional Data Engineer exam is 50-60 qs in 120 min. CertGrid's timed mock is a fixed 50 questions.
What is the passing score for Google Cloud Professional Data Engineer?
Google does not publish a fixed passing score for this exam; CertGrid uses readiness scoring for practice. You have about 120 min to complete it. CertGrid tracks your readiness against the exam objectives so you know where to focus.
Are these official Google Cloud Professional Data Engineer exam questions?
No. CertGrid is an independent practice platform. We do not provide real or leaked exam questions. Our questions are original and designed to help you practice the concepts, scenarios, and difficulty style of the Google Cloud Professional Data Engineer exam.
Is there a free Google Cloud Professional Data Engineer practice test?
Yes. You can take a free Google Cloud Professional Data Engineer practice test straight away: a fixed set of 20 practice questions for this exam, retryable as often as you like, with no credit card required. You get readiness scoring and a weak-domain breakdown on those questions. Paid plans unlock the full 830-question bank, timed mock exams and full-bank domain analytics.
What CertGrid is (and is not)
CertGrid is an independent IT certification practice platform for Azure, AWS, Google, Cisco, Security, Linux, Kubernetes, Terraform, and other certification tracks. It provides objective-mapped practice questions, readiness scoring, weak-domain drills, and explanations to help learners understand what to study next.
Independent & original. CertGrid is an independent practice platform and is not affiliated with or endorsed by Google. Questions are original practice items designed to mirror certification concepts and exam style. CertGrid does not provide official exam questions or braindumps.