GCP PDE · Domain 4 of 5

GCP PDE Domain 4: Preparing and using data for analysis

Get data ready for people and models: fast BI with BigQuery features, secure masking, feature and embedding preparation for ML and RAG, and controlled sharing through BigQuery sharing.

Exam weight
~15%
Official objectives
3
Estimated questions estimate
6–8
Suggested study time estimate
10–14 hrs

About 11 min read Reviewed October 2026

Overview

Preparing and using data for analysis is the smallest section of the Professional Data Engineer exam at about 15%, with three official objectives. Objective 4.1 covers visualization readiness: connecting tools, precalculating fields, BigQuery BI features such as BI Engine and materialized views, troubleshooting slow queries, and security with masking, IAM and Cloud DLP. Objective 4.2 covers preparing data for feature engineering, training and serving with BigQuery ML, and preparing unstructured data for embeddings and retrieval-augmented generation.

Objective 4.3 covers sharing: rules, publishing datasets and reports, and BigQuery sharing, which the guide also labels Analytics Hub. Cloud DLP is now part of Sensitive Data Protection, and Vertex AI is now Gemini Enterprise Agent Platform, so this page uses the current names. Although the weight is modest, the gen AI preparation topic is newer and often underprepared.

How it's tested

Domain 4 questions focus on a consumer: a dashboard, an analyst group, a model or an external partner. They ask which BigQuery feature, preparation step or sharing method serves that consumer with the right speed, cost and protection. Read who the consumer is and what they must not see.

  • Speed up BI

    A dashboard is slow or costly and you choose BI Engine, materialized views, precomputed tables or query fixes.

  • Protect while sharing

    Analysts or partners need access with masking, row filters or column restrictions, and you choose the right control.

  • Ready for ML and RAG

    You pick feature preparation in BigQuery ML or chunking and embedding steps for unstructured documents.

Reasoning it through

Marketing analysts in Looker filter a 5 TB sales table by region and date many times a day, and dashboards take twenty seconds. A materialized view aggregating sales by region and day shrinks the data scanned, and BI Engine reservation caches it in memory for subsecond responses. Exporting to a spreadsheet loses freshness, and adding slots alone would not cut scanned bytes.

Objectives 3

Official objectives from the Google Cloud outline, in outline order.

4.1 Preparing data for visualizationConnecting tools, precalculating fields, BI Engine and materialized views, query troubleshooting, security and masking.
What it means
This objective is about making data ready for dashboards and analysts. You connect BI tools to BigQuery, precompute fields that dashboards need, use BigQuery features that speed up BI, fix slow queries, and secure data with IAM, masking and sensitive data discovery.
What to understand
Looker connects to BigQuery through a semantic model, and Connected Sheets brings BigQuery into Google Sheets. Precalculating aggregates in tables or materialized views avoids repeated work; BigQuery refreshes materialized views incrementally and can rewrite queries to use them. BI Engine is an in-memory reservation that accelerates SQL from BI tools. For slow queries, read the execution graph, avoid SELECT *, filter on partitions early, and reduce data skew. Dynamic data masking with policy tags shows nulls, hashes or partial values to unauthorized users, and Sensitive Data Protection (Cloud DLP in the guide) finds PII to tag.
How it shows up
A dashboard is slow or costly, or some viewers must see masked values; pick the BigQuery feature that fits.
Common confusion
Thinking BI Engine reduces bytes billed by itself; it speeds queries in memory, while materialized views reduce work.
4.2 Preparing data for AI and MLPreparing data for feature engineering, training and serving with BigQuery ML, and unstructured data for embeddings and RAG.
What it means
This objective covers getting data model-ready. You engineer features and prepare training and serving data with BigQuery ML, and you turn documents and other unstructured content into chunks and vector embeddings that retrieval-augmented generation applications can search.
What to understand
BigQuery ML trains models with SQL, and the TRANSFORM clause stores preprocessing such as scaling, bucketizing and one-hot encoding so the same logic runs at prediction time, avoiding training-serving skew. Features can be shared through the Agent Platform Feature Store, which serves BigQuery data online. For RAG, extract text from files with Document AI or object tables, split it into chunks, generate embeddings with ML.GENERATE_EMBEDDING using a Gemini embedding model, store vectors in BigQuery and query with VECTOR_SEARCH, optionally backed by a vector index.
How it shows up
A model performs worse in production than in training, or documents must feed a gen AI assistant; choose consistent preprocessing or an embedding pipeline.
Common confusion
Applying preprocessing only in training code, which creates skew; TRANSFORM or shared feature pipelines keep serving consistent.
4.3 Sharing dataDefining sharing rules, publishing datasets, publishing reports and visualizations, BigQuery sharing (Analytics Hub).
What it means
This objective covers giving data to others under control. You define who may see what, publish datasets for internal or external consumers, publish reports and dashboards, and use BigQuery sharing to offer data through exchanges and listings.
What to understand
BigQuery sharing (formerly Analytics Hub) lets a publisher create exchanges and listings; subscribers get a linked dataset that reads the source without copying it, so updates appear immediately and the publisher keeps control. Data clean rooms let parties combine data under analysis rules without seeing raw rows. Authorized views and authorized datasets share query results without granting table access. Row access policies filter rows by user. Reports can be shared through Looker with its own permissions. Egress controls on listings can block subscribers from copying or exporting data.
How it shows up
A partner or another business unit needs live data without copies; choose BigQuery sharing listings, adding clean rooms for joint analysis.
Common confusion
Exporting CSV files to share data; copies go stale and escape governance controls.

High-yield concepts

The terms, rules and formulas this domain turns into questions most often.

  • BI Engine

    In-memory acceleration reservation for BigQuery.

    Remember
    Subsecond BI queries on cached data.
    Tested as
    Slow dashboard scenarios.
    Trap
    Expecting it to lower bytes scanned.

  • Materialized views

    Precomputed, incrementally refreshed query results.

    Remember
    BigQuery can automatically rewrite queries to use them.
    Tested as
    Repeated aggregate queries.
    Trap
    Using them for non-deterministic or unsupported functions.

  • Dynamic data masking

    Column masking rules attached through policy tags.

    Remember
    Users see masked values unless authorized.
    Tested as
    Analysts must not see raw PII.
    Trap
    Creating separate masked table copies.

  • Authorized views

    Views granted access to source data on behalf of users.

    Remember
    Users query the view without table access.
    Tested as
    Sharing subsets securely.
    Trap
    Granting table access alongside the view.

  • TRANSFORM clause

    Preprocessing stored inside a BigQuery ML model.

    Remember
    Same logic at training and prediction.
    Tested as
    Training-serving skew questions.
    Trap
    Repeating preprocessing manually at serving time.

  • ML.GENERATE_EMBEDDING

    BigQuery function creating vector embeddings with a remote model.

    Remember
    Embeddings stay next to the data.
    Tested as
    RAG preparation scenarios.
    Trap
    Exporting data to embed elsewhere without need.

  • VECTOR_SEARCH

    BigQuery similarity search over embeddings.

    Remember
    A vector index speeds large searches.
    Tested as
    Retrieval step in RAG.
    Trap
    Using keyword LIKE matching for semantic search.

  • BigQuery sharing

    Exchanges and listings for sharing datasets, formerly Analytics Hub.

    Remember
    Subscribers get linked, read-only datasets.
    Tested as
    Cross-organization sharing.
    Trap
    Copying data to each partner project.

  • Data clean rooms

    Privacy-centric shared analysis spaces in BigQuery sharing.

    Remember
    Analysis rules limit what can be queried.
    Tested as
    Joint analysis without exposing raw rows.
    Trap
    Granting partners direct table access.

Side by side

Concepts candidates mix up, compared on the point that decides the answer.

Dashboard performance features

ConceptMeaningKey differenceCommon trap
BI Engine In-memory query acceleration. Speeds queries; billing by reservation size. Expecting it to shrink scanned data.
Materialized views Stored, auto-refreshed aggregates. Reduce compute and bytes scanned. Assuming any SQL can be materialized.
Precomputed tables Scheduled aggregate tables. Flexible but refresh is manual or scheduled. Forgetting they can go stale between runs.

Ways to share data

ConceptMeaningKey differenceCommon trap
BigQuery sharing listings Linked datasets via exchanges. No copy, live, publisher-controlled. Thinking subscribers get a copy.
Authorized views Views that query restricted tables. Share a filtered subset in the same org. Also granting base table access.
Data clean rooms Controlled joint analysis. Raw rows never exposed. Using them for simple internal sharing.
File exports CSV or Parquet copies. Leaves governance behind. Choosing it when live data is needed.

Exam traps

Each trap is an answer that looks right. Learn the clue that should change your mind.

  1. More slots for slow BI

    What candidates pick
    Buy more BigQuery capacity
    Why it looks right
    More compute usually means faster.
    Why it's wrong
    If queries scan huge tables repeatedly, materialized views or BI Engine solve it at lower cost.

    Clue to watch for Same aggregate queries run constantly.

  2. Masked table copies

    What candidates pick
    Create a sanitized copy of each table
    Why it looks right
    Copies seem simple and safe.
    Why it's wrong
    Copies drift, double storage and need separate pipelines; dynamic masking applies rules at query time.

    Clue to watch for Some users need masked, others full values.

  3. Embed outside the warehouse

    What candidates pick
    Export documents to a custom service to create embeddings
    Why it looks right
    Specialized services feel more capable.
    Why it's wrong
    BigQuery can generate embeddings and run vector search in place, with less movement and governance risk.

    Clue to watch for Documents and metadata already in BigQuery or Cloud Storage.

  4. Share by export

    What candidates pick
    Send partners scheduled CSV files
    Why it looks right
    Every partner can read CSV.
    Why it's wrong
    Files go stale, escape access controls and cannot be revoked; linked datasets stay live and governed.

    Clue to watch for External partner needs current data.

  5. View without authorization

    What candidates pick
    Create a view and grant table access too
    Why it looks right
    Users need permission to read the underlying data.
    Why it's wrong
    Authorized views exist so users can query the view without any access to base tables.

    Clue to watch for Users must not read the raw table.

Answer framework

Use these steps for Domain 4 questions about serving data to people, models or partners.

  1. Identify the consumer: a BI dashboard, an analyst group, a training pipeline, a gen AI application or an external organization outside your company.
  2. For dashboards, reduce work first with materialized views or precomputed tables, then add BI Engine when subsecond interactive response is required.
  3. For sensitive fields, discover them with Sensitive Data Protection, tag them with policy tags and apply dynamic masking or row access policies.
  4. For ML and RAG, keep preprocessing consistent with TRANSFORM or a feature store, and build chunk, embed and vector search steps close to the data.
  5. For sharing, prefer BigQuery sharing listings or authorized views over copies, and add data clean rooms when partners must not see raw rows.

Practice question

A retailer wants to share daily updated sales data with 40 suppliers, each in its own Google Cloud organization. Suppliers must see current data without the retailer maintaining copies, and the retailer must be able to revoke access at any time. What should the data engineer do?

Want more like this? The GCP PDE practice test has questions for every domain.

Checklist

0 of 11

Tick each one you can do without notes. Your ticks stay in this browser.

Study strategy

Although this section is the smallest, its features are concrete and easy to practice, which makes it good value per hour. Start in BigQuery with a public dataset: create a materialized view, run a matching aggregate query and check whether BigQuery rewrote it to use the view. Create a small BI Engine reservation and compare dashboard response in Looker or Connected Sheets.

Next, set up a taxonomy with a policy tag on an email column and add a masking rule so a test user sees hashed values. Build an authorized view and confirm the test user cannot query the base table. For ML, train a BigQuery ML model with a TRANSFORM clause and call ML.PREDICT on raw input. For RAG, create a remote embedding model, embed a few text rows with ML.GENERATE_EMBEDDING and query them with VECTOR_SEARCH. End by creating a BigQuery sharing exchange, subscribing from another project and noting what the subscriber can and cannot do.

FAQ

How much of the GCP PDE exam is Preparing and using data for analysis?

Preparing and using data for analysis is the smallest section at about 15%, roughly 6 to 8 questions on a 40-50 question exam.

Is Analytics Hub still the name to know?

The guide writes BigQuery sharing with Analytics Hub in brackets. Google's documentation now uses BigQuery sharing, so recognize both.

How much gen AI is in this section?

The guide names preparing unstructured data for embeddings and RAG. Expect questions on chunking, embedding generation and vector search rather than model tuning.

Do I need deep BigQuery ML knowledge?

Focus on data preparation: feature engineering, the TRANSFORM clause, and splitting data for training and evaluation. Model architecture details belong to the Machine Learning Engineer exam.

Which security features matter most here?

Policy tags, dynamic data masking, row access policies, authorized views and Sensitive Data Protection discovery are the core controls for analysis data.

Will questions name specific BI tools?

Looker and Connected Sheets are the Google tools most likely to appear, but questions usually test the BigQuery features behind the dashboard.

Other Data & Analytics certifications

Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.

Test your Domain 4 knowledge

You have reviewed BI readiness, data protection, ML and RAG preparation and sharing. See whether you can pick the right BigQuery feature for each consumer.

Take the GCP PDE practice test Check your GCP PDE readiness

Keep going