GCP Data Practitioner common mistakes
GCP Data Practitioner · Understand the traps and how to avoid them.
Choosing a load method based on the data's file format alone (for example, 'it is CSV, so use a load job') without checking whether the pipeline needs row-level transforms, streaming inserts, or near-real-time latency before the data lands in BigQuery.
Study material often presents load jobs, streaming ingestion, and the Storage Write API as interchangeable options, so candidates memorize format-to-tool mappings and skip the decision criteria: batch versus streaming, exactly-once needs, and whether transformation should happen before or after landing.
What to do instead
For every ingestion scenario, write down four attributes first: source type, batch or streaming, latency requirement, and whether data must be cleaned before landing. Then map those to a tool (batch load job, Storage Write API, Pub/Sub plus Dataflow, Datastream for CDC). Practice justifying the choice in one sentence that names the latency and transformation requirement.
Treating Dataflow and Dataproc as drop-in replacements for each other, or defaulting to Dataproc for a simple streaming transform because it is familiar, without evaluating whether the workload is a serverless Apache Beam pipeline or an existing Hadoop/Spark job that needs cluster-level control.
Both are 'processing' services in the candidate's mental model, and the exam's scenario wording can mention Apache Spark or Hadoop without making the migration constraint obvious. Candidates also underestimate Dataflow's autoscaling and exactly-once behavior as differentiators.
What to do instead
Build a two-column comparison you can reproduce from memory: Dataflow (Beam, serverless, autoscaling, streaming with windowing and exactly-once) versus Dataproc (managed Spark/Hadoop, cluster control, lift-and-shift of existing jobs, optional serverless Spark). When a question mentions existing Spark code or custom cluster tuning, lean Dataproc; when it mentions unbounded streams or no infrastructure management, lean Dataflow.
Reading a BigQuery query cost question and answering from the logical data volume ('the table has 2 TB, so the query scans 2 TB') instead of reasoning about partitioning, clustering, and selected columns, which determine bytes billed.
Candidates learn that BigQuery bills on bytes scanned but practice on small tables where the distinction never surfaces. They forget that a WHERE filter on the partition column prunes partitions, that clustering prunes blocks, and that SELECT * defeats column pruning.
What to do instead
For any cost or performance question, explicitly state which columns are selected and whether the filter touches the partition column or clustering keys. Practice the rule: partitioning limits data scanned by partition, clustering limits data scanned within partitions, and selecting fewer columns reduces bytes read. If a scenario filters on a non-partition column, the answer is usually 'no pruning' regardless of table size.
Confusing IAM roles with data-level access controls, for example granting bigquery.dataViewer at the project level to solve a 'this analyst must see only one column' requirement, or granting BigQuery Data Viewer when the user also needs to run jobs.
Role names sound granular, so candidates assume bigquery.dataViewer restricts rows or columns. In reality, row-level and column-level security come from policy tags, authorized views, or row access policies, while predefined roles control which operations are allowed on resources.
What to do instead
Separate the two layers in your notes: resource-level access (IAM predefined or custom roles such as BigQuery Data Viewer, BigQuery Job User, BigQuery Data Editor) versus data-level access (column policy tags via Data Catalog, authorized views, row access policies). For any access scenario, first ask 'is the restriction about which actions or which rows/columns?' and pick the layer accordingly.
Designing a Cloud Composer DAG that performs heavy data transformation inside Python operators on the Airflow worker instead of delegating to Dataflow, Dataproc, or BigQuery, then choosing that design as the correct answer for a large-volume pipeline question.
Candidates equate 'orchestration' with 'doing the work' and are drawn to a single DAG that appears to do everything. They also miss that Airflow operators should trigger and monitor services, not process terabytes on the scheduler's workers.
What to do instead
Adopt the rule that Composer orchestrates and managed services execute. When a scenario involves large data volumes, the correct architecture triggers Dataflow, Dataproc, or BigQuery jobs from the DAG and uses sensors or deferrable operators to wait. Reserve Python operators for lightweight coordination logic, branching, and calls to APIs.
Assuming Pub/Sub guarantees ordered, exactly-once delivery to subscribers by default, and selecting answers that rely on message order or duplicate-free delivery without configuring ordering keys or acknowledging the at-least-once model.
Pub/Sub is introduced as a messaging service, and candidates transfer assumptions from queue systems that preserve order. The default behavior is at-least-once delivery with no ordering guarantee unless ordering keys are set and the subscriber handles them.
What to do instead
Memorize the delivery contract: Pub/Sub is at-least-once by default, ordering requires an ordering key on publish plus ordered delivery enabled on the subscription, and exactly-once delivery is an opt-in subscription setting with caveats. For any pipeline question, design downstream processing to be idempotent and state explicitly whether ordering or deduplication is required.
Choosing a storage or warehouse service by name association ('logs go to Cloud Storage, analytics go to BigQuery') without checking access patterns such as frequent small updates, point lookups by key, or transactional writes that point to Cloud SQL, Spanner, or Bigtable.
Candidates memorize service taglines and skip the workload characteristics that actually drive the decision. The exam often describes an access pattern (high-throughput key lookups, multi-row transactions, time-series writes) rather than naming the workload type.
What to do instead
Create a decision table keyed on access pattern: analytical scans over large datasets (BigQuery), object storage for raw or archival data (Cloud Storage), wide-column low-latency key lookups at scale (Bigtable), relational OLTP with transactions (Cloud SQL or Spanner depending on scale and global consistency), and document storage (Firestore). For each practice scenario, underline the access-pattern phrase before answering.
Treating Data Catalog (Dataplex) as only a search UI and missing its role in column-level security through policy tags, or conversely assuming policy tags alone enforce access without IAM roles on the taxonomy and the data.
Data Catalog appears in study guides under discovery and metadata, so candidates do not connect it to access control. Policy tags are a separate concept layered on top of BigQuery schema definitions, and enforcement depends on both the tag and the IAM bindings.
What to do instead
Learn the policy-tag flow end to end: define a taxonomy and policy tags in Data Catalog, attach tags to BigQuery columns, grant fine-grained reader or data catalog roles to the intended principals, and rely on BigQuery to enforce masking or denial. Practice questions that ask 'who can see this column' by checking both the tag attachment and the IAM binding.
Ignoring data quality and schema evolution handling in ingestion designs, and selecting an answer that loads raw data directly into the warehouse without validation, dead-letter handling, or schema compatibility checks.
Candidates focus on getting data from A to B and treat validation as optional polish. Exam scenarios frequently include malformed records, changing schemas, or late-arriving data, and the correct answer usually includes a quarantine path or a schema policy.
What to do instead
Add a standard checklist to every ingestion answer: schema validation at ingest, a dead-letter or error table for rejected records, handling of late or duplicate data, and a defined schema evolution policy (for example, BigQuery schema update options or Avro/Protobuf compatibility modes). If an option lacks any failure path, treat it as suspect.
Answering monitoring and cost-management questions with generic 'enable logging' or 'set a budget' responses instead of naming the specific mechanisms: Cloud Monitoring alerts on job metrics, BigQuery INFORMATION_SCHEMA job history, Cloud Logging sinks, and budget alerts with programmatic notifications.
Operations content feels less technical, so candidates skim it and retain only vague impressions. The exam expects concrete service names and the specific resource each one observes.
What to do instead
Memorize a short operations map: Cloud Monitoring for metrics and alerting policies, Cloud Logging with sinks for audit and export, BigQuery INFORMATION_SCHEMA.JOBS for query cost and history, Cloud Billing budgets with Pub/Sub notifications for spend control, and Dataflow or Dataproc job metrics for pipeline health. Practice naming the exact resource and metric for each monitoring scenario.