Simulado Google Cloud Professional Data Engineer

The correct option re-keys on a high-cardinality, evenly distributed value (order_id, optionally salted/hash-prefixed): because most writes share status 'PENDING', leading with order_status concentrates writes on a tiny set of key prefixes, so leading with order_id spreads writes across the key space and directly supports the required order_id lookup. The 'add more nodes' option is wrong because hot-spotting from a low-cardinality leading field concentrates load on specific tablets; extra nodes sit idle while the hot tablet stays saturated, so scaling out does not resolve the skew. The 'status#reverse_timestamp' option is wrong because it still leads with the low-cardinality status field — the root cause — so 'PENDING' writes remain clustered and hot regardless of timestamp ordering. The 'compress column families' option is wrong because compression reduces storage/IO size but does nothing to redistribute the key-space skew causing the write hotspot.

The Cloud Natural Language API is a Google pretrained API that returns sentiment and entity analysis out of the box with no training, which matches the requirement for minimal effort and no model building; orchestrating it from Dataflow or a scheduled pipeline writes the enrichment back to BigQuery for analysts. Training a BigQuery ML LOGISTIC_REG classifier 'from scratch on the unlabeled reviews' is wrong because logistic regression is supervised and requires labels, which the team does not have, and the task explicitly says training is not justified. Building and hosting a custom transformer on a GPU endpoint is the maximum-effort option and directly contradicts 'no model training' and 'minimal effort.' K-means clustering produces unlabeled groupings, not sentiment classes; calling a cluster a 'sentiment' is an unjustified leap, since clusters carry no positive/negative/neutral meaning.

Dataproc is correct because it is Google Cloud's managed Spark and Hadoop service, designed precisely for lift-and-shift of existing Hadoop/Spark/Hive/Oozie workloads and third-party ecosystem libraries; it preserves the open-source APIs so the proprietary HBase coprocessor and custom jobs run with minimal code changes. Dataflow is wrong because it requires rewriting all jobs into the Apache Beam programming model, which is a substantial re-engineering effort and contradicts the explicit 'minimal code changes / preserve existing APIs' constraint. BigQuery is wrong because it would force re-implementing all Spark and Hive logic as SQL and abandoning the Hadoop ecosystem libraries entirely, again violating the lift-and-shift requirement. Dataprep is wrong because it is a visual, interactive wrangling tool for non-programmatic data preparation and cannot host arbitrary custom Spark code, Oozie orchestration, or a proprietary HBase coprocessor.