Practice exam · GCP
Google Cloud Professional Data Engineer practice exam
Short answer
The Google Cloud Professional Data Engineer practice exam has 50 questions in 120 minutes, with a 70% passing mark, as configured here. The fastest way to know whether you are ready is to sit a full exam on the clock and read your score by domain, not only the total.
Domains covered
- Ingesting and Processing the Data
- Preparing and Using Data for Analysis
- Designing Data Processing Systems
- Maintaining and Automating Data Workloads
- Storing the Data
Sample questions, with explanations
Three questions from the bank, open to read.
A Cloud Bigtable table stores e-commerce orders. The current row key is order_status#timestamp (e.g., 'PENDING#1718000000'). Most new orders are created with status 'PENDING', and the primary write path is order creation. The team observes severe write hot-spotting and uneven node CPU. They cannot change the access pattern of looking up orders by order_id. What is the best remediation?
- Add more Bigtable nodes so the PENDING workload is spread across additional CPUs
- Redesign the row key to lead with a well-distributed field such as a hash-prefixed order_id (e.g., '<salt>#order_id'), since order_status is low-cardinality and a few values dominate writes ✓ (correct)
- Switch the key to status#reverse_timestamp so the newest pending orders sort first
- Keep order_status as the leading field but compress the column families to reduce per-node load
Why this is correct
The correct option re-keys on a high-cardinality, evenly distributed value (order_id, optionally salted/hash-prefixed): because most writes share status 'PENDING', leading with order_status concentrates writes on a tiny set of key prefixes, so leading with order_id spreads writes across the key space and directly supports the required order_id lookup. The 'add more nodes' option is wrong because hot-spotting from a low-cardinality leading field concentrates load on specific tablets; extra nodes sit idle while the hot tablet stays saturated, so scaling out does not resolve the skew. The 'status#reverse_timestamp' option is wrong because it still leads with the low-cardinality status field — the root cause — so 'PENDING' writes remain clustered and hot regardless of timestamp ordering. The 'compress column families' option is wrong because compression reduces storage/IO size but does nothing to redistribute the key-space skew causing the write hotspot.
A media company ingests thousands of user-submitted product reviews per hour into BigQuery. The data team wants to enrich each review with sentiment (positive/negative/neutral) and detected entities, with minimal effort and no model training, then store the enrichment back in BigQuery for analysts. The volume and quality requirements do not justify building or fine-tuning a custom NLP model. What is the most appropriate approach?
- Train a BigQuery ML LOGISTIC_REG sentiment classifier from scratch on the unlabeled reviews
- Call the Cloud Natural Language API (a pretrained API) from a Dataflow or scheduled pipeline to add sentiment and entity columns to the BigQuery table ✓ (correct)
- Build a custom transformer model on Vertex AI Training and host it on a dedicated GPU endpoint
- Use a BigQuery ML KMEANS model to cluster reviews and treat each cluster as a sentiment label
Why this is correct
The Cloud Natural Language API is a Google pretrained API that returns sentiment and entity analysis out of the box with no training, which matches the requirement for minimal effort and no model building; orchestrating it from Dataflow or a scheduled pipeline writes the enrichment back to BigQuery for analysts. Training a BigQuery ML LOGISTIC_REG classifier 'from scratch on the unlabeled reviews' is wrong because logistic regression is supervised and requires labels, which the team does not have, and the task explicitly says training is not justified. Building and hosting a custom transformer on a GPU endpoint is the maximum-effort option and directly contradicts 'no model training' and 'minimal effort.' K-means clustering produces unlabeled groupings, not sentiment classes; calling a cluster a 'sentiment' is an unjustified leap, since clusters carry no positive/negative/neutral meaning.
An enterprise is migrating an on-premises Hadoop ecosystem to Google Cloud. The existing platform relies on custom Apache Spark and Hive jobs, Oozie workflows, and several third-party Hadoop ecosystem libraries (including a proprietary HBase coprocessor) that the team must keep running with minimal code changes. They want to lift-and-shift these jobs to a managed service while preserving the open-source APIs they already use. Which processing service is the most appropriate choice?
- Dataprep, by recreating each Spark transformation as a visual wrangling recipe
- Dataflow, by rewriting all Spark and Hive jobs into Apache Beam pipelines before migration
- BigQuery, by importing all data and rewriting the Spark and Hive logic as SQL
- Dataproc, because it runs managed Spark and Hadoop and supports existing Spark/Hive jobs and ecosystem libraries with minimal modification ✓ (correct)
Why this is correct
Dataproc is correct because it is Google Cloud's managed Spark and Hadoop service, designed precisely for lift-and-shift of existing Hadoop/Spark/Hive/Oozie workloads and third-party ecosystem libraries; it preserves the open-source APIs so the proprietary HBase coprocessor and custom jobs run with minimal code changes. Dataflow is wrong because it requires rewriting all jobs into the Apache Beam programming model, which is a substantial re-engineering effort and contradicts the explicit 'minimal code changes / preserve existing APIs' constraint. BigQuery is wrong because it would force re-implementing all Spark and Hive logic as SQL and abandoning the Hadoop ecosystem libraries entirely, again violating the lift-and-shift requirement. Dataprep is wrong because it is a visual, interactive wrangling tool for non-programmatic data preparation and cannot host arbitrary custom Spark code, Oozie orchestration, or a proprietary HBase coprocessor.
Take the full practice exam
- 50 questions drawn from the bank, with a 120-minute timer
- Score by domain and a review of every question
- An AI tutor to talk through each question you miss
- What you miss feeds your study plan
Independent, unofficial practice exam. GCP and the exam name are trademarks of their owners; UpSkillScore is not affiliated with them. Format and passing mark are the exam's configuration in UpSkillScore, not an official statement.
Frequently asked questions
How many questions does the Google Cloud Professional Data Engineer practice exam have?
It has 50 questions and a 120-minute limit. The passing mark of the practice exam is 70%.
Is this the official Google Cloud Professional Data Engineer exam?
No. It is an independent practice exam built to match the structure of the real one. It does not replace the official exam.
Do I need an account to take it?
You can read the structure and sample questions without an account. Taking the full timed exam, scoring by domain and the AI tutor need one.