Pass the Google Cloud Professional Data Engineer exam with an AI tutor

Partitioning on event_date lets BigQuery prune every partition outside the requested day, which is what eliminates the full-table scan and the cost. Clustering on user_id then sorts blocks within each daily partition, so the GROUP BY reads fewer blocks. Partitioning addresses the filter, clustering addresses the grouping — the two work together, and partition pruning is the change with the larger cost effect.

• B fails because clustering alone does not give you the guaranteed pruning that a date partition does; BigQuery can skip blocks but cannot skip whole partitions that do not exist.
• C fails because the workload is analytical aggregation over a day of data, not low-latency key lookups. Bigtable would make the GROUP BY harder and lose SQL analytics.
• D fails because materialized views help repeated identical aggregations but do not fix the underlying scan pattern, and per-team views multiply maintenance cost.

Dataproc is managed Spark and Hadoop, so existing Spark jobs and their Scala dependencies run largely unchanged — that is exactly the constraint the question sets. Ephemeral, per-job clusters keep the cost profile close to serverless because you pay only for the life of the job rather than for an idle long-running cluster.

• A fails on the constraint, not on the technology: rewriting 200 jobs into Beam is a large migration and directly violates 'minimal code change' within one quarter.
• C fails because complex Scala transformation logic with custom dependencies does not translate to SQL stored procedures, and much of it may not be expressible in SQL at all.
• D fails because you would be hand-rolling cluster coordination, shuffle, and resource management that Dataproc already provides for Spark.

VPC Service Controls creates a service perimeter that is evaluated independently of IAM. Even a caller holding valid credentials — including a leaked service account key — is denied when the request originates outside the perimeter's permitted ingress. That is precisely the 'valid permissions but wrong network' threat described.

• A fails because IAM roles govern who may act, not where the request comes from; a leaked key carries the role with it.
• B fails because CMEK controls the encryption key lifecycle. It lets you revoke access by disabling the key, but it does not restrict network origin for an otherwise-authorised caller.
• D fails because authorized views limit which columns and rows are exposed, not the network from which the query arrives.

A small baseline reservation covers the steady floor at committed rates, while autoscaling slots absorb the quarter-end burst and are billed only while they are in use. This matches spend to a bursty profile without setting a ceiling that would throttle analysts at peak.

• A fails because a commitment sized for the peak is idle most of the month, which is the expensive failure mode the question is asking you to avoid.
• C fails because per-user cost controls reduce spend by cutting people off — that caps throughput at quarter end, which the requirement forbids.
• D fails because Bigtable is not an analytical warehouse; ad-hoc aggregation over historical data would become slower and harder, not cheaper.

Analytics Hub shares data in place — the partner subscribes and queries live data without any copy leaving your project. Backing the listing with an authorized view means the partner sees only the curated columns and rows while the base tables remain inaccessible. That satisfies all three constraints at once.

• A fails because nightly extracts are copies, and they are stale by up to a day — the requirement is on-demand current data.
• C fails because dataViewer on the source dataset grants exactly the base-table access the question rules out.
• D fails on freshness, on the no-copy rule, and on basic data-governance grounds.

Dataflow deduplicates Pub/Sub messages using the message id, so supplying your own event_id as the id attribute makes publisher retries collapse into a single processed record inside the streaming pipeline. The duplicate never reaches the aggregation step, so the per-minute counts are correct at the point they are written.

• A fails because the acknowledgement deadline affects redelivery of unacknowledged messages, not duplicates that the publisher itself sent twice.
• B fails because ordering keys guarantee sequence, not uniqueness; ordered duplicates are still duplicates.
• D fails because it corrects the warehouse after the fact — the aggregates are already wrong when written, and anything read in the intervening hour is wrong too.