PDE - Ingesting and Processing Data (25% of the exam) - Section 2.1

Plan data pipelines by defining sources and sinks, transformation and orchestration logic, networking fundamentals, and data encryption requirements.

Define the sources, sinks, and transformation logic of a data pipeline, choosing between Pub/Sub for real-time event ingestion, Cloud Storage for batch inputs, and Dataflow for processing, and identify the networking and encryption requirements that constrain the design.

Pub/SubCloud StorageDataflowPipeline design

Practice question for this objective

Free sampleIngesting and Processing Datamedium

A regulated team is planning a Dataflow streaming pipeline that consumes Pub/Sub messages, transforms them, and writes to BigQuery. Compliance requires that data at rest, including intermediate state, is encrypted with keys the team controls and can rotate or disable on demand, while the team prefers not to manage key material directly on virtual machines. Which encryption approach best satisfies these requirements across Pub/Sub, Dataflow, and BigQuery?

ARely on default Google-managed encryption keys for Pub/Sub, Dataflow temporary state, and BigQuery, since all data at rest is encrypted by Google by default.
BUse customer-supplied encryption keys passed in each request to Pub/Sub, Dataflow, and BigQuery so the team holds the key bytes outside Google Cloud.
CEncrypt the message payloads in the publisher application before sending to Pub/Sub and decrypt them in BigQuery, leaving Dataflow blind to the contents.
DConfigure customer-managed encryption keys in Cloud KMS and apply them to the Pub/Sub topic, the Dataflow job's temporary storage, and the BigQuery destination dataset or table. Correct

Use Cloud KMS customer-managed encryption keys to control encryption at rest across Pub/Sub, Dataflow state, and BigQuery in a single pipeline. Customer-managed encryption keys held in Cloud KMS satisfy regulator requirements for key rotation and the ability to revoke access, without forcing the team to manage raw key material on workers. Pub/Sub topics, Dataflow job temporary storage, and BigQuery datasets each integrate with CMEK so the entire data path can be covered consistently.

Why A is wrong: Tempting because default encryption is always on, but it does not give the team the ability to rotate or disable the underlying key, which the compliance requirement explicitly demands.

Why B is wrong: Plausible because customer-supplied keys give the team possession of key material, but they are supported only on specific Cloud Storage operations, not on Pub/Sub, Dataflow state, or BigQuery, so this option does not cover the pipeline.

Why C is wrong: Application-layer encryption can supplement defence in depth, but it breaks Dataflow's ability to transform the data and does not address encryption of intermediate Dataflow state, so it does not solve the stated problem.

Why D is correct: Correct. Customer-managed encryption keys held in Cloud KMS let the team control rotation and disable access without managing raw key material, and CMEK can be applied to Pub/Sub topics, Dataflow temporary state, and BigQuery datasets or tables along the pipeline.

See more PDE practice questions, answers explained.

Exam traps in Ingesting and Processing Data

Answers that look right on this material and are not. Each one is a distractor from a different question in the PDE bank for this domain.

Rely on Google-managed encryption keys for Pub/Sub, Dataflow temporary storage, and BigQuery, and accept that revocation is handled internally by Google when the team requests it through a support case.
Why it is wrong: Google-managed keys encrypt data at rest by default, but the team cannot directly revoke the key on demand, so this configuration does not satisfy the stated control and revocation requirement even though it does cover encryption in transit.
Re-enable the previous key version so that workers can continue to decrypt objects that were written under the older version of the key.
Why it is wrong: Cloud KMS automatically uses the key version stored in each ciphertext's metadata for decrypt, so a disabled prior version is the actual problem only when the workload still references it. Re-enabling a disabled version is a workaround, not a fix, and conflicts with the team's rotation intent.
Use customer-supplied encryption keys provided per request to Pub/Sub, Dataflow, and BigQuery so that the key material never resides inside Google Cloud.
Why it is wrong: Customer-supplied encryption keys are accepted only by specific services such as Cloud Storage and Compute Engine for object and disk encryption. Pub/Sub, Dataflow state, and BigQuery do not support CSEK as a configuration option, so this approach cannot be applied end to end.

Examworthy is not affiliated with or endorsed by Google Cloud. Original, blueprint-aligned practice material only.