Overview
Storing the data accounts for about 20% of the Professional Data Engineer exam across four official objectives. Objective 3.1 is selecting storage from access patterns among BigQuery, BigLake, AlloyDB, Bigtable, Spanner, Cloud SQL, Cloud Storage, Firestore and Memorystore, plus cost, performance and lifecycle planning. Objective 3.2 is warehouse design: data model, degree of normalization and architecture for access patterns.
Objective 3.3 covers managing and monitoring a data lake, including discovery, access and cost controls. Objective 3.4 covers building a data platform with Dataplex, Dataplex Catalog, BigQuery and Cloud Storage and a federated governance model. Google now calls Dataplex Universal Catalog Knowledge Catalog and documents BigLake as Lakehouse for Apache Iceberg, so this page uses those names while noting the guide's terms.
How it's tested
Domain 3 scenarios describe data shape, volume, latency, consistency needs and query style, and ask where to store the data or how to model it. The most reliable clues are read and write patterns, global reach, transactional needs, retention period and whether users run SQL analytics or point lookups.
-
Pick the store
From latency, scale, schema and consistency clues, choose among BigQuery, Bigtable, Spanner, Cloud SQL, AlloyDB, Firestore, Memorystore and Cloud Storage.
-
Model the warehouse
Decide partitioning, clustering, denormalization with nested and repeated fields, or star schemas to control BigQuery cost and speed.
-
Govern the lake
Use Knowledge Catalog lakes, zones, policies and BigLake tables to give discovery and fine-grained access over Cloud Storage data.
An ad-tech company ingests two million events per second and must serve each user's last hour of activity in under ten milliseconds. BigQuery suits analytics, not single-digit millisecond lookups. Spanner gives transactions it does not need at higher cost. Cloud SQL cannot absorb that write rate. Bigtable with a row key of user ID plus reversed timestamp fits both the throughput and the lookup pattern.
Objectives 4
Official objectives from the Google Cloud outline, in outline order.
3.1 Selecting storage systemsAccess patterns, managed service choice, storage cost and performance, data lifecycle management.
- What it means
- This objective asks you to choose where data lives. You analyze how data is read and written, pick among BigQuery, BigLake, AlloyDB, Bigtable, Spanner, Cloud SQL, Cloud Storage, Firestore and Memorystore, plan for cost and performance, and manage data through its lifecycle.
- What to understand
- Bigtable handles huge write rates and key-range scans with low latency but has no SQL joins or multi-row transactions; row key design avoids hotspots. Spanner offers relational schema, strong consistency and horizontal global scale. Cloud SQL and AlloyDB serve regional relational workloads, with AlloyDB adding faster analytics on PostgreSQL. Firestore stores documents for apps; Memorystore caches. Cloud Storage classes (Standard, Nearline, Coldline, Archive) trade access cost for storage price, and lifecycle rules move or delete objects automatically. BigQuery long-term storage pricing applies to tables unchanged for 90 days.
- How it shows up
- Read the latency and consistency clues; global transactions mean Spanner, massive key lookups mean Bigtable, analytics means BigQuery.
- Common confusion
- Choosing Bigtable for small datasets; it is designed for terabyte scale and high throughput, not a few gigabytes.
3.2 Planning for using a data warehouseDesigning the data model, deciding normalization, mapping business requirements, architecture for access patterns.
- What it means
- Here you design the BigQuery warehouse itself. You choose a data model, decide how far to normalize or denormalize, map business questions to tables and views, and arrange datasets, partitions and clusters around how people query the data.
- What to understand
- BigQuery favors denormalized tables with nested and repeated fields (STRUCT and ARRAY), which avoid costly joins. Star schemas remain common and work well for BI tools. Partition by ingestion time, a date or timestamp column, or an integer range to prune data; cluster on frequently filtered columns to cut bytes scanned further. Require partition filters to block full scans. Materialized views precompute common aggregates. Authorized views and datasets separate raw from curated layers. Slowly changing dimensions can be handled with MERGE statements.
- How it shows up
- Expect a slow or expensive query pattern; partition on the date filter and cluster on the next most selective column.
- Common confusion
- Thinking normalization always improves BigQuery; heavy joins across normalized tables usually cost more than nested data.
3.3 Using a data lakeManaging the lake with discovery, access and cost controls, processing lake data and monitoring the lake.
- What it means
- A data lake keeps raw and refined files, usually in Cloud Storage, for many consumers. This objective covers making that data discoverable, controlling who reads what, keeping costs down, processing lake data and monitoring the lake's health.
- What to understand
- Knowledge Catalog (Dataplex in the guide) organizes buckets and datasets into lakes and zones, discovers files automatically and registers them as tables. BigLake tables, now part of Lakehouse for Apache Iceberg, apply row and column security to files in Cloud Storage and let BigQuery, Spark and other engines read them with consistent permissions. Storage classes and lifecycle rules control cost. Processing can use BigQuery external tables, Spark or Dataflow. Data quality and profiling scans, plus Cloud Monitoring metrics and audit logs, show lake health.
- How it shows up
- Files in Cloud Storage need fine-grained access across engines; look for BigLake tables governed through the catalog.
- Common confusion
- Granting bucket-level IAM to give column-level control; bucket roles cannot hide individual columns.
3.4 Designing for a data platformBuilding a platform from requirements with Google Cloud tools and building federated governance for distributed data.
- What it means
- This objective looks above individual stores to the platform. You assemble Dataplex, Dataplex Catalog, BigQuery and Cloud Storage into a platform that meets stated needs, then design governance that lets separate domains own data while shared rules still apply.
- What to understand
- A federated or data mesh model gives domain teams ownership of their data products in their own projects while a central team sets policies, standards and the catalog. Knowledge Catalog provides a single metadata view, business glossaries, aspects, lineage and data quality across projects. BigQuery datasets act as data products, shared through authorized views or BigQuery sharing. Policy tags enforce column-level security consistently. Cloud Storage holds raw and unstructured data alongside the warehouse.
- How it shows up
- Several business units must own data but follow common rules; choose federated governance with a shared catalog and policy tags.
- Common confusion
- Equating federated governance with no central control; shared standards and catalog remain central.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
Bigtable row key
The single indexed key in a Bigtable table.
- Remember
- Design to spread writes and support range scans.
- Tested as
- Hotspot and lookup questions.
- Trap
- Starting keys with timestamps, which hotspots one node.
-
Spanner
Globally distributed relational database.
- Remember
- Strong consistency with horizontal scale.
- Tested as
- Global transactions and high availability.
- Trap
- Choosing it for analytics workloads.
-
BigQuery partitioning
Splits a table by date, ingestion time or integer range.
- Remember
- Prunes scanned data when filters match.
- Tested as
- Cost and performance cases.
- Trap
- Partitioning on a column nobody filters.
-
BigQuery clustering
Sorts storage blocks by up to four columns.
- Remember
- Further cuts bytes scanned within partitions.
- Tested as
- Pairs with partitioning.
- Trap
- Expecting it to replace partitioning for date filters.
-
Nested and repeated fields
STRUCT and ARRAY columns in BigQuery.
- Remember
- Denormalize without join cost.
- Tested as
- Warehouse modeling questions.
- Trap
- Normalizing everything out of habit.
-
Knowledge Catalog
Unified metadata, discovery, quality and lineage, formerly Dataplex Universal Catalog.
- Remember
- Lakes and zones organize data across projects.
- Tested as
- Lake and platform governance.
- Trap
- Building a separate custom catalog.
-
BigLake tables
Tables over Cloud Storage files with fine-grained security.
- Remember
- Same access rules across BigQuery and Spark.
- Tested as
- Lakehouse scenarios with open formats.
- Trap
- Using plain external tables when column security is needed.
-
Cloud Storage lifecycle rules
Automatic class changes or deletion by age or condition.
- Remember
- Cuts storage cost without code.
- Tested as
- Retention and archive questions.
- Trap
- Writing scripts to move old objects.
-
Policy tags
Column-level access control in BigQuery via taxonomies.
- Remember
- Applied once, enforced for all queries.
- Tested as
- PII column protection.
- Trap
- Creating separate tables for each audience.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
Operational and analytical stores
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| BigQuery | Serverless analytics warehouse. | SQL analytics over huge datasets. | Using it for millisecond point lookups. |
| Bigtable | Wide-column NoSQL at massive scale. | Low-latency key access, high write throughput. | Expecting joins or SQL transactions. |
| Spanner | Global relational with strong consistency. | Horizontal scale plus transactions. | Paying for it when one region is enough. |
| Cloud SQL / AlloyDB | Managed MySQL, PostgreSQL, SQL Server; AlloyDB for PostgreSQL. | Regional relational workloads. | Pushing it past single-instance write limits. |
| Firestore | Serverless document database. | Mobile and web app data. | Choosing it for analytical queries. |
Lake table options
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| External tables | BigQuery reads files in place. | Simple, coarse access control. | Expecting row or column security. |
| BigLake tables | Governed tables over Cloud Storage. | Fine-grained security across engines. | Forgetting the connection's service account needs bucket access. |
| Native BigQuery tables | Data loaded into BigQuery storage. | Best query speed and features. | Loading data that must stay in open formats. |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
BigQuery for everything
- What candidates pick
- Store user profiles for app lookups in BigQuery
- Why it looks right
- BigQuery is the data engineer's main tool.
- Why it's wrong
- It is built for analytics scans, not millisecond single-row reads at high request rates.
Clue to watch for Low-latency lookups per key.
-
Spanner for scale alone
- What candidates pick
- Move a regional app database to Spanner
- Why it looks right
- It scales without limits.
- Why it's wrong
- Spanner costs more and adds no value when Cloud SQL or AlloyDB handles a regional workload.
Clue to watch for Single region, moderate size.
-
Timestamp row keys
- What candidates pick
- Use event time as the leading row key segment
- Why it looks right
- Data is naturally ordered by time.
- Why it's wrong
- Sequential keys concentrate writes on one tablet; prefix with an entity ID or hash.
Clue to watch for High write rate time series.
-
Normalize the warehouse
- What candidates pick
- Split data into many normalized tables
- Why it looks right
- It mirrors OLTP best practice.
- Why it's wrong
- Joins across large normalized tables raise BigQuery cost; nested fields keep related data together.
Clue to watch for Join-heavy, slow BigQuery queries.
-
Copy per audience
- What candidates pick
- Create filtered table copies for each team
- Why it looks right
- Each team sees only its data.
- Why it's wrong
- Copies drift and multiply storage; row access policies, policy tags or authorized views apply rules on one table.
Clue to watch for Different users need different rows or columns.
Answer framework
Run through these steps when a Domain 3 question asks where data should live or how to model it.
- Classify the workload as analytical scans, transactional reads and writes, key-based lookups, document access, caching or archive, using the latency and query style stated.
- Check scale and geography: terabytes of time series point to Bigtable, global consistent transactions to Spanner, and regional relational work to Cloud SQL or AlloyDB.
- For BigQuery, choose partitioning on the main date filter, clustering on selective columns, and nested fields where joins are frequent.
- For lake data, register files through Knowledge Catalog, use BigLake tables when fine-grained security is needed, and set lifecycle rules for cost.
- Confirm governance: policy tags, row access policies, a shared catalog and clear domain ownership for any multi-team platform design.
Practice question
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
Build a one-page storage matrix first. For each service, write its data model, consistency, scale limits, latency and the clue words that select it, and quiz yourself until you can name the store from a two-line scenario. Create a small Bigtable instance and test row key designs with the cbt tool, and spin up a Spanner instance to see how interleaved tables and transactions look.
Then move to BigQuery modeling. Load a public dataset into a partitioned and clustered table, run the same query against an unpartitioned copy and compare bytes processed. Rewrite a join-heavy query using nested fields. For the lake and platform objectives, open Knowledge Catalog, create a lake with raw and curated zones, attach a bucket and see which tables discovery registers. Create a BigLake table and add a column-level policy tag. Close the section by reviewing data mesh ideas and practicing questions that mix storage choice with governance.
FAQ
How much of the GCP PDE exam is Storing the data?
Storing the data makes up about 20% of the exam, so expect roughly 8 to 10 questions on a 40-50 question exam.
Which comparison is tested most in this section?
Choosing between BigQuery, Bigtable, Spanner and Cloud SQL is the classic storage decision, and it appears in many forms across the exam.
Is Dataplex still tested?
Yes. The guide names Dataplex and Dataplex Catalog. Google renamed Dataplex Universal Catalog to Knowledge Catalog in April 2026, so learn the features under both names.
Do I need to know AlloyDB and Firestore in depth?
Know their purpose and when to choose them. AlloyDB is high-performance PostgreSQL with analytics acceleration; Firestore is a document store for apps.
What is the difference between a data lake and a data platform objective?
Objective 3.3 manages one lake's discovery, access, cost and monitoring. Objective 3.4 designs the wider platform and governance model that spans many teams and stores.
How detailed are BigQuery modeling questions?
Expect choices about partition columns, clustering order, nested fields and when to use views. Exact DDL syntax is rarely needed.
Other Data & Analytics certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
Test your Domain 3 knowledge
You have studied storage selection, warehouse modeling, data lakes and platform governance. Test whether you can name the right store from a short scenario.
Keep going
- Training Training Built on your Weak areas
- Practice test Questions by domain, with explanations
- Mock exam Full length, timed like the real exam
- Readiness test Find your weakest domain in minutes
- Cheat sheet Key terms and formulas on one page
- Ask the GCP PDE AI tutor Get any concept explained your way