Google Cloud Professional Data Engineer (PDE) practice questions

A retail analytics team ingests clickstream events into Pub/Sub and processes them with a Dataflow streaming pipeline that aggregates page views per user session, where a session ends after 20 minutes of inactivity. Sessions can run from seconds to several hours, and late events arrive up to 10 minutes behind the watermark. Which windowing strategy in Apache Beam should the team apply to compute one aggregate per logical session per user?

• AApply session windows with a gap duration of 20 minutes keyed by user, with allowed lateness of 10 minutes.check_circle Correct
• BApply fixed windows of 20 minutes keyed by user, with allowed lateness of 10 minutes and accumulating panes.
• CApply sliding windows of 20 minutes with a 1-minute period, with allowed lateness of 10 minutes.
• DApply global windows with an early trigger every 20 minutes, with allowed lateness of 10 minutes.

Why A is correct: Session windows are data-driven and group events for the same key whenever the gap between successive event timestamps is below the configured duration, producing exactly one window per logical session of activity.

Why B is wrong: Fixed windows split a long browsing session into arbitrary 20-minute buckets aligned to wall-clock time, so a single user session straddling a boundary is reported as two aggregates rather than one logical session.

Why C is wrong: Sliding windows emit overlapping aggregates and produce many panes per user, which is appropriate for moving averages but not for a one-aggregate-per-session contract because each event belongs to multiple windows.

Why D is wrong: The global window groups all events into a single window per key and relies on triggers for emission, which cannot express the inactivity-gap semantics of a session and would mix events from unrelated sessions.

An architect is comparing BigQuery and Bigtable for a workload that records device telemetry from two million industrial sensors. Each sensor emits a reading every second, and downstream applications need to retrieve the most recent 24 hours of readings for any single sensor within tens of milliseconds, while a separate weekly analytical job scans aggregates across the full fleet. The architect wants to understand the fundamental role boundary between the two services. Which statement most accurately describes how BigQuery and Bigtable differ for this workload?

• ABigtable is a wide-column NoSQL store with sorted row keys that gives single-digit millisecond reads for a known key, while BigQuery is a columnar analytical warehouse designed for high-throughput scans across very large tables; the per-sensor lookup belongs in Bigtable and the weekly aggregate belongs in BigQuery.check_circle Correct
• BBigQuery is a wide-column NoSQL store optimised for single-row lookups by key, while Bigtable is a columnar analytical warehouse tuned for ad hoc SQL scans, so the per-sensor lookups should target BigQuery and the weekly aggregate should target Bigtable.
• CBigQuery and Bigtable both target operational workloads, but BigQuery is preferred whenever rows exceed one kilobyte and Bigtable is preferred whenever rows are smaller, regardless of access pattern.
• DBigtable and BigQuery are interchangeable for telemetry because both are columnar; the team should pick the cheaper one for the region and accept identical latency characteristics from each service.

Why A is correct: Bigtable is sorted by row key and serves point and small range reads in low single-digit milliseconds, which suits the per-sensor 24-hour lookup, while BigQuery's columnar storage and slot-based execution are designed to scan and aggregate across very large tables on schedule, which suits the weekly cross-fleet job.

Why B is wrong: This reverses the actual roles. BigQuery is the columnar analytical warehouse and Bigtable is the wide-column key-ordered NoSQL store, so the description swaps the two services. A candidate who only half-remembers the column orientation of BigQuery can fall into this trap.

Why C is wrong: BigQuery is an analytical warehouse, not an operational store, and the selection between Bigtable and BigQuery is driven by access pattern rather than row size. The size-based rule sounds concrete but is fabricated and will mislead a candidate who has not internalised the role boundary.

Why D is wrong: Although both services use a column-oriented physical layout, their access patterns and latency profiles are very different. Bigtable serves low-latency keyed reads while BigQuery serves throughput-oriented scans, so they are not interchangeable for a real-time per-sensor lookup.

A data platform team grants an analyst the BigQuery Data Viewer role at the project level so the analyst can query several datasets. The team now wants the analyst to read only tables whose names start with the prefix sales_ in one specific dataset, without creating a new custom role and without changing the analyst's existing project-level grants. Which approach achieves this most precisely?

• AAdd a deny policy at the project level that denies BigQuery read permissions on tables whose name does not start with sales_, attached to the analyst's principal.
• BRemove the project-level BigQuery Data Viewer grant and instead grant BigQuery Data Viewer on every individual table whose name starts with sales_ in the target dataset.
• CAdd an IAM condition to the analyst's BigQuery Data Viewer binding that uses resource.name.startsWith with the table path prefix for sales_ tables in the target dataset.check_circle Correct
• DCreate an authorised view in a separate dataset that selects from the sales_ tables, and grant the analyst BigQuery Data Viewer on that dataset only.

Why A is wrong: Deny policies can restrict permissions but cannot match BigQuery table names with a startsWith expression on a resource attribute, so the negation cannot be authored cleanly and would block far more than the intended tables.

Why B is wrong: Per-table grants would work but the requirement is to leave existing project-level grants in place, and managing one binding per table does not scale as new sales_ tables are created over time.

Why C is correct: IAM conditions on a role binding evaluate CEL expressions against request and resource attributes, and resource.name.startsWith on the BigQuery table path is the documented pattern for restricting access to tables matching a name prefix.

Why D is wrong: Authorised views are useful for column or row filtering but they require maintaining one view per table or a union view, and they do not transparently expose the underlying sales_ tables to ad hoc queries by name.