Free PDE flashcards

When session boundaries are defined by gaps in user activity rather than fixed wall-clock intervals, which Beam windowing strategy should you choose?

Beam session windows are created dynamically per key from the inactivity gap between event timestamps. A new event within the configured gap extends the existing window for that key; otherwise a new session opens. This yields one aggregate per logical user session of any duration, and allowed lateness keeps window state alive long enough to absorb late events.

Calling the BigQuery Storage Read API from a ParDo for every incoming transaction is an efficient way to fetch the latest risk score.

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.

How do you scope an existing IAM role binding to a subset of resources, like only BigQuery tables with a given name prefix, without creating a custom role?

Attach an IAM condition (a CEL expression) to the existing role binding. For BigQuery, resource.name.startsWith on the full table path is the supported attribute for prefix matching, so the role becomes effective only on tables whose path begins with the chosen prefix while the rest of the project-level grant remains unchanged.

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.

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.

How do Bigtable and BigQuery differ in role when serving per-sensor recent telemetry lookups versus weekly fleet-wide aggregations?

Bigtable stores rows sorted by a single row key and is engineered for low-latency point and small range reads at very high write rates, which suits the per-sensor recent-history pattern. BigQuery stores data in columnar format across distributed storage and uses a slot-based execution engine that excels at scanning and aggregating across large tables, which is the weekly fleet-wide pattern. Each service is chosen for the access pattern it was built for.

BigQuery is a wide-column NoSQL store optimised for single-row key lookups, while Bigtable is a columnar analytical warehouse for SQL scans.

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.

How do baseline and autoscaler slot settings in a BigQuery Editions reservation affect query start latency and billing?

Baseline slots are reserved continuously and available with no scale-up delay, so queries that fit within them start immediately. When demand exceeds the baseline, the autoscaler adds slots in increments up to the configured maximum; those autoscaler slots take a short time to provision and are billed per second only while active, which is why a zero-baseline reservation makes small ad hoc queries wait.

Every query against an Enterprise edition reservation incurs the same scale-up delay because baseline and autoscaler slots are both provisioned on demand.

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.