Google Professional Data Engineer PDE Questions 676–747 | Page 10/10

676

MCQeasy

You need to orchestrate a simple, linear workflow that calls several Cloud Functions and API endpoints sequentially with conditional logic. The workflow should be defined as code and have minimal overhead. Which GCP service should you use?

A.Cloud Tasks

B.Workflows

C.Dataflow

D.Cloud Composer

AnswerB

Workflows orchestrates sequential steps with conditional branching, defined declaratively in YAML or JSON, and natively invokes Cloud Functions and HTTP endpoints. This satisfies the stem's need for a linear, code-defined workflow with minimal operational overhead.

Why this answer

Workflows is a serverless orchestration service that uses YAML/JSON to define workflows. It is ideal for simpler, linear or conditional orchestrations without the need for full Airflow infrastructure.

Full explanation →

677

Multi-Selectmedium

A company is migrating an on-premises PostgreSQL database to Google Cloud. They need a fully managed database that is compatible with PostgreSQL and can handle both transactional and analytical workloads with high performance. Which two database services meet these requirements? (Choose TWO.)

Select 2 answers

A.Cloud Spanner

B.Cloud SQL for PostgreSQL

C.BigQuery

D.AlloyDB

E.Firestore

AnswersB, D

Fully managed, PostgreSQL-compatible, supports OLTP and some analytical queries.

Why this answer

Cloud SQL for PostgreSQL (B) is correct because it is a fully managed service that runs the native PostgreSQL engine, so it is directly compatible with the on-premises PostgreSQL database and supports transactional (OLTP) workloads. AlloyDB (D) is also correct because it is a fully managed, PostgreSQL-compatible database engine that is specifically designed for high-performance transactional workloads while also accelerating analytical queries through its columnar engine, making it well suited to mixed transactional and analytical use. Cloud Spanner (A) is not the right fit here because, although it is fully managed and highly scalable, it is not PostgreSQL-compatible in the native sense and is aimed at globally distributed OLTP rather than this migration scenario.

BigQuery (C) is a fully managed analytical data warehouse optimized for OLAP, not a PostgreSQL-compatible transactional database. Firestore (E) is a fully managed NoSQL document database and is neither PostgreSQL-compatible nor designed for the transactional/analytical mix described.

Exam trap

Google often tests the distinction between general-purpose managed databases (Cloud SQL) and specialized high-performance databases (AlloyDB), and the trap here is that candidates may think BigQuery or Spanner are PostgreSQL-compatible because they support SQL, but they do not support the PostgreSQL dialect or transactional workloads natively.

Full explanation →

678

MCQmedium

A data engineer is designing a BigQuery table to store customer order records. Queries frequently filter by order_date and customer_id, and the dataset grows by about 5 TB per day. The engineer wants to minimize query cost and improve performance for these filtered queries. What should the engineer do?

A.Create a materialized view that pre-aggregates orders by customer_id and order_date.

B.Enable BigQuery BI Engine and reserve memory for the dataset.

C.Partition the table by order_date and cluster by customer_id.

D.Use a wildcard table over daily sharded tables named orders_YYYYMMDD.

AnswerC

Partitioning by order_date allows BigQuery to prune partitions when queries filter on that column, reducing bytes scanned and cost. Clustering by customer_id further sorts data within each partition, improving filter and aggregation performance for customer-specific queries. This combination directly addresses the access patterns described and is the recommended approach for large, time-series-like datasets with common filter columns.

Why this answer

Partitioning by order_date enables partition pruning, so queries with date filters scan only relevant partitions, cutting cost and improving speed. Clustering by customer_id sorts data within partitions, making customer-filtered queries more efficient. Together they match the described query patterns and scale well with daily 5 TB loads, unlike materialized views, wildcard tables, or BI Engine, which do not address base-table scan efficiency.

Exam trap

The trap here is assuming that a materialized view or BI Engine can replace partitioning and clustering for reducing scan cost on large base tables.

Full explanation →

679

MCQmedium

A data engineer uses Cloud Composer to orchestrate a daily batch pipeline. A downstream task should only start after an upstream BigQuery load job finishes successfully and a specific file appears in Cloud Storage. Which combination of operators should the engineer use in the Airflow DAG?

A.BigQueryInsertJobOperator with wait_for_downstream=True

B.BigQueryInsertJobOperator and GCSObjectExistenceSensor with upstream dependency

C.DataflowPythonOperator and GCSObjectExistenceSensor

D.BigQueryOperator and FileSensor with downstream dependency

AnswerB

BigQueryInsertJobOperator runs the load job, while GCSObjectExistenceSensor pokes Cloud Storage until the file appears. Setting the sensor as an upstream dependency forces the downstream task to wait for both the successful load and the file's arrival, satisfying the dual trigger condition.

Why this answer

The engineer needs a BigQuery load job to finish successfully and a specific file to appear in Cloud Storage before a downstream task starts. The correct combination is BigQueryInsertJobOperator to run and wait for the BigQuery job, and GCSObjectExistenceSensor to check for the file, with the sensor set as an upstream dependency of the downstream task. This ensures both conditions are met before proceeding.

Exam trap

The trap is assuming that a single operator can handle both conditions or that wait_for_downstream covers external dependencies; candidates must recognize the need for a separate sensor and correct dependency direction.

How to eliminate wrong answers

Option A is wrong because BigQueryInsertJobOperator with wait_for_downstream=True only ensures downstream tasks wait for the BigQuery job, but it does not check for the file in Cloud Storage. Option C is wrong because DataflowPythonOperator is for Dataflow jobs, not BigQuery load jobs, and it lacks the file sensor. Option D is wrong because BigQueryOperator is deprecated in favor of BigQueryInsertJobOperator, and FileSensor checks local filesystem, not Cloud Storage; also the dependency direction is misstated.

Full explanation →

680

MCQmedium

You are designing a Dataflow pipeline that joins two unbounded PCollections from different sources. Which transform should you use?

A.ParDo

B.Flatten

C.CoGroupByKey

D.GroupByKey

AnswerC

CoGroupByKey performs a relational join of two or more PCollections sharing a common key type, emitting grouped values per key. It is the designated transform for joining unbounded PCollections, unlike side inputs or per-element lookups that cannot correlate streams.

Why this answer

CoGroupByKey performs a key-based join of multiple PCollections. It can handle unbounded streams with appropriate windowing.

Full explanation →

681

MCQhard

You are designing a streaming pipeline that must handle late-arriving data with a maximum lateness of 10 minutes. You need to ensure that all data is processed exactly once and that results are emitted after the watermark passes the window. Which Apache Beam concept should you use to achieve this?

A.Use sliding windows with a period of 10 minutes and a trigger that fires when the watermark passes the end of the window.

B.Use a global window with a trigger that fires every 10 minutes.

C.Use session windows with a gap duration of 10 minutes and a trigger that fires on every element.

D.Use fixed windows with allowed lateness set to 10 minutes and a trigger that fires when the watermark passes the end of the window.

AnswerD

Setting allowed lateness to 10 minutes on fixed windows ensures that late data up to 10 minutes is not dropped. A trigger that fires when the watermark passes the end of the window emits results only after the watermark indicates all on-time data has arrived, satisfying the requirement.

Why this answer

Fixed windows with allowed lateness of 10 minutes and a watermark-based trigger ensure that data arriving up to 10 minutes late is included, and results are emitted only after the watermark passes the window end, meaning all on-time data has arrived. This combination provides exactly-once processing semantics when used with a runner that supports it.

Exam trap

The trap here is confusing processing-time triggers with event-time watermarks; only watermark-based triggers respect event-time completeness and allowed lateness.

Full explanation →

682

MCQhard

A company wants to use BigQuery's PIVOT operator to transform their sales data. They have a table with columns: 'year', 'quarter', 'revenue'. They want to create a report where each row is a year and each column is a quarter (Q1, Q2, Q3, Q4) showing revenue. Which SQL statement is correct?

A.SELECT * FROM sales PIVOT(SUM(revenue) FOR quarter IN ('Q1','Q2','Q3','Q4'))

B.SELECT * FROM sales PIVOT(revenue FOR quarter IN (Q1, Q2, Q3, Q4))

C.PIVOT sales ON quarter USING SUM(revenue)

D.SELECT * FROM (SELECT year, quarter, revenue FROM sales) PIVOT(SUM(revenue) FOR quarter IN (Q1, Q2, Q3, Q4))

AnswerA

PIVOT aggregates revenue with SUM, grouping by the remaining column (year) and spreading quarter values into Q1–Q4 columns, exactly matching the required year-per-row, quarter-per-column report. The IN list supplies the literal quarter values to become column headers, so no explicit GROUP BY is needed.

Why this answer

BigQuery's PIVOT operator requires an aggregate function applied to the value column, followed by FOR <pivot_column> IN (<list of values>). Option A correctly uses SUM(revenue) as the aggregate, FOR quarter to specify the pivot column, and IN ('Q1','Q2','Q3','Q4') with quoted string literals. The remaining columns (year) automatically become the grouping keys, producing one row per year with Q1–Q4 as columns.

Exam trap

PDE often tests whether candidates remember that BigQuery PIVOT requires an aggregate function and quoted string literals in the IN list — many candidates pick the option that looks like Oracle/SQL Server PIVOT syntax (ON/USING) or forgets the aggregate entirely.

How to eliminate wrong answers

Option B is wrong because it omits the aggregate function — PIVOT requires an aggregate like SUM, AVG, or COUNT around the value column, and it also uses unquoted identifiers (Q1, Q2) instead of string literals. Option C is wrong because 'PIVOT sales ON quarter USING SUM(revenue)' is not valid BigQuery SQL syntax — it resembles Oracle/SQL Server PIVOT syntax and BigQuery does not support the ON/USING clause form. Option D is wrong because wrapping the source in a subquery is unnecessary and, more importantly, the subquery selects only year, quarter, and revenue but the outer PIVOT still requires the same aggregate syntax — the extra subquery adds no value and the statement is functionally redundant rather than the canonical correct form.

Full explanation →

683

MCQhard

You are designing a Dataflow pipeline that reads from Pub/Sub and writes to BigQuery. Some incoming messages are malformed and fail to parse. How should you handle these messages to ensure the pipeline continues processing without data loss?

A.Configure Pub/Sub to retry indefinitely until the message is processed

B.Use a try-catch block in the pipeline and ignore malformed messages

C.Write malformed messages to a dead-letter sink (e.g., Pub/Sub topic or GCS) and continue processing

D.Set the pipeline to fail and alert the team via Cloud Monitoring

AnswerC

Routing unparseable records to a dead-letter sink isolates them from the main pipeline, so a single malformed message cannot halt processing or be silently dropped. This satisfies the no-data-loss constraint by preserving failures for later inspection while valid messages continue to BigQuery.

Why this answer

Writing malformed messages to a dead-letter sink (Pub/Sub topic or GCS) preserves the data for later inspection while allowing the pipeline to continue processing valid messages. This is the standard Dataflow/Apache Beam pattern for handling unparseable records without halting the stream or silently discarding data. It satisfies both the 'no data loss' and 'continue processing' requirements.

Exam trap

PDE often tests the misconception that Pub/Sub retry or pipeline failure is an acceptable error-handling strategy — candidates forget that retries cannot fix deterministic parse failures and that failing the pipeline violates availability requirements.

How to eliminate wrong answers

Option A is wrong because Pub/Sub itself cannot parse or validate message content — retrying indefinitely just redelivers the same malformed payload forever, causing a poison-pill loop and blocking the subscription. Option B is wrong because silently ignoring malformed messages causes data loss and removes any audit trail for troubleshooting. Option D is wrong because failing the entire pipeline halts processing of all valid messages, violating the requirement that the pipeline continue processing.

Full explanation →

684

MCQeasy

A data engineer needs to schedule recurring nightly loads from Amazon S3 to Google Cloud Storage. The data is in CSV format and the volume is approximately 500 GB per night. Which Google Cloud service should they use?

A.Transfer Appliance

B.Storage Transfer Service

C.BigQuery Data Transfer Service

D.Datastream

AnswerB

Storage Transfer Service performs server-side, managed transfers between object stores, including S3 to Cloud Storage, and handles scheduling, retries and 500 GB nightly volumes without compute provisioning. CSV format is irrelevant since it copies objects verbatim.

Why this answer

The Storage Transfer Service is designed for online data transfers from external cloud providers like Amazon S3 to Google Cloud Storage. It supports scheduling recurring nightly transfers, handles large volumes (500 GB/night), and automatically retries failed transfers, making it the correct choice for this use case.

Exam trap

Google often tests the distinction between services that transfer data to Cloud Storage (Storage Transfer Service) versus services that load data directly into BigQuery (BigQuery Data Transfer Service), causing candidates to confuse the destination.

How to eliminate wrong answers

Option A is wrong because Transfer Appliance is a physical device for offline data transfer, used for very large datasets (hundreds of TB to PB) where network transfer is impractical, not for recurring nightly loads. Option C is wrong because BigQuery Data Transfer Service is for loading data into BigQuery tables from sources like Google Ads or Amazon S3, but it does not directly transfer files to Cloud Storage; it loads data into BigQuery, not Cloud Storage. Option D is wrong because Datastream is for real-time change data capture (CDC) from databases like MySQL or PostgreSQL to BigQuery or Cloud Storage, not for batch CSV file transfers from S3.

Full explanation →

685

MCQeasy

A data engineer must give a Dataproc Serverless for Spark batch workload permission to read objects from a specific Cloud Storage bucket and write to a BigQuery dataset, following least privilege. The workload runs as a custom service account. Which approach should be used?

A.Grant the workload's service account `roles/storage.objectViewer` on the bucket and `roles/bigquery.dataEditor` on the dataset.

B.Grant the workload's service account the basic `roles/editor` role on the project so both Cloud Storage and BigQuery calls succeed.

C.Enable the Cloud Storage and BigQuery APIs and rely on the default Compute Engine service account attached to the Dataproc Serverless workload.

D.Create a VPC Service Controls perimeter around the bucket and dataset and add the workload's service account to the access level.

AnswerA

Attaching IAM roles at the bucket and dataset level scopes permissions to exactly the resources the Spark workload touches. `roles/storage.objectViewer` permits reading objects without delete or create rights, and `roles/bigquery.dataEditor` allows writing data while excluding dataset administration. This satisfies least privilege for a Dataproc Serverless workload running as a custom service account.

Why this answer

Least privilege in Google Cloud means binding predefined or custom roles to the narrowest resource scope that still satisfies the workload. Bucket-level object viewer and dataset-level data editor grant precisely the read and write operations the Spark job requires. Broad project roles, default service accounts, and perimeter controls either overshoot the needed permissions or fail to grant them at all.

Exam trap

The trap here is treating VPC Service Controls or basic project roles as substitutes for scoped IAM bindings, when perimeter policies only constrain access and basic roles grant far more than the workload needs.

Full explanation →

686

MCQeasy

A company wants to analyze server logs stored in Cloud Storage using SQL. They need to get results in seconds without setting up any clusters. Which service should they use?

A.Cloud Dataflow

B.Cloud Logging

C.BigQuery

D.Cloud Dataproc

AnswerC

BigQuery queries Cloud Storage logs directly through its federated external-table capability, returning SQL results in seconds via serverless, automatically provisioned compute. This satisfies both stem constraints: no cluster setup or management, and fast interactive analysis. Its columnar engine scans only referenced columns, keeping latency low without infrastructure provisioning.

Why this answer

BigQuery is a serverless, highly scalable, and cost-effective multi-cloud data warehouse designed for business agility. It allows you to analyze petabytes of data using standard SQL without needing to provision or manage any clusters, making it ideal for querying server logs stored in Cloud Storage directly via external tables or loading data into BigQuery for sub-second query performance.

Exam trap

Google Cloud often tests the distinction between serverless SQL analytics (BigQuery) and managed compute frameworks (Dataflow, Dataproc), where candidates mistakenly choose Dataflow or Dataproc for SQL-like analysis without recognizing the need for cluster management or pipeline setup.

How to eliminate wrong answers

Option A is wrong because Cloud Dataflow is a unified stream and batch data processing service that requires setting up and managing pipelines (though serverless, it is not primarily for ad-hoc SQL queries on stored logs). Option B is wrong because Cloud Logging is a real-time log management and analysis service for monitoring and debugging, not designed for complex SQL analytics on large historical log datasets stored in Cloud Storage. Option D is wrong because Cloud Dataproc is a managed Spark and Hadoop service that requires provisioning clusters (even if ephemeral) and is not serverless SQL querying.

Full explanation →

687

MCQhard

A media company streams user interaction events into Pub/Sub and processes them with a Dataflow streaming pipeline that writes to BigQuery. During peak hours, the pipeline's watermark lags significantly behind real time, and late-arriving events are being dropped. The team wants late events to be included in windowed aggregations for up to 30 minutes after the window closes. Which Dataflow configuration should they apply?

A.Switch the pipeline to use processing-time windows instead of event-time windows.

B.Increase the number of worker threads and enable autoscaling to reduce the watermark lag.

C.Set the allowed lateness on the windowing transform to 30 minutes and update the aggregation to emit late panes.

D.Configure the Pub/Sub subscription to retain messages for 30 minutes and replay them.

AnswerC

Allowed lateness controls how long after a window closes Dataflow continues to accept and process late-arriving elements for that window. Setting it to 30 minutes and ensuring the aggregation emits late panes lets events arriving within that period update results, which directly addresses the dropped late events while keeping the watermark behavior unchanged.

Why this answer

Allowed lateness extends the period during which a window accepts late data after the watermark passes the window end. Setting it to 30 minutes and emitting late panes ensures events arriving within that window update the aggregation instead of being dropped, which is the correct way to handle late-arriving streaming data.

Exam trap

The trap here is confusing watermark lag with allowed lateness; scaling workers addresses throughput, not the windowing rule that discards late elements.

Full explanation →

688

MCQhard

Your company uses Cloud Composer to orchestrate a complex data pipeline. You need to ensure that the pipeline can recover from failures and that tasks are retried automatically with exponential backoff. You also want to be alerted if a task fails after all retries. Which combination of features should you implement?

A.Use Airflow's SLA feature to trigger retries and send alerts.

B.Set retries and retry_delay on each task, and configure email alerts on task failure.

C.Set retries and retry_exponential_backoff on each task, and use Cloud Monitoring alerts based on Airflow metrics.

D.Configure a custom operator that implements retry logic and sends alerts via Pub/Sub.

AnswerC

Setting retries and retry_exponential_backoff on tasks enables automatic retries with exponential backoff. Cloud Composer exports Airflow metrics to Cloud Monitoring, allowing you to create alerts on task failures or other conditions. This combination provides robust retry logic and centralized alerting, meeting the requirements.

Why this answer

Tasks in Airflow can be configured with retries and retry_exponential_backoff to automatically retry failed tasks with increasing delays. Cloud Composer exports metrics to Cloud Monitoring, where you can set up alerts for task failures. This combination provides both automatic recovery and alerting, fulfilling the requirements.

Exam trap

The trap here is confusing Airflow's SLA feature with retry logic; SLA is for monitoring, not retrying.

Full explanation →

689

MCQmedium

You have a BigQuery table `logs` with a column `message` that contains JSON strings. You need to extract the value of the `user_id` field from each JSON string and return it as a separate column. Which function should you use?

A.JSON_EXTRACT_SCALAR(message, '$.user_id')

B.JSON_EXTRACT(message, '$.user_id')

C.REGEXP_EXTRACT(message, r'"user_id":\s*"([^"]+)"')

D.PARSE_JSON(message).user_id

AnswerA

JSON_EXTRACT_SCALAR extracts a scalar value from a JSON string using a JSONPath expression. It returns the value as a STRING, which is suitable for extracting user_id. This is the correct function for this scenario because it handles JSON parsing and returns a scalar, not a JSON object.

Why this answer

The JSON_EXTRACT_SCALAR function is designed to extract scalar values from JSON strings using JSONPath. It returns the value as a STRING, which is ideal for extracting user_id. Other functions either return JSON-formatted strings, rely on brittle regex, or use invalid syntax.

For robust JSON parsing in BigQuery, JSON_EXTRACT_SCALAR is the correct choice.

Exam trap

The trap here is choosing JSON_EXTRACT, which returns a JSON string with quotes, instead of JSON_EXTRACT_SCALAR, which returns the unquoted scalar value.

Full explanation →

690

MCQeasy

You need to schedule a recurring BigQuery query that aggregates data from a partitioned table and writes the results to a new table every day at 03:00 UTC. You want a fully managed solution with minimal operational overhead. What should you use?

A.Cloud Scheduler with a cron job that invokes a Cloud Function to run the query.

B.BigQuery scheduled queries.

C.Cloud Composer with a DAG that runs a BigQueryOperator.

D.A cron job on a Compute Engine instance that runs the bq query command.

AnswerB

BigQuery scheduled queries allow you to schedule SQL queries directly in the BigQuery UI or via API. They are fully managed, require no additional infrastructure, and support cron-like schedules. This is the simplest and most operationally efficient way to run a recurring query and write results to a table.

Why this answer

BigQuery scheduled queries are a fully managed feature that lets you schedule SQL queries to run at specified intervals. They require no additional infrastructure, support cron scheduling, and can write results to destination tables. This makes them the ideal choice for a recurring aggregation query with minimal operational overhead, unlike Cloud Functions, Composer, or VM-based cron jobs.

Exam trap

The trap here is overcomplicating the solution by using orchestration tools like Cloud Composer or Cloud Functions when a native BigQuery feature already provides the required scheduling with zero infrastructure management.

Full explanation →

691

MCQhard

A company needs to serve predictions for a model that runs an expensive computation on each request. The model is used by a batch job that processes millions of records each night, and also by a real-time API for a few thousand queries per hour. Which prediction strategy minimizes cost and latency for both use cases?

A.Deploy two identical models, one on a Compute Engine VM for batch, one on Vertex AI for online, and synchronize updates.

B.Use Vertex AI batch prediction for the nightly job and a separate online endpoint with auto-scaling for the real-time API.

C.Use Vertex AI batch prediction for both workloads.

D.Use a single online Vertex AI endpoint with auto-scaling to handle both workloads.

AnswerB

Batch prediction processes the nightly millions of records asynchronously at far lower cost than an always-on endpoint, while a separate auto-scaling online endpoint serves the few thousand real-time queries with low latency. This split matches each workload's cost and latency profile.

Why this answer

It separates the batch and online workloads to optimize cost and latency. Vertex AI batch prediction is designed for high-throughput, asynchronous processing of large datasets at lower cost, while a separate online endpoint with auto-scaling ensures low-latency responses for real-time API queries by scaling resources based on demand. This avoids over-provisioning for the batch job and prevents the batch workload from interfering with the latency-sensitive API.

Exam trap

Google often tests the misconception that a single Vertex AI endpoint can handle both batch and online workloads efficiently, but the trap is that batch and online have fundamentally different latency and throughput requirements, and using the same infrastructure for both leads to cost or performance penalties.

How to eliminate wrong answers

Option A is wrong because deploying two identical models on separate infrastructure (Compute Engine VM and Vertex AI) introduces unnecessary management overhead and synchronization complexity, and does not leverage Vertex AI's managed batch prediction service for cost efficiency. Option C is wrong because using batch prediction for the real-time API would introduce unacceptable latency, as batch predictions are asynchronous and not designed for sub-second response times required by online queries. Option D is wrong because using a single online endpoint for both workloads would cause the batch job's high-volume requests to consume resources and potentially throttle or delay the real-time API queries, increasing latency and cost due to over-provisioning to handle peak loads.

Full explanation →

692

MCQmedium

Refer to the exhibit. What is the cause of this error?

A.The machine type flag is only used during model deployment, not endpoint creation

B.The endpoint name already exists

C.The user must specify a model name

D.The region is missing

AnswerA

The machine type is a deployment-time property of the Model resource, not the Endpoint. Passing it during endpoint creation is rejected because the API expects no such field there, which is exactly the constraint the error reflects.

Why this answer

The error occurs because the `machine_type` flag is only valid during model deployment (when creating a deployment in Vertex AI), not during endpoint creation. When creating an endpoint, you specify the endpoint name and region, but the machine type is configured later when deploying a model to that endpoint. Attempting to set `machine_type` during endpoint creation causes a validation error because the API does not accept that parameter at that stage.

Exam trap

Google Cloud tests the distinction between endpoint creation and model deployment parameters in Vertex AI. Candidates often mistakenly assume that machine type can be set during endpoint creation, but it is only valid when deploying a model to the endpoint.

How to eliminate wrong answers

Option B is wrong because if the endpoint name already exists, the error would be a 409 Conflict or 'Already exists' message, not a validation error about an invalid parameter. Option C is wrong because a model name is not required when creating an endpoint; the endpoint is a container that can host multiple models, and models are specified during deployment. Option D is wrong because the region is a required parameter for endpoint creation, and if it were missing, the error would indicate a missing required field, not an invalid parameter like `machine_type`.

Full explanation →

693

MCQmedium

A company deploys a model to Vertex AI Endpoint. They want to run a canary deployment to test a new model version with 10% of traffic. How should they configure this?

A.Deploy to a new endpoint and update the application to call both

B.Use Cloud Load Balancing to route traffic

C.Deploy the new model to the same endpoint and set traffic split

D.Deploy to Cloud Run and use gradual rollout

AnswerC

Deploying both models to one Vertex AI Endpoint and assigning a traffic split routes exactly 10% of prediction requests to the new version, satisfying the canary requirement. Vertex AI supports multiple DeployedModels per endpoint with configurable traffic percentages, so no separate endpoint or redeployment is needed.

Why this answer

Vertex AI Endpoints natively support traffic splitting between model versions deployed to the same endpoint. By deploying the new model version to the same endpoint and setting a traffic split of 10% to the new version and 90% to the current version, the company can perform a canary deployment without changing the application code or infrastructure.

Exam trap

Google Cloud often tests the misconception that canary deployments require separate endpoints or external load balancers, when in fact Vertex AI Endpoints provide a built-in traffic splitting feature that handles this at the model version level.

How to eliminate wrong answers

Option A is wrong because deploying to a new endpoint and updating the application to call both endpoints adds unnecessary complexity and defeats the purpose of a canary deployment, which should be transparent to the application. Option B is wrong because Cloud Load Balancing operates at the network layer and cannot route traffic based on model version within a single Vertex AI Endpoint; it is designed for distributing traffic across regional endpoints or backends, not for model version canary testing. Option D is wrong because deploying to Cloud Run and using gradual rollout is not the native way to manage model versions in Vertex AI; Vertex AI Endpoints provide built-in traffic splitting for model versions, which is the recommended approach for canary deployments in this context.

Full explanation →

694

MCQeasy

Which BigQuery feature allows you to share query results with specific users without giving them direct access to the underlying tables?

A.IAM roles

B.Authorized views

C.Dataset access controls

D.Materialized views

AnswerB

Authorized views run with the view owner's permissions, so grantees query the view and see results without any direct table access. This satisfies the requirement to share query results with specific users while withholding underlying table permissions.

Why this answer

Authorized views allow sharing results without granting access to the base tables.

Full explanation →

695

MCQmedium

A company uses BigQuery for analytics. They need to ensure data quality by preventing duplicate records from being inserted. Which approach is most effective?

A.Use BigQuery ML to train a model that identifies anomalies.

B.Use a DML MERGE statement that filters out duplicates based on a unique key.

C.Use Cloud Data Loss Prevention API to scan for duplicates.

D.Use COUNT DISTINCT in queries to ignore duplicates.

AnswerB

A MERGE statement performs conditional upsert logic, matching incoming rows against existing records on a unique key so only new or changed rows are written. This prevents duplicate insertion at the query level, satisfying the data-quality constraint more reliably than post-load deduplication or table constraints alone.

Why this answer

BigQuery's DML MERGE statement can be used to atomically insert rows only when a unique key does not already exist in the target table. By using a MERGE with a WHEN NOT MATCHED THEN INSERT clause, the operation prevents duplicate records from being inserted in a single, transactional statement, ensuring data quality without requiring external tools or post-processing.

Exam trap

Google Cloud certifications often test the misconception that data quality tools like DLP or ML can solve structural data integrity problems, when in fact the correct approach is to use native DML operations (like MERGE) that enforce uniqueness at write time.

How to eliminate wrong answers

Option A is wrong because BigQuery ML is designed for machine learning tasks like forecasting or classification, not for enforcing data integrity constraints such as preventing duplicate rows; training a model for anomaly detection would be overkill and unreliable for exact duplicate prevention. Option C is wrong because the Cloud Data Loss Prevention (DLP) API is used for inspecting and de-identifying sensitive data (e.g., PII), not for detecting or preventing duplicate records; it has no concept of unique keys or row-level deduplication. Option D is wrong because COUNT DISTINCT only ignores duplicates in query results for aggregation purposes; it does not prevent duplicate records from being inserted into the table, so duplicates can still accumulate over time.

Full explanation →

696

MCQeasy

A data engineer wants to automatically detect when the distribution of input features to a production model has shifted significantly. Which Vertex AI feature should they enable?

A.Vertex AI Vizier

B.Vertex AI Model Monitoring

C.Vertex AI Explainable AI

D.Vertex AI Feature Store

AnswerB

Vertex AI Model Monitoring continuously tracks production input feature distributions against a baseline and alerts when drift or skew exceeds configured thresholds. This automates detection of significant feature distribution shifts, which manual periodic checks cannot achieve at scale.

Why this answer

Vertex AI Model Monitoring is the correct service because it is specifically designed to continuously detect feature distribution drift and prediction skew in production models. It automatically compares the current input feature distribution against a baseline (e.g., training data) and triggers alerts when significant statistical shifts occur, enabling proactive retraining or investigation.

Exam trap

The trap here is that candidates confuse 'monitoring model performance' (e.g., accuracy, latency) with 'monitoring input feature distribution drift', leading them to incorrectly choose Vertex AI Vizier or Explainable AI, which address different aspects of model lifecycle management.

How to eliminate wrong answers

Option A is wrong because Vertex AI Vizier is a hyperparameter tuning service that optimizes model performance through black-box optimization, not for monitoring distribution shifts in production. Option C is wrong because Vertex AI Explainable AI provides feature attributions and explanations for individual predictions, but it does not monitor aggregate distribution changes over time. Option D is wrong because Vertex AI Feature Store is a centralized repository for storing, serving, and sharing feature data, but it lacks built-in drift detection or alerting capabilities.

Full explanation →

697

MCQmedium

A logistics company collects GPS pings from delivery vehicles into Pub/Sub and needs to compute the distance traveled per vehicle per hour. The data volume is high and bursty, and the company wants a managed service that automatically scales the number of workers based on load while allowing custom windowing and stateful processing. Which service should they use?

A.Cloud Functions triggered by Pub/Sub messages

B.Dataflow with a streaming pipeline using windowing and stateful DoFn

C.Dataproc with a Spark Streaming job on a fixed-size cluster

D.BigQuery with a scheduled query that reads from a Pub/Sub subscription

AnswerB

Dataflow is a managed, autoscaling service for stream and batch processing. It supports windowing, triggers, and stateful DoFn, which are exactly the primitives needed to compute per-vehicle hourly distance while handling bursty load. The service scales workers automatically, matching the requirement for managed elasticity and custom stateful processing.

Why this answer

Dataflow provides managed autoscaling and native support for windowing and stateful processing, which are required to compute per-vehicle hourly distance from a bursty stream. The other options either lack stateful windowing, do not scale automatically, or are not designed for continuous stream processing.

Exam trap

The trap here is assuming that any service that can read Pub/Sub can also perform windowed, stateful aggregation, when only a stream processing engine like Dataflow provides those primitives natively.

Full explanation →

698

Multi-Selectmedium

You are using BigQuery to analyze a dataset. You need to create a new table that contains only rows from `sales` where the `region` is 'North America' and the `sale_date` is in the year 2023. You also want to add a column `sale_month` that extracts the month from `sale_date`. Which two actions should you take? (Choose two.)

Select 2 answers

A.Use the FORMAT_DATE function to create the `sale_month` column.

B.Use the EXTRACT function in the SELECT list to create the `sale_month` column.

C.Use a LIMIT clause to restrict the number of rows to only those in 2023.

D.Use a HAVING clause to filter on `region` and `sale_date`.

E.Use a WHERE clause with conditions on `region` and `sale_date`.

AnswersB, E

To add a column that extracts the month from a date, you use the EXTRACT function: `EXTRACT(MONTH FROM sale_date) AS sale_month`. This returns an integer representing the month. You can include this expression in the SELECT list of your query, and when you create a table from the query, the new column will be included. This is the correct way to derive the month from a date column.

Why this answer

To filter rows by region and date, a WHERE clause is required. To add a new column with the month, use the EXTRACT function in the SELECT list. HAVING is for aggregated groups, FORMAT_DATE returns a string, and LIMIT does not filter conditionally.

Thus, the correct actions are using a WHERE clause and using EXTRACT.

Exam trap

The trap here is confusing row filtering with aggregation filtering, or using formatting functions instead of extraction functions for date parts.

Full explanation →

699

MCQhard

You manage a team that deploys multiple versions of a computer vision model for A/B testing on Vertex AI Endpoints. You need to route a small percentage of traffic to a canary version while the rest goes to the stable version. You also need to gradually increase the canary traffic over time based on performance metrics. Which approach should you take?

A.Create two separate endpoints, one for each version, and use a separate load balancer to route a percentage of requests to the canary endpoint.

B.Deploy both models to the same endpoint and configure traffic splitting percentages using the Vertex AI console or API.

C.Use Cloud Armor with weighted backend services to route a portion of requests to the canary version.

D.Implement feature flags in the application code to randomly select the model version for each prediction request.

AnswerB

Traffic splitting on one Vertex AI endpoint assigns each deployed model a percentage of prediction requests, so the canary receives a small share that you can raise incrementally. This satisfies the gradual rollout constraint without redeploying or changing the client's endpoint URL.

Why this answer

Vertex AI Endpoints natively support traffic splitting between model versions deployed to the same endpoint. This allows you to assign a percentage of traffic (e.g., 5%) to a canary version and the remainder to the stable version, and then adjust the split over time via the console or API as performance metrics dictate. This approach avoids the complexity and latency of external load balancers or application-level routing.

Exam trap

Google often tests the misconception that you need an external load balancer or separate endpoints for canary deployments, when in fact Vertex AI's native traffic splitting is the correct and simplest approach.

How to eliminate wrong answers

Option A is wrong because creating two separate endpoints with an external load balancer adds unnecessary infrastructure complexity, latency, and cost; Vertex AI already provides built-in traffic splitting within a single endpoint. Option C is wrong because Cloud Armor is a web application firewall and DDoS protection service, not a traffic routing mechanism for model versions; it cannot perform weighted backend routing for Vertex AI endpoints. Option D is wrong because implementing feature flags in application code for model selection bypasses Vertex AI's managed traffic splitting, introduces custom logic that must be maintained, and does not leverage the platform's native canary deployment capabilities.

Full explanation →

700

MCQhard

A financial company uses a Dataflow streaming pipeline to read transactions from Pub/Sub and write to BigQuery. They need exactly-once processing semantics for the BigQuery writes and want to avoid duplicates during pipeline updates. Which approach should they use?

A.Use the BigQuery Storage Write API with exactly-once semantics in the Dataflow BigQueryIO connector.

B.Use BigQueryIO with STREAMING_INSERTS and enable insertId-based deduplication.

C.Use BigQueryIO with the FILE_LOADS method and trigger frequent load jobs.

D.Write to a temporary table and run a MERGE statement periodically to deduplicate.

AnswerA

The BigQueryIO connector can use the Storage Write API with exactly-once semantics, which deduplicates writes using stream offsets and supports seamless pipeline updates without duplicates. This is the recommended approach for exactly-once streaming writes to BigQuery in Dataflow.

Why this answer

The Storage Write API with exactly-once semantics in BigQueryIO provides deduplication through stream offsets and supports pipeline updates without duplicates. It is the designed solution for exactly-once streaming writes to BigQuery in Dataflow, unlike legacy streaming inserts or file loads.

Exam trap

The trap here is assuming that insertId deduplication with streaming inserts guarantees exactly-once, when it only provides best-effort deduplication.

Full explanation →

701

MCQhard

A BigQuery table has a REQUIRED column 'user_id' that now needs to accept NULL values due to upstream data changes. You want to alter the schema with minimal downtime and no data loss. What should you do?

A.Run `ALTER TABLE dataset.table ALTER COLUMN user_id DROP NOT NULL;`

B.Use the bq command: `bq update --set_nullable_fields user_id dataset.table`

C.Create a view that casts user_id to NULLABLE and use the view instead.

D.Drop the table and recreate it with the column as NULLABLE.

AnswerA

This BigQuery DDL statement changes the column to nullable without downtime or data loss.

Why this answer

BigQuery allows changing a column from REQUIRED to NULLABLE using the ALTER TABLE ALTER COLUMN SET DATA TYPE statement. This operation is a metadata change and does not require table recreation or data copy. Dropping and recreating the table would cause downtime and data loss.

Using a view is a workaround but doesn't change the underlying schema. Exporting and reloading is disruptive.

Full explanation →

702

Multi-Selecthard

A company uses Workflows to orchestrate a multi-step data pipeline. One step calls an HTTP endpoint that may take up to 10 minutes, but the default Workflows timeout is too short. They also need to handle transient errors with retries. Which TWO configurations should they apply? (Choose 2)

Select 2 answers

A.Set a step timeout of 600 seconds for the HTTP call step

B.Configure a dead letter queue for failed steps

C.Use the default retry policy on the step

D.Set the workflow execution timeout to 600 seconds

E.Add a retry policy on the step with appropriate conditions for transient errors

AnswersA, E

The HTTP call can run for 10 minutes, exceeding the default step timeout. Setting a 600-second step timeout on that call allows the long-running request to finish rather than being cancelled mid-flight, directly satisfying the stem's stated duration constraint.

Why this answer

Option A is correct because Workflows steps support a per-step timeout, and setting it to 600 seconds (10 minutes) ensures the HTTP call step is allowed to run for the full duration instead of being cut off by the shorter default step timeout. Option E is correct because transient errors (such as 5xx responses or connection resets) should be handled by attaching a retry policy to the step with conditions that match those transient failures, so the step is retried automatically. Option B is not appropriate because Workflows does not use dead letter queues for failed steps; failures are surfaced through execution errors and logs.

Option C is wrong because relying on the default retry policy does not let them target transient errors with appropriate conditions, and the default may not retry at all. Option D is wrong because setting the workflow execution timeout to 600 seconds would cap the entire workflow at 10 minutes, which is not the same as giving the HTTP step enough time and could still cause premature termination.

Full explanation →

703

MCQeasy

A team has trained a scikit-learn model and wants to deploy it to AI Platform Prediction for online predictions. What is the required format for the model artifact?

A.A model.joblib file (or model.pkl) along with any custom code.

B.A single .h5 file containing the model weights.

C.A SavedModel directory containing the model for TensorFlow.

D.A model.pt file for PyTorch models.

AnswerA

AI Platform Prediction requires the scikit-learn artifact serialised as model.joblib or model.pkl, optionally bundled with custom code in a tarball. This format satisfies the deployment constraint because the serving container loads that exact filename to reconstruct the estimator.

Why this answer

AI Platform Prediction (now Vertex AI) supports scikit-learn models natively. The required artifact format is a serialized model file (model.joblib or model.pkl) optionally accompanied by any custom code dependencies. This is because scikit-learn models are pickled objects, and the platform deserializes them using the same Python environment specified in the runtime version.

Exam trap

Candidates often mistakenly believe that a single universal model file format (e.g., .h5 or SavedModel) works for all frameworks on Vertex AI, but each framework has its own required format. For scikit-learn, it must be a .joblib or .pkl file.

How to eliminate wrong answers

Option B is wrong because .h5 files are specific to Keras/TensorFlow models, not scikit-learn; AI Platform Prediction expects a SavedModel or a serialized pickle for scikit-learn. Option C is wrong because a SavedModel directory is the required format for TensorFlow models, not for scikit-learn models. Option D is wrong because model.pt files are PyTorch serialization format; AI Platform Prediction requires a SavedModel for PyTorch or a custom container, not a raw .pt file.

Full explanation →

704

MCQeasy

To enable data lineage tracking in BigQuery, which feature should be activated?

A.BigQuery Audit Logs

B.Data Catalog

C.Dataplex Lineage

D.BigQuery Lineage API

AnswerC

Correct. Dataplex Lineage provides comprehensive data lineage for BigQuery and other Google Cloud data services.

Why this answer

The correct feature for data lineage tracking in BigQuery is Dataplex Lineage. Dataplex provides end-to-end lineage tracking across data assets, including BigQuery tables and views. BigQuery Lineage API is not a distinct feature; lineage capabilities are integrated into Dataplex.

BigQuery Audit Logs capture metadata changes but are not lineage-specific, and Data Catalog is for metadata management, not lineage.

Exam trap

Candidates may assume that BigQuery Lineage API is a separate service, but lineage for BigQuery is actually provided through Dataplex. Selecting D (BigQuery Lineage API) is incorrect because it is not a standalone feature.

Full explanation →

705

MCQhard

A financial services firm must process payment events in strict order per account and cannot tolerate duplicates. The events arrive in Pub/Sub and must be written to BigQuery. The engineering team is designing the pipeline and wants to guarantee that each account's events are applied in the order they were published. Which approach should they take?

A.Write all events to a Cloud Storage bucket and run a nightly batch job that sorts by timestamp before loading into BigQuery.

B.Use a single Pub/Sub subscriber with one thread to process all events sequentially across all accounts.

C.Use a Pub/Sub pull subscription with multiple subscribers and rely on BigQuery to sort events by timestamp during queries.

D.Enable message ordering on the Pub/Sub subscription and use the ordering key set to the account ID, then process with a Dataflow pipeline that preserves order per key.

AnswerD

Pub/Sub message ordering with an ordering key ensures that messages with the same key are delivered in publish order. Setting the key to the account ID gives per-account ordering, and a Dataflow pipeline that respects the key can apply events in sequence. This directly satisfies the strict per-account ordering requirement.

Why this answer

Pub/Sub ordering keys combined with a key-aware Dataflow pipeline enforce per-account order without sacrificing parallelism across accounts. Sorting after the fact or using a single global consumer either fails to guarantee application order or imposes unacceptable throughput limits.

Exam trap

The trap here is thinking that timestamps alone can reconstruct publish order, when ordering keys are what Pub/Sub actually uses to sequence messages per key.

Full explanation →

706

MCQeasy

You need to load a large CSV file from Cloud Storage into BigQuery. The file has a header row and contains a column with date values in the format 'YYYY-MM-DD'. You want to ensure the date column is correctly recognized as a DATE type. Which method should you use?

A.Define an explicit schema in JSON or inline that specifies the date column as DATE, and provide it during the load job.

B.Use the bq load command with the --autodetect flag and no schema definition.

C.Load the file as a string column, then use a SQL query to cast the string to DATE after loading.

D.Convert the CSV to a newline-delimited JSON file with date values as strings, then load with autodetect.

AnswerA

Providing an explicit schema ensures BigQuery interprets the date column as DATE regardless of the string format. This is the most reliable method, especially when the format matches the expected DATE literal. It avoids ambiguity and guarantees correct type recognition, which is essential for subsequent date functions.

Why this answer

Defining an explicit schema that specifies the date column as DATE ensures BigQuery correctly interprets the values during load. This method is reliable and avoids the uncertainty of autodetect or post-load casting, making it the best practice for date columns with a known format.

Exam trap

The trap here is relying on autodetect to infer DATE types, but autodetect can be inconsistent and may default to STRING if the format is not perfectly recognized.

Full explanation →

707

MCQmedium

A media analytics company ingests clickstream events into Pub/Sub at a sustained rate of 2 GB/s. A Dataflow streaming pipeline reads these events, performs windowed aggregations, and writes results to BigQuery. The pipeline must handle occasional spikes up to 5 GB/s without data loss or excessive backlog. The operations team wants to minimize manual intervention and cost. What should you do to configure the Dataflow pipeline for dynamic scaling?

A.Set the number of workers to a fixed value of 100 to handle peak load, and enable autoscaling with a maximum of 100 workers.

B.Enable autoscaling and set the maximum number of workers to 200, and use Streaming Engine to offload windowing and state management.

C.Configure the pipeline to use a single worker with a high-memory machine type to reduce coordination overhead.

D.Use a batch pipeline with a trigger that runs every 5 minutes to process accumulated Pub/Sub messages.

AnswerB

Enabling autoscaling allows Dataflow to add workers when backlog increases and remove them when load decreases, optimizing cost. Setting a high maximum ensures capacity for spikes. Streaming Engine moves pipeline state and windowing out of worker memory, improving scalability and reducing worker resource needs. This combination handles dynamic load without manual intervention and is the recommended approach for variable streaming workloads.

Why this answer

Autoscaling with a sufficient maximum worker count allows Dataflow to dynamically adjust to load, while Streaming Engine optimizes state management and reduces worker burden. This combination handles both sustained high throughput and spikes without manual tuning, and it minimizes cost during low periods. Fixed worker counts or batch processing would either be inefficient or fail to meet latency and scalability needs.

Exam trap

The trap here is assuming that setting a high fixed number of workers is sufficient for spikes, but that ignores cost optimization and the benefits of dynamic scaling.

Full explanation →

708

Multi-Selecteasy

A company is designing a data processing pipeline for real-time sensor data. They want to ensure low latency and exactly-once processing semantics. Which two Google services should they combine to achieve this? (Choose 2)

Select 2 answers

A.Cloud Dataproc with Spark Streaming

B.Cloud Functions with Cloud Pub/Sub triggers

C.Cloud Pub/Sub with exactly-once delivery

D.Cloud Dataflow with exactly-once processing mode

E.Cloud IoT Core with device gateways

AnswersC, D

Pub/Sub can be configured for exactly-once delivery to subscribers.

Why this answer

Cloud Pub/Sub with exactly-once delivery (Option C) ensures that each message is delivered to subscribers exactly once, preventing duplicates in the pipeline. Cloud Dataflow with exactly-once processing mode (Option D) provides end-to-end exactly-once semantics by leveraging consistent snapshots and idempotent sinks, which is critical for real-time sensor data pipelines requiring low latency and accuracy.

Exam trap

Google Cloud often tests the misconception that Cloud Pub/Sub alone provides end-to-end exactly-once processing, but candidates must recognize that Pub/Sub only guarantees delivery exactly once to subscribers, while Dataflow is needed to ensure processing exactly once across transformations and sinks.

Full explanation →

709

MCQmedium

A data engineer is designing a batch ETL pipeline using Cloud Composer and Dataflow. The pipeline must be self-healing and retry on failures. Which Composer feature should they configure?

A.Use Cloud Tasks for retries

B.Retry policy on the DAG

C.Cloud Composer with high availability

D.Dataflow retries

AnswerB

A retry policy on the DAG defines retries, delay and backoff for failed tasks, so transient Dataflow or API errors are re-attempted automatically. This delivers the self-healing behaviour the pipeline requires without manual intervention or external orchestration.

Why this answer

Cloud Composer (based on Apache Airflow) allows you to configure a retry policy directly on the DAG or individual tasks. This enables the pipeline to automatically retry failed tasks according to parameters like `retries`, `retry_delay`, and `retry_exponential_backoff`, making the ETL pipeline self-healing without external services.

Exam trap

Google Cloud often tests the distinction between orchestration-level retries (Composer DAG) and execution-level retries (Dataflow), leading candidates to pick Dataflow retries (Option D) when the question explicitly asks for a Composer feature.

How to eliminate wrong answers

Option A is wrong because Cloud Tasks is a fully managed queue service for asynchronous task execution, not a feature of Cloud Composer; it would introduce unnecessary complexity and is not the native way to handle retries within a Composer DAG. Option C is wrong because high availability (HA) for Cloud Composer ensures the Airflow components are resilient to zone failures, but it does not configure task-level retry behavior for pipeline failures. Option D is wrong because Dataflow retries handle failures at the Dataflow job level (e.g., worker failures), but the question asks for a Composer feature to manage retries of the overall pipeline orchestration, not the underlying data processing job.

Full explanation →

710

MCQeasy

A company uses Cloud Dataflow to process streaming data. They notice that the pipeline's throughput is lower than expected and the system is experiencing high latency. What is the most likely cause?

A.Using batch mode instead of streaming mode

B.Too many workers

C.Too few workers

D.Incorrect watermark setting

AnswerC

Insufficient worker instances directly limit parallel processing capacity, so the pipeline cannot keep pace with incoming streaming data, producing the observed throughput drop and elevated latency. Cloud Dataflow scales horizontally by distributing work across workers; with too few allocated, backlog accumulates and per-element processing time rises.

Why this answer

In Cloud Dataflow, streaming pipelines require sufficient worker resources to handle the incoming data rate and maintain low latency. When too few workers are provisioned, the pipeline cannot process data quickly enough, leading to increased backlog and higher latency. This is the most likely cause of reduced throughput and high latency in a streaming pipeline.

Exam trap

A common misconception is that adding more workers always improves performance, but the key insight here is that too few workers directly cause high latency and low throughput in a streaming pipeline. The trap is to overlook the importance of sufficient worker scaling.

How to eliminate wrong answers

Option A is wrong because batch mode is a separate execution mode for bounded data, and using batch mode instead of streaming mode would not cause high latency in a streaming pipeline—it would simply not process unbounded data correctly. Option B is wrong because too many workers would typically improve throughput and reduce latency, not cause high latency, unless there is excessive overhead from worker coordination, but that is less common than underprovisioning. Option D is wrong because an incorrect watermark setting affects event-time processing and windowing accuracy, but it does not directly cause lower throughput or high latency; it may cause late data handling issues or incorrect results.

Full explanation →

711

MCQeasy

A team deployed a model to Vertex AI Endpoint and notices latency spikes during peak hours. What should they first investigate?

A.Switch to batch prediction

B.Reduce number of features

C.Increase machine type

D.Check if autoscaling is enabled and configured correctly

AnswerD

Autoscaling governs how Vertex AI Endpoint provisions replicas against traffic, so misconfigured minimum or maximum replica counts, or an absent scaling metric, directly cause peak-hour latency spikes. Verifying this first addresses the stem's load-dependent symptom before investigating model-level or network causes.

Why this answer

Latency spikes during peak hours typically indicate that the serving infrastructure is unable to handle the increased request volume. The first step is to check if autoscaling is enabled and configured correctly on the Vertex AI Endpoint, as this determines whether additional compute nodes are automatically provisioned to match demand. Without proper autoscaling, the endpoint will be overwhelmed, leading to queuing delays and latency spikes.

Exam trap

Google Cloud often tests the misconception that latency spikes are always due to model complexity or feature engineering, when in fact the first diagnostic step should always be to verify the serving infrastructure's scaling configuration.

How to eliminate wrong answers

Option A is wrong because switching to batch prediction is for asynchronous, non-real-time inference and does not address the root cause of latency spikes during online serving. Option B is wrong because reducing the number of features may lower model complexity but does not directly resolve infrastructure scaling issues; latency spikes are typically due to insufficient compute resources, not feature count. Option C is wrong because increasing the machine type (e.g., using a larger VM) may improve per-request performance but does not solve the problem of handling concurrent peak traffic; without autoscaling, a single larger machine can still be overwhelmed.

Full explanation →

712

Multi-Selecteasy

A company wants to implement a data lake on Google Cloud. They need to store raw, structured data in open formats and allow querying directly from BigQuery without loading. Which TWO services or features should they use? (Choose 2)

Select 2 answers

A.Cloud Storage (GCS)

B.Dataproc

C.Dataflow

D.Cloud SQL

E.BigLake

AnswersA, E

GCS is the underlying storage for the data lake, storing data in open formats like Parquet/ORC.

Why this answer

Cloud Storage (GCS) [CORRECT] is the right choice because a data lake on Google Cloud stores raw, structured data as objects in open formats (e.g., Parquet, Avro, ORC, JSON) in buckets, providing durable, scalable, and cost-effective storage. BigLake [CORRECT] is also correct because it is a storage engine that lets BigQuery query data directly in Cloud Storage (and other sources) without loading it, using external tables with fine-grained access control and metadata caching. Together, GCS holds the raw files and BigLake exposes them to BigQuery for direct querying, which matches the requirement exactly.

Dataproc (B) is a managed Spark/Hadoop service for processing, not the storage or direct-query layer, and Dataflow (C) is a managed Apache Beam pipeline service for stream/batch processing, so neither fulfills the storage-plus-query requirement. Cloud SQL (D) is a managed relational database for transactional workloads, not a data lake storage layer, and it does not provide the open-format object storage or BigQuery external querying described.

Exam trap

Google often tests the misconception that Dataproc or Dataflow are required for querying data in a data lake, when in fact BigQuery external tables and BigLake provide direct querying without loading, and the key is to recognize that storage (GCS) and the query engine (BigLake) are the correct services.

Full explanation →

713

MCQmedium

You train a BigQuery ML linear regression model to predict house prices. The model has high bias during evaluation. Which action BEST reduces bias?

A.Decrease the learning rate in the training options

B.Add more features like number of bedrooms and square footage

C.Remove features that have low correlation with the label

D.Increase L2 regularization

AnswerB

High bias means the model underfits because its hypothesis space is too simple for the underlying relationship. Adding predictive features such as bedrooms and square footage increases model capacity, satisfying the stem's requirement to reduce bias rather than variance.

Why this answer

High bias indicates underfitting, meaning the model is too simple to capture the underlying patterns in the data. Adding more features, such as number of bedrooms and square footage, increases the model's complexity and its ability to fit the training data, thereby reducing bias. This is a standard approach to address underfitting in linear regression.

Exam trap

The PDE exam often tests the confusion between bias and variance, leading candidates to choose regularization or learning rate adjustments when the problem is underfitting due to insufficient features.

How to eliminate wrong answers

Option A is wrong because decreasing the learning rate affects the optimization process but does not directly reduce bias; it may slow convergence but won't help the model fit better if it's too simple. Option C is wrong because removing features would further simplify the model, likely increasing bias. Option D is wrong because increasing L2 regularization adds a penalty for large coefficients, which can increase bias by shrinking coefficients, making the model even simpler.

Full explanation →

714

MCQmedium

Refer to the exhibit. A team uses this Cloud Build configuration to deploy a service to Cloud Run. The deployment step fails with a 'Permission denied' error. What is the most likely cause?

A.The Dockerfile is missing from the repository.

B.The Docker image tag is missing or malformed.

C.The region 'us-central1' is incorrect for Cloud Run.

D.The Cloud Build service account does not have the Cloud Run Admin role.

AnswerD

Cloud Build executes deployments using its dedicated service account, which requires the Cloud Run Admin role to create or update services. Without that IAM binding, the deployment step is rejected with 'Permission denied' even though the configuration syntax itself is valid.

Why this answer

The Cloud Build service account (typically the default compute engine service account or a user-specified service account) must have the Cloud Run Admin role (roles/run.admin) to deploy services to Cloud Run. Without this IAM permission, the deployment step fails with a 'Permission denied' error, even if the build itself succeeds. The error occurs because Cloud Build attempts to call the Cloud Run Admin API (run.googleapis.com) to create or update the service, and the service account lacks the required authorization.

Exam trap

Google often tests the distinction between build-time errors (e.g., missing Dockerfile, malformed tags) and deployment-time permission errors, expecting candidates to recognize that a 'Permission denied' error specifically points to IAM misconfiguration rather than build configuration issues.

How to eliminate wrong answers

Option A is wrong because a missing Dockerfile would cause a build failure (e.g., 'unable to prepare context: path not found'), not a deployment-time 'Permission denied' error. Option B is wrong because a missing or malformed image tag would cause a push or pull error (e.g., 'invalid reference format'), not a permission error during deployment. Option C is wrong because 'us-central1' is a valid Cloud Run region; an incorrect region would result in a 'region not found' or 'location not found' error, not a permission error.

Full explanation →

715

Multi-Selecthard

You are designing a data pipeline for ML training with Vertex AI. You need to split time-series data into train/validation/test sets without leaking future data. Which THREE practices should you follow?

Select 3 answers

A.Use a sliding window validation approach for hyperparameter tuning.

B.Ensure that all data points for a given time period are in the same split.

C.Use Looker to generate the splits automatically.

D.Randomly assign rows to each split to ensure statistical distribution.

E.Use a date column to define the split boundaries.

AnswersA, B, E

Sliding-window validation trains on an expanding or rolling past window and validates on the immediately following period, so every fold respects chronological order. This directly prevents future leakage during hyperparameter tuning, satisfying the stem's requirement to split time-series data without exposing the model to later observations.

Why this answer

Option A is correct because a sliding-window (rolling-origin) validation scheme trains on past data and validates on the immediately following window, which respects temporal order and prevents future leakage during hyperparameter tuning. Option B is correct because keeping all data points from the same time period (e.g., same day or timestamp bucket) in a single split avoids boundary leakage, where records from one period appear in both train and test. Option E is correct because using an explicit date column to define split boundaries (for example, train on data before 2024-01-01, validate on Q1 2024, test on Q2 2024) enforces a strict chronological cutoff.

Option C is not appropriate because Looker is a BI/analytics and dashboarding tool, not a mechanism for producing leakage-safe ML dataset splits. Option D is wrong because random row assignment mixes past and future observations across splits, which is exactly the temporal leakage the scenario must avoid.

Full explanation →

716

MCQmedium

A global e-commerce platform requires a relational database that can handle millions of transactions per second across regions with strong consistency and automatic failover. The database must also support SQL joins. Which database should they choose?

A.Cloud Spanner

B.Cloud SQL

C.Cloud Firestore

D.Cloud Bigtable

AnswerA

Cloud Spanner satisfies the stem's demand for horizontal scalability with strong consistency by using TrueTime and Paxos across regions, delivering automatic failover and ANSI SQL joins. Unlike eventually consistent NoSQL stores, it preserves relational semantics at global scale, matching millions of transactions per second.

Why this answer

Cloud Spanner is the correct choice because it is a globally distributed, horizontally scalable relational database that provides strong consistency and automatic failover across regions, while fully supporting SQL joins. It combines the benefits of a traditional relational database with the horizontal scalability of NoSQL systems, making it ideal for high-throughput, globally distributed applications requiring ACID transactions.

Exam trap

A common trap in the Google Professional Data Engineer exam is to assume Cloud SQL is suitable for global-scale, high-consistency workloads because it is a relational database, but it lacks the global distribution and automatic failover capabilities required for millions of transactions per second across regions.

How to eliminate wrong answers

Option B (Cloud SQL) is wrong because it is a single-region, vertically scalable relational database that cannot handle millions of transactions per second across regions with automatic failover; it lacks global distribution and strong consistency across regions. Option C (Cloud Firestore) is wrong because it is a NoSQL document database that does not support SQL joins and is designed for mobile and web apps with eventual consistency, not for high-throughput relational workloads requiring strong consistency. Option D (Cloud Bigtable) is wrong because it is a NoSQL wide-column database that does not support SQL joins or relational queries; it is optimized for analytical and time-series workloads, not transactional applications requiring ACID properties.

Full explanation →

717

MCQeasy

A media company needs to process a large number of small JSON files stored in Cloud Storage. They want to use a serverless, SQL-based approach to transform and aggregate the data without managing infrastructure. Which Google Cloud service should they use?

A.Cloud Dataproc

B.Cloud Dataflow

C.Cloud SQL

D.BigQuery

AnswerD

BigQuery is a serverless, highly scalable data warehouse that supports SQL queries. It can directly query external data in Cloud Storage using external tables or load JSON files. This allows the company to transform and aggregate data using SQL without managing infrastructure. It is the ideal service for this requirement.

Why this answer

BigQuery is a serverless, SQL-based analytics service that can query data directly from Cloud Storage, including JSON files, using external tables or loading jobs. It eliminates infrastructure management and allows the media company to transform and aggregate data using familiar SQL. This makes it the most suitable choice among the options.

Exam trap

The trap here is confusing serverless with code-free SQL; Dataflow is serverless but requires coding, while BigQuery is both serverless and SQL-based.

Full explanation →

718

MCQhard

A retail company uses BigQuery to store sales data and wants to forecast weekly demand for the next 8 weeks using historical data from the past 2 years. They need to account for seasonality and holidays. Which BigQuery ML model type and configuration is most appropriate?

A.ARIMA_PLUS with holiday_region parameter

B.Boosted tree classifier

C.Linear regression with engineered time features

D.Time-series DECOMPOSE model

AnswerA

ARIMA_PLUS decomposes the time series into trend, seasonal and holiday components, automatically detecting weekly and yearly seasonality across the two years of history. Setting holiday_region incorporates retail holiday effects into the forecast, directly satisfying the requirement to account for seasonality and holidays over the eight-week horizon.

Why this answer

ARIMA_PLUS with the holiday_region parameter is the most appropriate BigQuery ML model for forecasting weekly demand with seasonality and holidays. ARIMA_PLUS is specifically designed for time-series forecasting, automatically handles seasonality, trend, and holidays when the holiday_region is specified. It also provides explainability and handles missing data.

Exam trap

PDE often tests the choice of BigQuery ML model for time-series forecasting; candidates may overlook ARIMA_PLUS's built-in holiday and seasonality handling and opt for manual feature engineering with linear regression.

How to eliminate wrong answers

Option B is wrong because a boosted tree classifier is for classification problems, not time-series forecasting. Option C is wrong because linear regression with engineered time features requires manual feature engineering and may not capture complex seasonality and holiday effects as effectively as ARIMA_PLUS. Option D is wrong because 'Time-series DECOMPOSE model' is not a valid BigQuery ML model type; BigQuery ML offers ARIMA_PLUS and ARIMA_PLUS_XREG for time-series forecasting.

Full explanation →

719

Drag & Dropmedium

Drag and drop the steps to set up a BigQuery dataset with a scheduled query into the correct order.

Drag or tap steps into the slots.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

Why this order

Setting up a BigQuery dataset with a scheduled query involves three logical steps in order: first create a dataset to store your data, then write the SQL query that transforms or loads the data, and finally configure the scheduled query to run at specified intervals. The dataset must exist before you can reference it in the query or schedule, and the query must be defined before you can schedule it. Reversing these steps leads to errors because each step depends on the previous one.

Full explanation →

720

MCQmedium

A data team uses Looker Studio to create a report that combines data from two different BigQuery tables: one with sales transactions and another with customer demographics. They need to join these tables in the report without writing SQL. Which feature should they use?

A.Data blending

B.Creating a report with multiple charts

C.Custom query in BigQuery connector

D.Calculated fields

AnswerA

Data blending lets Looker Studio combine two BigQuery data sources by matching a shared dimension, producing a joined result inside the report. This satisfies the requirement to join sales transactions with customer demographics without writing SQL or pre-joining the tables in BigQuery.

Why this answer

Looker Studio's data blending feature allows combining data from multiple sources (including BigQuery tables) using a common key, without writing SQL. It provides a graphical interface to define joins. Creating a custom query requires SQL.

Looker Studio reports support multiple charts, but blending is the specific feature for joining data. Calculated fields transform data within a single source.

Full explanation →

721

Multi-Selectmedium

Which TWO are best practices for monitoring a deployed machine learning model in production on Vertex AI?

Select 2 answers

A.Set up a weekly retraining pipeline triggered by calendar schedule

B.Enable Vertex AI Model Monitoring to track feature drift and skew

C.Monitor the training job duration to detect anomalies

D.Monitor the distribution of predictions over time to detect concept drift

E.Monitor the model's file size to ensure it hasn't changed

AnswersB, D

Vertex AI Model Monitoring computes training-serving skew and prediction drift against a baseline, directly satisfying the stem's requirement to detect feature drift and skew in production. It raises alerts when distributions diverge, so degradation is caught before it affects business outcomes.

Why this answer

Option B is correct because Vertex AI Model Monitoring is the purpose-built service for detecting training-serving skew and prediction drift on deployed models by comparing incoming request features against the training baseline, which is exactly the production monitoring best practice. Option D is correct because tracking the distribution of predictions over time is the standard way to detect concept drift, since a shift in the relationship between inputs and outputs shows up as changing output distributions even when input features look stable. Option A is not a monitoring best practice because a fixed calendar-schedule retraining pipeline is a maintenance strategy, not monitoring, and it can miss sudden drift between runs.

Option C is wrong because training job duration is a build-time metric, not a runtime signal of model quality in production. Option E is wrong because model file size is a static artifact property and has no bearing on prediction quality or drift.

Exam trap

The trap here is that candidates confuse operational maintenance tasks (like scheduled retraining) with monitoring tasks, or they focus on infrastructure metrics (like job duration or file size) instead of data and prediction distribution monitoring, which directly impact model accuracy in production.

Full explanation →

722

MCQmedium

Your company stores sensitive customer data in Cloud Storage. You need to inspect the data for personally identifiable information (PII) and de-identify it before sharing with a third party. Which Google Cloud service should you use?

A.Security Command Center

B.Dataplex

C.Cloud Data Loss Prevention (DLP)

D.Cloud KMS

AnswerC

Cloud DLP inspects data using infoType detectors to locate PII, then applies de-identification transformations such as masking, tokenisation or redaction. This satisfies both requirements: identifying sensitive customer data and removing it before sharing with the third party.

Why this answer

Cloud Data Loss Prevention (DLP) is the correct service because it is specifically designed to inspect, classify, and de-identify sensitive data such as PII in Cloud Storage. It provides built-in infoType detectors for over 150 types of PII and supports de-identification techniques like masking, tokenization, and encryption. This directly matches the requirement to inspect and de-identify data before sharing with a third party.

Exam trap

Candidates often confuse Cloud KMS (key management only) with Cloud DLP (inspection and de-identification), leading them to mistakenly choose Cloud KMS because they associate 'de-identify' with encryption, but Cloud KMS only manages keys, not the inspection or transformation of data content.

How to eliminate wrong answers

Option A is wrong because Security Command Center is a security and risk management platform that provides threat detection, vulnerability scanning, and compliance monitoring, but it does not have native capabilities to inspect or de-identify PII in data objects. Option B is wrong because Dataplex is a data governance and management service that helps organize, catalog, and manage data across lakes and warehouses, but it lacks built-in PII inspection and de-identification features. Option D is wrong because Cloud KMS is a key management service for creating, storing, and managing encryption keys, but it does not inspect data for PII or perform de-identification; it only provides encryption/decryption operations.

Full explanation →

723

MCQmedium

Your team is using Vertex AI Pipelines to orchestrate a model retraining workflow. The pipeline includes a data validation step, a training step, and a model evaluation step. You want to ensure that if the evaluation step fails due to low model performance, the pipeline stops and does not deploy the model. Which approach should you use?

A.Run the evaluation step after deployment and roll back if performance is low

B.Configure the evaluation step to retry up to 3 times on failure

C.Use a Conditional in the pipeline to check evaluation metrics and only run the deployment step if metrics pass thresholds

D.Create a separate pipeline for deployment and trigger it manually after review

AnswerC

A conditional branch evaluates the evaluation step's output metrics against your thresholds, then gates the deployment step so it only executes when performance passes. This directly satisfies the stem's requirement that a low-performance evaluation halts the pipeline before deployment, since the deployment task is skipped entirely rather than merely flagged.

Why this answer

Vertex AI Pipelines supports conditional execution via the `Condition` component, which allows you to evaluate model performance metrics (e.g., accuracy, RMSE) and gate subsequent steps. By placing the deployment step inside a conditional branch that only executes when evaluation metrics meet predefined thresholds, the pipeline automatically stops and avoids deploying a poor-performing model. This approach aligns with MLOps best practices for automated gating in production pipelines.

Exam trap

The trap here is that candidates confuse retry logic (Option B) with conditional gating, mistakenly thinking that retrying a failed evaluation step will somehow improve model performance, when in fact retries only handle transient errors, not metric-based failures.

How to eliminate wrong answers

Option A is wrong because running the evaluation step after deployment and then rolling back violates the principle of failing fast; it wastes compute resources and risks serving a bad model to users before rollback. Option B is wrong because retrying the evaluation step on failure does not address the root cause — low model performance — and would simply re-run the same evaluation, potentially masking the failure or delaying the pipeline. Option D is wrong because creating a separate pipeline for manual deployment defeats the purpose of automation and introduces human latency and error, contradicting the goal of an automated orchestrated workflow.

Full explanation →

724

MCQhard

A company runs a batch data processing workload using Dataproc clusters that are auto-scaled based on YARN memory utilization. During peak times, jobs take much longer than expected. Analysis shows the cluster is not scaling up despite high YARN memory utilization. What is the most likely cause?

A.Spark dynamic allocation is disabled, preventing executors from using added workers

B.The cluster autoscaler is misconfigured to scale based on CPU, not memory

C.The autoscaler is set to scale down secondary workers, not up

D.The cluster is using primary workers only; auto-scaling only adds secondary workers

AnswerD

Dataproc autoscaling adds only secondary workers to a cluster; primary worker count stays fixed. If the cluster runs primary workers alone, no scale-up occurs despite high YARN memory utilisation, which explains the stalled scaling during peak periods.

Why this answer

Dataproc clusters have two types of workers: primary workers (which run both HDFS and compute) and secondary workers (compute-only). The autoscaler can only add or remove secondary workers; it cannot scale primary workers. If the cluster uses only primary workers, the autoscaler has no secondary workers to add, so it cannot scale up even under high YARN memory utilization.

This explains why the cluster remains static during peak times.

Exam trap

The trap here is that candidates assume autoscaling applies to all worker nodes equally, overlooking the Dataproc-specific distinction between primary and secondary workers and the autoscaler's limitation to secondary workers only.

How to eliminate wrong answers

Option A is wrong because Spark dynamic allocation controls how executors are distributed within existing nodes, not how the cluster adds new nodes; even if disabled, the autoscaler would still attempt to add workers if configured correctly. Option B is wrong because the question explicitly states the autoscaler is based on YARN memory utilization, not CPU; a misconfiguration to CPU would cause scaling based on CPU metrics, but the symptom here is no scaling at all, not scaling on the wrong metric. Option C is wrong because the autoscaler is designed to scale up secondary workers when utilization is high; a misconfiguration to scale down would cause premature removal of workers, not a failure to scale up.

Full explanation →

725

MCQhard

A team is training a large model using a custom container with TensorFlow on Vertex AI Training. They need to use multiple GPUs across several machines. Which strategy should they implement to maximize training throughput?

A.Use Cloud TPU Pods for distributed training

B.Use Dataflow for distributed training

C.Use Vertex AI Training with a custom job specifying workerPoolSpecs and MultiWorkerMirroredStrategy

D.Use a single worker with multiple GPUs and TensorFlow MirroredStrategy

AnswerC

MultiWorkerMirroredStrategy performs all-reduce synchronisation across GPUs on every machine, giving true data-parallel training over the whole cluster. Specifying workerPoolSpecs in the custom job provisions those multiple machines, satisfying the stem's requirement for multi-machine, multi-GPU throughput rather than single-node scaling.

Why this answer

Vertex AI Training's custom job with workerPoolSpecs enables multi-machine, multi-GPU distributed training, and TensorFlow's MultiWorkerMirroredStrategy is specifically designed for synchronous distributed training across multiple workers. This combination maximizes throughput by efficiently synchronizing gradients across all GPUs on all machines using all-reduce communication, which is essential for large model training.

Exam trap

Google often tests the distinction between single-machine multi-GPU strategies (MirroredStrategy) and multi-machine distributed strategies (MultiWorkerMirroredStrategy), leading candidates to pick D when they overlook the requirement for multiple machines.

How to eliminate wrong answers

Option A is wrong because Cloud TPU Pods are specialized hardware for Tensor Processing Units, not GPUs, and the question explicitly requires using multiple GPUs across several machines. Option B is wrong because Dataflow is a serverless, fully managed service for batch and stream data processing (e.g., Apache Beam pipelines), not designed for distributed model training with TensorFlow on GPUs. Option D is wrong because a single worker with multiple GPUs and TensorFlow MirroredStrategy only scales within one machine, failing to leverage multiple machines for distributed training across a cluster.

Full explanation →

726

Multi-Selecthard

A financial services firm stores transaction records in a BigQuery table partitioned by transaction_date. Compliance requires that rows older than seven years be permanently and irreversibly deleted, and the team must prove deletion occurred. The table currently uses the default partition expiration of never. The engineer must implement the retention policy without dropping the whole table. (Choose two.)

Select 2 answers

A.Use Cloud Key Management Service with a customer-managed encryption key and destroy the key version after seven years.

B.Verify retention by querying INFORMATION_SCHEMA.PARTITIONS to confirm partitions beyond the retention window no longer exist.

C.Configure a Cloud Storage lifecycle rule on the table's underlying data to remove objects older than seven years.

D.Create a scheduled query that runs DELETE FROM the table WHERE transaction_date < DATE_SUB(CURRENT_DATE(), INTERVAL 7 YEAR).

E.Set a partition expiration on the table so partitions older than the required retention window are deleted automatically.

AnswersB, E

After partition expiration removes old partitions, INFORMATION_SCHEMA.PARTITIONS lists the partitions that remain, giving auditors evidence that partitions past the seven-year boundary are gone. This metadata view is the standard way to demonstrate which partitions exist and their sizes. Combined with partition expiration, it provides the proof of deletion that compliance demands.

Why this answer

Partition expiration is the native BigQuery mechanism that irreversibly removes whole partitions once they age past the retention window, and it operates without dropping the table so recent data stays available. The compliance proof comes from INFORMATION_SCHEMA.PARTITIONS, which shows exactly which partitions remain. A scheduled DELETE leaves recoverable copies through time travel and fail-safe, Cloud Storage lifecycle rules cannot see BigQuery-managed storage, and key destruction is not selective enough to age out only old rows.

Exam trap

The trap here is treating a scheduled DELETE as equivalent to partition expiration, when time travel and fail-safe retention mean deleted rows are not immediately and irreversibly gone.

Full explanation →

727

MCQeasy

A company wants to use BigQuery to query data stored in Parquet files in Cloud Storage without loading the data into BigQuery. Which BigQuery feature should they use?

A.BigQuery Omni

B.BigQuery ML

C.BigQuery external tables

D.BigQuery BI Engine

AnswerC

External tables let BigQuery query Parquet files in Cloud Storage directly, reading the data in place without ingestion. This satisfies the no-loading constraint, since no data is copied into BigQuery's native storage and queries run against the external source.

Why this answer

BigQuery external tables allow querying data stored in Cloud Storage (including Parquet files) directly without loading it into BigQuery storage. This feature uses a federated query engine that reads the data on the fly, supporting formats like Parquet, Avro, ORC, CSV, and JSON. Option C is correct because it directly addresses the requirement to query Parquet files in Cloud Storage without ingestion.

Exam trap

Google often tests the distinction between features that query external data (external tables) versus features that process data within BigQuery (like BI Engine) or across clouds (Omni), leading candidates to confuse Omni's multi-cloud capability with external data access in the same cloud.

How to eliminate wrong answers

Option A is wrong because BigQuery Omni is designed to query data across multi-cloud environments (AWS, Azure) using BigQuery's interface, not for querying Parquet files in Cloud Storage without loading. Option B is wrong because BigQuery ML is a machine learning feature that enables creating and executing models using SQL, not for querying external data files. Option D is wrong because BigQuery BI Engine is an in-memory analysis service that accelerates dashboard queries on data already stored in BigQuery, not for querying external Parquet files in Cloud Storage.

Full explanation →

728

Multi-Selectmedium

A data warehouse team uses Cloud BigQuery for analytics. They want to optimize query performance and reduce costs. Which three actions should they take? (Choose 3)

Select 3 answers

A.Use partitioned tables on time columns

B.Use clustered tables on frequently filtered columns

C.Use automatic reclustering

D.Use materialized views for aggregations

E.Use BI Engine for all queries

AnswersA, B, D

Partitioning allows queries to skip irrelevant partitions, reducing cost and improving speed.

Why this answer

Partitioning tables on time columns (e.g., DATE, TIMESTAMP) in BigQuery allows the query engine to perform partition pruning, scanning only the relevant partitions instead of the entire table. This directly reduces the amount of data read, lowering query costs and improving performance by limiting I/O to the necessary time range.

Exam trap

Google Cloud often tests the distinction between automatic reclustering as a passive maintenance feature versus an active optimization action, leading candidates to mistakenly select it as a cost-saving measure when it is actually a built-in behavior that does not require manual intervention.

Full explanation →

729

Multi-Selectmedium

Which TWO steps are required to deploy a custom scikit-learn model to Vertex AI for online predictions?

Select 2 answers

A.Write a custom prediction routine

B.Containerize the model using Docker

C.Save the model using joblib or pickle

D.Create a Vertex AI Endpoint manually

E.Upload the model to Vertex AI Model Registry

AnswersC, E

Vertex AI expects a saved model artifact.

Why this answer

Scikit-learn models must be serialized using joblib or pickle to be saved as a model artifact that can be uploaded to Vertex AI. Vertex AI's pre-built prediction containers for scikit-learn expect the model file to be in this format (typically model.joblib or model.pkl) to serve online predictions.

Exam trap

Google Cloud often tests the misconception that you must always write a custom prediction routine or containerize your model, when in fact Vertex AI provides pre-built containers for popular frameworks like scikit-learn, making steps A and B unnecessary for standard deployments.

Full explanation →

730

MCQhard

A company has a production machine learning model deployed on Vertex AI Endpoint that predicts customer churn. The model is retrained weekly using a Vertex AI Pipeline that pulls new data from BigQuery. Recently, the model's accuracy has been declining. The data science team suspects data drift but is unsure. They have enabled Vertex AI Model Monitoring but have not set up any alerts. The team wants to diagnose and address the issue quickly. The pipeline runs successfully, and no errors are reported. The model endpoint is serving predictions with average latency of 200ms. What should the team do first?

A.Immediately trigger a retraining pipeline with more recent data

B.Increase the number of replicas to reduce latency

C.Examine Cloud Logging for prediction errors

D.Review Vertex AI Model Monitoring drift reports and set up alerts for significant drift

AnswerD

Model Monitoring already computes drift metrics, so reviewing its drift reports confirms whether feature or prediction drift explains the accuracy decline. Enabling alerts on significant drift then provides ongoing notification, satisfying the need to diagnose and address the issue quickly without pipeline changes.

Why this answer

The team has already enabled Vertex AI Model Monitoring, which automatically tracks feature distributions and prediction statistics over time. The first diagnostic step should be to review the drift reports generated by Model Monitoring to confirm whether data drift is occurring, and then set up alerts so the team is proactively notified of significant drift in the future. This directly addresses the suspected root cause without unnecessary operational changes.

Exam trap

Google Cloud often tests the misconception that any model performance decline must be fixed by immediate retraining or infrastructure scaling, when the correct first step is always to diagnose the root cause using the monitoring tools already in place.

How to eliminate wrong answers

Option A is wrong because blindly retraining with more recent data without first confirming data drift may waste resources and could even degrade model performance if the new data is not representative or contains label errors. Option B is wrong because increasing replicas addresses latency, not accuracy decline; the current 200ms latency is well within acceptable bounds and is unrelated to the accuracy problem. Option C is wrong because Cloud Logging captures prediction errors (e.g., runtime exceptions, invalid inputs), but the pipeline runs successfully with no errors, so examining logs for errors will not reveal gradual accuracy degradation caused by data drift.

Full explanation →

731

MCQhard

A financial services company deploys a fraud detection model on Vertex AI using a custom prediction container that runs a PyTorch model. The model requires GPU acceleration. The deployment succeeds but predictions return an error: 'CUDA error: out of memory'. What should the team do to resolve this issue?

A.Change the container to use a CPU-only image to avoid CUDA errors

B.Increase the GPU machine type to one with more memory (e.g., from NVIDIA T4 to A100)

C.Enable Vertex AI Model Monitoring to automatically scale the endpoint

D.Add CPU replicas to distribute the inferencing load

AnswerB

CUDA out-of-memory arises when the GPU's VRAM cannot hold the PyTorch model and its tensors. Moving from a T4 to an A100 provides substantially more GPU memory, directly resolving the allocation failure without changing the container or model code.

Why this answer

The CUDA out-of-memory error indicates that the GPU's VRAM is insufficient to load the PyTorch model or process the inference batch. Increasing the GPU machine type to one with more memory, such as from an NVIDIA T4 (16 GB) to an A100 (40 or 80 GB), directly resolves the capacity issue. Vertex AI prediction endpoints allow you to select different accelerator types and sizes, and this change ensures the model fits within GPU memory.

Exam trap

The trap here is that candidates may confuse a resource exhaustion error (out of memory) with a scaling or monitoring issue, leading them to choose options like Model Monitoring or adding CPU replicas, rather than recognizing the need for a larger GPU machine type.

How to eliminate wrong answers

Option A is wrong because switching to a CPU-only image would avoid CUDA errors but would likely cause severe performance degradation or timeout, as the model requires GPU acceleration for acceptable inference latency. Option C is wrong because Vertex AI Model Monitoring is designed for detecting data drift and feature skew, not for scaling endpoints or resolving out-of-memory errors; it does not automatically adjust machine resources. Option D is wrong because adding CPU replicas does not address the GPU memory exhaustion; the error occurs on the GPU, and distributing load across CPU replicas would still route requests to GPU-backed instances that lack sufficient VRAM.

Full explanation →

732

MCQeasy

Your company has a machine learning model that predicts customer churn. The model is deployed on Vertex AI Endpoints with autoscaling. After a marketing campaign, traffic to the endpoint increases by 10x. Some predictions start failing with 'HTTP 503 Service Unavailable' errors. What is the most likely cause?

A.The model container has a memory leak.

B.The model's accuracy has degraded due to data drift.

C.The autoscaling configuration has insufficient maximum nodes to handle the traffic.

D.The model is using an older version that is not supported.

AnswerC

Autoscaling adds replicas only up to the configured maximum node count. A 10x traffic surge can exhaust that ceiling, leaving requests unserved and returning HTTP 503. Raising the maximum node limit lets autoscaling provision enough capacity to absorb the campaign load.

Why this answer

A 503 Service Unavailable error from Vertex AI Endpoints indicates that the endpoint is overwhelmed and cannot handle the incoming request volume. With a 10x traffic spike and autoscaling configured, the most likely cause is that the autoscaling configuration has insufficient maximum nodes, so the endpoint cannot scale out enough to handle the load, causing requests to be rejected.

Exam trap

Google Cloud often tests the distinction between model-level errors (e.g., data drift, accuracy degradation) and infrastructure-level errors (e.g., 503, 429, timeout), so the trap here is that candidates confuse a model performance issue with a scaling/availability issue.

How to eliminate wrong answers

Option A is wrong because a memory leak in the model container would cause gradual performance degradation or OOM kills, not a sudden 503 error under high traffic; Vertex AI would still attempt to serve requests until the container crashes. Option B is wrong because data drift affects prediction accuracy (e.g., wrong predictions), not the availability or HTTP status of the endpoint; 503 errors are infrastructure-level, not model-level. Option D is wrong because using an unsupported older version would cause deployment or startup failures, not transient 503 errors under load; Vertex AI would reject the deployment or return a different error (e.g., 400 or 404) if the version is incompatible.

Full explanation →

733

MCQmedium

Your company ingests millions of events per second into a Pub/Sub topic. The downstream consumer must process events with minimal latency and high throughput. However, the consumer occasionally falls behind during traffic spikes, and you need to ensure no data loss while minimizing costs. Which subscription type and configuration should you choose?

A.Push subscription with a load balancer

B.Pull subscription with flow control settings

C.Push subscription with endpoint on Cloud Run

D.Pull subscription with exactly-once delivery disabled

AnswerB

A pull subscription lets the consumer control retrieval rate, and flow control settings cap outstanding messages and bytes so the subscriber is not overwhelmed during spikes. Pub/Sub retains unacknowledged messages, so throttled consumption prevents data loss while avoiding the cost of over-provisioned resources.

Why this answer

A pull subscription with flow control settings allows the consumer to control the rate of message delivery, preventing overload during traffic spikes. Pull subscriptions are ideal for high-throughput, low-latency processing because the consumer can batch and process messages at its own pace. Flow control settings (e.g., max outstanding messages, max bytes) help avoid overwhelming the consumer, ensuring no data loss while minimizing costs.

Exam trap

PDE often tests the misconception that push subscriptions are always better for low latency, but pull with flow control provides better backpressure and cost control for high-throughput, spiky workloads.

How to eliminate wrong answers

Option A is wrong because a push subscription with a load balancer adds complexity and does not inherently provide flow control; push subscriptions push messages to an endpoint, which can overwhelm the consumer during spikes. Option C is wrong because a push subscription to Cloud Run may have cold starts and concurrency limits, and it lacks fine-grained flow control, risking data loss or high latency. Option D is wrong because disabling exactly-once delivery does not address the need for flow control; it may reduce costs but does not prevent the consumer from falling behind, and exactly-once is not the primary concern here.

Full explanation →

734

Multi-Selectmedium

Which THREE metrics should be monitored to detect model drift in a production ML system?

Select 3 answers

A.Training loss convergence.

B.Prediction distribution (prediction drift).

C.Feature distribution (data drift).

D.CPU utilization of the serving nodes.

E.Model performance metrics (e.g., accuracy, precision, recall) on a ground truth dataset.

AnswersB, C, E

Prediction drift tracks changes in the distribution of model outputs over time. A shifting spread of predicted classes or values, even without labels, signals the model is behaving differently, satisfying drift detection where ground truth is delayed or unavailable.

Why this answer

Option B (prediction distribution / prediction drift) is correct because monitoring how the model's output scores or predicted labels shift over time reveals changes in model behavior even before ground truth labels arrive, which is a core signal of model drift. Option C (feature distribution / data drift) is correct because drift in input features relative to the training distribution (e.g., via PSI, KL divergence, or KS tests) is a leading indicator that the model is being fed data unlike what it learned from. Option E (model performance metrics such as accuracy, precision, recall on a ground truth dataset) is correct because once labeled outcomes are available, degradation in these metrics directly confirms that the model's predictive quality has decayed.

Option A (training loss convergence) is not a drift metric—it is a one-time training diagnostic and does not reflect post-deployment data changes. Option D (CPU utilization of serving nodes) is an infrastructure/operational metric that indicates resource pressure, not statistical or behavioral drift in the model.

Exam trap

A common trap is the misconception that training metrics like loss convergence are relevant for production monitoring, when in fact they are only applicable during the training phase and have no role in detecting post-deployment drift.

Full explanation →

735

MCQeasy

A user gets the above error when trying to get online predictions. The model was created and the endpoint exists. What is the most likely reason?

A.The endpoint does not exist.

B.The endpoint is in a different region than the model.

C.No version of the model is deployed to the endpoint.

D.The model does not exist.

AnswerC

Online prediction requests fail when the endpoint has no deployed model version to route them to. Creating the model and endpoint alone is insufficient; a version must be deployed to the endpoint before it can serve predictions, which is the missing step here.

Why this answer

The error 'No version of the model is deployed to the endpoint' occurs when the endpoint exists but has no active model version assigned to it. In Google Cloud AI Platform (Vertex AI), an endpoint must have at least one deployed model version to serve predictions. Without a deployed version, the endpoint cannot handle inference requests, even though the endpoint resource exists.

Exam trap

Google Cloud exams often test the misconception that creating an endpoint automatically deploys the latest model version, when in fact you must explicitly specify a model version during endpoint creation or update.

How to eliminate wrong answers

Option A is wrong because the user explicitly states 'the endpoint exists,' so the error is not due to a missing endpoint. Option B is wrong because endpoints and models in SageMaker are region-scoped; you cannot create an endpoint in a different region than the model's artifacts, so this scenario would not produce the given error. Option D is wrong because the model exists (the user says 'the model was created'), and the error is specifically about deployment status, not model existence.

Full explanation →

736

MCQhard

An e-commerce company uses Cloud Spanner for order processing. They need to query orders by customer ID and retrieve all order items. Which schema design pattern should they use for optimal performance?

A.Use interleaved tables where Orders is the parent and OrderItems is an interleaved child table with the same primary key prefix.

B.Store all data in a single table with nullable columns for order item attributes.

C.Denormalize by storing order items as a repeated field in the orders table.

D.Create two separate tables with a secondary index on customer_id in the orders table and a secondary index on order_id in the order_items table.

AnswerC

Spanner is a relational database; repeated fields are not supported. Denormalization would break relational integrity.

Why this answer

For this access pattern, the optimal Spanner design is to denormalize order items as a repeated field in the Orders table. A repeated field stores child rows inline with the parent row, so a query by customer_id (with a secondary index on customer_id) retrieves the order and all its items in a single lookup without a join or extra network round-trip. Interleaved tables co-locate child rows with the parent, but they only help when the query uses the parent's primary key prefix; querying by customer_id would still require a secondary index and then a join-like lookup to fetch interleaved children, so option A is not the best fit here.

Exam trap

A common pitfall in Google PDE exams is assuming interleaved tables automatically optimize any parent-child query. Interleaving only provides physical co-location when the query uses the parent's primary key prefix; queries on non-key columns like customer_id still need a secondary index and can incur additional lookups. For read patterns that always fetch the full child set with the parent, a repeated field is often the better denormalization choice.

How to eliminate wrong answers

Option B is wrong because a single table with nullable columns violates normalization, wastes storage, and forces complex queries to filter order-item rows from order rows, eliminating Spanner's interleaving performance benefit. Option C is wrong because storing order items as a repeated field (e.g., ARRAY<STRUCT>) prevents independent indexing and filtering of individual items, and updating a single item requires rewriting the entire order row, causing contention and poor concurrency. Option D is wrong because two separate tables with secondary indexes on customer_id and order_id require a distributed join across splits, incurring cross-node communication and higher latency compared to the co-located access of interleaved tables.

Full explanation →

737

Multi-Selecteasy

Your team is using Cloud Dataprep to clean and transform a dataset. Which TWO features of Cloud Dataprep help you understand data quality issues before running the pipeline? (Choose 2.)

Select 2 answers

A.Scheduling data quality jobs

B.Column histograms

C.Joining datasets

D.Recipe steps

E.Data quality profiling

AnswersB, E

Column histograms render the value distribution for each column, exposing skew, outliers, nulls and unexpected cardinality before the pipeline runs. This satisfies the requirement to understand data quality issues during profiling, letting you spot malformed or dominant values that would otherwise corrupt downstream transformation output.

Why this answer

Option B, column histograms, is correct because Cloud Dataprep generates interactive histograms for each column that visually reveal value distributions, outliers, nulls, and anomalies, letting you spot data quality issues before executing a pipeline. Option E, data quality profiling, is correct because Cloud Dataprep's profiling feature automatically scans the dataset and reports metrics such as missing values, distinct counts, mismatched types, and invalid values, which is exactly the pre-pipeline assessment of data quality described. Option A, scheduling data quality jobs, is not correct because scheduling controls when transformation jobs run, not how you inspect data quality beforehand.

Option C, joining datasets, is not correct because joins are transformation operations that combine data rather than diagnose quality issues. Option D, recipe steps, is not correct because recipe steps define the transformations to apply, not the profiling or histogram analysis used to understand data quality first.

Exam trap

PDE often tests the confusion between transformation features (joins, recipe steps) and diagnostic features (histograms, profiling), so candidates must distinguish understanding data from transforming it.

Full explanation →

738

MCQeasy

Which Google Cloud service would you use to create a unified data catalog that automatically captures lineage from BigQuery, Cloud Storage, and other sources?

A.Cloud Composer

B.Dataflow

C.Data Catalog

D.Dataplex

AnswerD

Dataplex provides a unified data catalogue with automatic metadata discovery and lineage tracking across BigQuery, Cloud Storage and other sources, satisfying the requirement for automatic lineage capture. Its built-in Data Catalog integration and lineage API record transformations without manual annotation, which is precisely the unified, cross-source lineage capability the scenario demands.

Why this answer

Dataplex is Google Cloud's unified data governance and catalog service that automatically discovers, catalogs, and captures lineage across BigQuery, Cloud Storage, and other sources. It provides a unified data catalog with automatic metadata extraction and lineage tracking, which is exactly what the question describes.

Exam trap

The trap is picking Data Catalog because it sounds like the obvious catalog service — but the question emphasizes unified catalog with automatic lineage across multiple sources, which is Dataplex's differentiator.

How to eliminate wrong answers

Option A is wrong because Cloud Composer is a managed Apache Airflow workflow orchestration service, not a data catalog or lineage tool. Option B is wrong because Dataflow is a managed Apache Beam stream/batch processing service, not a catalog. Option C is wrong because Data Catalog is the older standalone metadata service that has been folded into Dataplex — it does not provide the unified, automatic lineage across sources that Dataplex does.

Full explanation →

739

MCQmedium

Your team is designing a data processing system that ingests JSON messages from millions of IoT devices. The ingestion rate is highly variable, with spikes up to 500,000 messages per second. You need a fully managed, serverless messaging service that can buffer messages and decouple producers from consumers. Which Google Cloud service should you choose?

A.Cloud Bigtable

B.Cloud Dataflow

C.Cloud Dataproc

D.Cloud Pub/Sub

AnswerD

Cloud Pub/Sub is a fully managed, serverless messaging service designed for high-throughput, variable workloads. It automatically scales to handle millions of messages per second, buffers messages durably, and decouples producers from consumers. It integrates natively with Dataflow and other GCP services, making it ideal for this IoT ingestion scenario.

Why this answer

Cloud Pub/Sub is the correct choice because it is a serverless, fully managed messaging service that automatically scales to handle variable ingestion rates, buffers messages durably, and decouples producers from consumers. It is purpose-built for high-throughput event ingestion and integrates seamlessly with downstream processing services like Dataflow.

Exam trap

The trap here is confusing a processing service like Dataflow with a messaging service like Pub/Sub, overlooking that decoupling and buffering are messaging concerns.

Full explanation →

740

MCQmedium

A data engineer needs to run an existing Spark job on Google Cloud with minimal code changes. The job requires Hive metastore access. Which Dataproc feature should they use to provide a managed Hive metastore?

A.Cloud SQL for MySQL

B.Dataproc Metastore

C.BigQuery as a Hive metastore

D.Dataproc on GKE

AnswerB

Dataproc Metastore is a fully managed, Hive-compatible metastore service that existing Spark jobs connect to via the standard Hive metastore interface, so no code changes are needed. It satisfies the managed Hive metastore requirement directly, unlike cluster-local or self-managed alternatives.

Why this answer

Dataproc Metastore is a fully managed, highly available Hive metastore service (based on Hive Metastore 2.3/3.1) that can be attached to Dataproc clusters, providing a persistent, serverless metastore without running a separate Hive metastore on a cluster. It allows existing Spark jobs that require Hive metastore access to run with minimal code changes, since the metastore endpoint is configured via cluster properties.

Exam trap

PDE often tests the confusion between a backing database (Cloud SQL) and a managed metastore service (Dataproc Metastore); candidates pick Cloud SQL thinking MySQL is the Hive metastore, missing that the managed service is the correct answer.

How to eliminate wrong answers

Option A (Cloud SQL for MySQL) is wrong because while Hive metastore can technically use MySQL as a backing RDBMS, Cloud SQL alone is not a managed Hive metastore service — you would have to install and manage Hive metastore yourself. Option C (BigQuery as a Hive metastore) is wrong because BigQuery is an analytics data warehouse, not a Hive metastore implementation; it does not expose the Thrift metastore API that Spark/Hive clients require. Option D (Dataproc on GKE) is wrong because it is a deployment model for running Dataproc workloads on Kubernetes, not a managed Hive metastore feature.

Full explanation →

741

MCQhard

A logistics company ingests GPS telemetry from delivery vehicles into Pub/Sub. They need to process the stream in Dataflow to calculate real-time estimated arrival times (ETAs). The pipeline must handle late-arriving data up to 2 hours and must emit results every 5 minutes. The team wants to use Apache Beam's windowing and triggering. Which windowing strategy and trigger should they use to meet these requirements?

A.Fixed windows of 5 minutes with an AfterWatermark trigger that includes a late firing with a 2-hour allowed lateness.

B.Sliding windows of 10 minutes every 5 minutes with an early trigger that fires when the watermark passes the end of the window.

C.Fixed windows of 5 minutes with a default trigger, allowing late data to be dropped after the watermark passes.

D.Session windows with a gap duration of 5 minutes and a repeating trigger every 5 minutes.

AnswerA

Fixed windows of 5 minutes align with the desired emission interval. The AfterWatermark trigger with a late firing allows the pipeline to emit results when the watermark passes (on-time) and again when late data arrives, up to the allowed lateness of 2 hours. This precisely handles late-arriving data and emits updates every 5 minutes, meeting both requirements.

Why this answer

The requirement is to emit results every 5 minutes and handle late data up to 2 hours. Fixed windows of 5 minutes provide the regular emission cadence. The AfterWatermark trigger with a late firing ensures that on-time results are emitted when the watermark passes, and late data triggers additional firings.

Setting allowed lateness to 2 hours ensures that late data is not dropped prematurely. This combination satisfies both the timing and lateness requirements.

Exam trap

The trap here is choosing sliding or session windows for a regular emission interval, or forgetting to configure a late trigger and allowed lateness, which would drop late data.

Full explanation →

742

MCQhard

You manage a Cloud Composer 2 environment that runs a DAG with a task using the BigQueryInsertJobOperator. The task occasionally fails with 'rateLimitExceeded' when submitting many jobs in parallel. You want to limit the number of concurrent BigQuery jobs submitted by this DAG without affecting other DAGs in the same environment. What should you do?

A.Use a pool with a limited number of slots and assign the BigQuery tasks to that pool.

B.Increase the number of workers in the Cloud Composer environment to distribute the load.

C.Configure the BigQueryInsertJobOperator with a lower priority for the jobs.

D.Set max_active_tasks on the DAG to a low value.

AnswerA

Airflow pools allow you to limit parallelism for a specific set of tasks. By creating a pool with a small number of slots and assigning the BigQuery tasks to it, you control how many BigQuery jobs run concurrently, directly addressing the rate limit. This does not affect other DAGs or tasks that are not assigned to the pool, providing a targeted solution.

Why this answer

Airflow pools are designed to limit parallelism for a set of tasks. Creating a pool with a limited number of slots and assigning the BigQuery tasks to it ensures that only a controlled number of BigQuery jobs are submitted concurrently, preventing rateLimitExceeded errors. This approach is scoped to the specific tasks and does not affect other DAGs or tasks in the environment.

Exam trap

The trap here is confusing task-level concurrency controls like max_active_tasks with the need to throttle a specific external service, which is best handled by Airflow pools.

Full explanation →

743

MCQmedium

Your team maintains a BigQuery dataset where a partitioned table 'transactions' is partitioned by DATE(transaction_time) and clustered by customer_id. Analysts frequently run queries filtering on a specific customer_id and a date range of the last 7 days. They report that these queries scan more data than expected, and you notice that the table was created without a partition filter requirement but with a clustering column. Which action should you take to optimize query performance and reduce bytes scanned?

A.Add a partition filter requirement to the table using ALTER TABLE SET OPTIONS(require_partition_filter = true).

B.Recreate the table with clustering on both customer_id and transaction_time to improve filter effectiveness.

C.Change the table to use ingestion-time partitioning instead of column-based partitioning to reduce overhead.

D.Ensure that queries filter on the clustering column customer_id and use the partition column in the WHERE clause to allow partition pruning and cluster pruning.

AnswerD

BigQuery uses partition pruning when the query filters on the partition column, and cluster pruning when it filters on the clustering columns. If analysts are not filtering on customer_id, or if the filter is not applied correctly (e.g., using a function on the column), clustering benefits are lost. By ensuring queries filter directly on customer_id and the partition column, BigQuery can scan only relevant partitions and blocks, reducing bytes scanned and improving performance. This is the correct approach to optimize the query.

Why this answer

The table is partitioned by DATE(transaction_time) and clustered by customer_id. To optimize queries that filter on customer_id and a date range, analysts must ensure their WHERE clause includes both the partition column and the clustering column without transformations. This enables partition pruning and cluster pruning, minimizing data scanned.

Requiring a partition filter or changing clustering does not fix the root cause if queries are not written to leverage the existing schema.

Exam trap

The trap here is assuming that adding a partition filter requirement or additional clustering will automatically improve performance, when the real issue is that queries must filter directly on the existing partition and clustering columns to enable pruning.

Full explanation →

744

Multi-Selectmedium

A data team wants to use Approximate Aggregation Functions in BigQuery to get faster query results. Which two functions can they use? (Choose 2)

Select 2 answers

A.APPROX_SUM

B.APPROX_AVG

C.APPROX_QUANTILES

D.APPROX_COUNT_DISTINCT

E.APPROX_MEDIAN

AnswersC, D

APPROX_QUANTILES returns approximate quantile boundaries from a sample, satisfying the stem's demand for faster results on large datasets. It computes quantiles in a single pass with bounded memory, unlike exact PERCENTILE_CONT which requires full sorting. This makes it a valid Approximate Aggregation Function alongside APPROX_COUNT_DISTINCT.

Why this answer

APPROX_QUANTILES [CORRECT] is a valid BigQuery approximate aggregation function that returns approximate quantile boundaries for a dataset, letting the team trade a small amount of accuracy for much faster results on large data. APPROX_COUNT_DISTINCT [CORRECT] is also a real BigQuery approximate aggregation function that estimates the number of distinct values using HyperLogLog++ sketches, providing fast, scalable cardinality estimates. The other options are not BigQuery functions: APPROX_SUM, APPROX_AVG, and APPROX_MEDIAN do not exist in BigQuery's function library, so they cannot be used for approximate aggregation.

Exam trap

PDE often tests whether candidates know which approximate functions actually exist in BigQuery — the trap is plausible-sounding names like APPROX_SUM, APPROX_AVG, and APPROX_MEDIAN that are not real functions.

Full explanation →

745

Multi-Selectmedium

A company is planning to migrate a legacy batch ETL pipeline to Google Cloud. The pipeline involves reading from a relational database, transforming data, and writing to a data warehouse. Which three Google Cloud services can be used as the orchestration layer? (Choose three.)

Select 3 answers

A.Cloud Dataproc

B.Cloud Scheduler

C.Cloud Dataflow

D.Cloud Workflows

E.Cloud Composer

AnswersB, D, E

Cloud Scheduler can trigger jobs on a schedule, acting as a simple orchestrator.

Why this answer

Cloud Scheduler is a fully managed cron job service that can trigger orchestration workflows on a schedule. It is correct because it can initiate batch ETL pipelines by sending HTTP requests to Cloud Run, Cloud Functions, or Pub/Sub, making it a lightweight orchestration trigger for scheduled batch jobs.

Exam trap

Google Cloud often tests the distinction between data processing services (Dataproc, Dataflow) and orchestration services (Workflows, Composer, Scheduler), so candidates mistakenly select Dataproc or Dataflow thinking they can orchestrate, when they are actually execution engines.

Full explanation →

746

Multi-Selectmedium

A data scientist needs to perform feature engineering for a machine learning model using Vertex AI. They want to preprocess data using a pipeline that includes scaling, one-hot encoding, and handling missing values. Which TWO services can they use to define and execute this preprocessing pipeline? (Choose 2.)

Select 2 answers

A.Cloud Dataproc

B.Vertex AI Pipelines

C.BigQuery SQL with ML.TRANSFORM

D.Cloud Dataflow

E.Cloud Functions

AnswersB, C

Allows you to build and run end-to-end ML pipelines, including preprocessing.

Why this answer

Vertex AI Pipelines is the recommended service for building and running ML pipelines, including preprocessing steps. Alternatively, you can use BigQuery SQL for feature engineering directly on the data, then export the processed data for training. Cloud Dataflow is an option for batch/streaming data processing but is not specific to ML pipelines.

Cloud Functions and Dataproc are less suitable for this purpose.

Full explanation →

747

MCQmedium

A company is building a real-time streaming pipeline using Pub/Sub and Dataflow to process clickstream data. The pipeline writes aggregated metrics to BigQuery every 10 seconds using a fixed window. During peak traffic, some windows produce duplicate rows in BigQuery. What is the most likely cause?

A.Dataflow is retrying BigQuery streaming inserts after a timeout, and the retries succeed even though the original insert succeeded.

B.The pipeline uses default triggers instead of after-watermark triggers.

C.The fixed window duration is too short, causing overlapping windows.

D.The pipeline is using too many Dataflow workers, causing load balancing issues.

AnswerA

BigQuery streaming inserts are at-least-once, not exactly-once. When Dataflow's insert call times out, the bundle is retried; if the original insert actually committed, the retry writes the same window's rows again, producing duplicates. Idempotent deduplication keys or BigQuery Storage Write API with exactly-once semantics prevent this.

Why this answer

Dataflow uses at-least-once semantics for streaming inserts into BigQuery. When a streaming insert times out, Dataflow retries the insert, and if the original insert actually succeeded but the acknowledgment was lost, the retry produces a duplicate row. This is a known behavior of BigQuery streaming inserts with retry logic.

Exam trap

The trap here is that candidates often confuse trigger behavior (Option B) with the root cause of duplicates, not realizing that duplicates stem from retry semantics in the sink, not from windowing or parallelism.

How to eliminate wrong answers

Option B is wrong because default triggers in Dataflow (which fire on element arrival and after watermark) do not cause duplicate rows; they affect when results are emitted, not whether duplicates occur. Option C is wrong because fixed windows of 10 seconds do not overlap by design; overlapping windows would require a sliding window, not a fixed window. Option D is wrong because using too many Dataflow workers can cause resource inefficiency or shuffle issues, but it does not directly cause duplicate rows in BigQuery output.

Full explanation →

Google Professional Data Engineer (PDE) — Questions 676–747