Examworthyexamworthy.comGoogle Cloud Professional Data Engineer cheat sheet
Google Cloud
Free to share. Examworthy is not affiliated with or endorsed by Google Cloud; PDE and related marks belong to their respective owners.
At a glance
Format: Multiple choice and multiple select, online- or onsite-proctored
Domain weight map
Heaviest first - spend your time hereHow this exam thinks
PDE is a pick-the-right-service exam: almost every question is a scenario with cost, latency, scale, and operational constraints, and the right answer is the Google Cloud service that fits them, usually the most managed option that meets the requirement.
Spot the trap
Tempting wrong answers, and why they failTempting but wrong
Calling the BigQuery Storage Read API from a ParDo for every incoming transaction is an efficient way to fetch the latest risk score.
Why it fails
Per-element remote calls add latency and quota pressure proportional to throughput, and they ignore the fact that the lookup is small and changes only every 15 minutes, making this both slower and more expensive than a side input.
Ingesting and Processing Data
Tempting but wrong
Detecting public bucket bindings via a Cloud Audit Logs sink and auto-revoking with a Cloud Function satisfies a central preventive control against public access.
Why it fails
Detection and remediation after the fact leaves a window where data is publicly accessible, and the requirement explicitly rules out an audit-driven approach in favour of central preventive enforcement.
Designing Data Processing Systems
Tempting but wrong
BigQuery is a wide-column NoSQL store optimised for single-row key lookups, while Bigtable is a columnar analytical warehouse for SQL scans.
Why it fails
This reverses the actual roles. BigQuery is the columnar analytical warehouse and Bigtable is the wide-column key-ordered NoSQL store, so this description swaps the two services. A candidate who only half-remembers the column orientation of BigQuery can fall into this trap.
Storing Data
Tempting but wrong
Every query against an Enterprise edition reservation incurs the same scale-up delay because baseline and autoscaler slots are both provisioned on demand.
Why it fails
Tempting because reservations feel elastic end to end, but baseline capacity is held continuously and is available without any scale-up; only the autoscaler portion above the baseline is provisioned on demand.
Maintaining and Automating Data Workloads
Tempting but wrong
BI Engine only accelerates queries issued through Looker Studio and ignores those from the console or bq.
Why it fails
Tempting because BI Engine was originally promoted as a Looker Studio accelerator. In practice acceleration is client-agnostic and applies to any SQL query that fits within the reservation's supported feature set, including queries from the BigQuery console, the bq command-line tool, drivers, and Looker.
Preparing and Using Data for Analysis
Tempting but wrong
Dataproc autoscaling on YARN pending memory can target both primary and secondary worker pools.
Why it fails
Dataproc autoscaling is supported only on secondary workers because primary workers participate in HDFS and removing them is unsafe, so a policy that targets the primary pool would be rejected or destabilise the cluster.
Ingesting and Processing Data
Tempting but wrong
With CMEK, the customer holds the key material outside Google Cloud and supplies it with each request, so the key never resides in Cloud KMS.
Why it fails
That description matches customer-supplied encryption keys for Cloud Storage. With CMEK the key material lives inside Cloud KMS and is referenced by its resource name, not supplied on every request.
Designing Data Processing Systems
Tempting but wrong
BigLake tables copy the underlying files into a managed Cloud Storage bucket owned by BigQuery, which is what unlocks fine-grained security.
Why it fails
BigLake does not copy the files; the data continues to live in the customer's Cloud Storage bucket and is read through a connection. Coupling fine-grained security to a hidden copy step is a believable but incorrect mental model.
Storing Data
Key terms
Exam-day rules
- Read the scenario for its constraint first. The cost, latency, scale, or operational-overhead limit named in the question is what picks the answer, so find it before you judge the options.
- When two services both work, default to the most managed one. Google prefers serverless and fully managed; reach for the less managed option only when the scenario names a reason, such as existing Spark or Hadoop code.
- Treat an existing open-source estate as a signal. Words like existing Spark, Hadoop, or Kafka usually point to Dataproc or a lift-and-shift answer over the otherwise obvious Dataflow or Pub/Sub choice.
- Let the access pattern pick the storage. Analytical SQL means BigQuery, low-latency key reads mean Bigtable, regional relational means Cloud SQL, global strong consistency means Spanner; do not default to the one you know best.
- Watch for the cost trap. When a question stresses minimising cost or predictable spend, the answer is usually the lever built for it: partitioning and clustering, on-demand versus Editions, or an ephemeral cluster over a persistent one.
Revision schedule
- Day 1Map the blueprint and book a date
- Week 1Build the service-selection map
- Weeks 1 to 3Go deep on ingesting and designing (Domains 2 and 1)
- Weeks 3 to 4Lock storage selection and BigQuery modelling (Domain 3)
- Week 4Cover analysis and operations (Domains 4 and 5)