Design innovative, scalable, and highly available cloud database solutions →mediumMultiple ChoiceObjective-mapped
PCDE Practice Question: Design innovative, scalable, and highly available cloud database solutions
A team is migrating a relational database to Bigtable. The existing schema uses foreign keys to join orders, customers, and products. Which data model approach is most suitable for Bigtable?
⚠ Common exam trap
The Google Professional Cloud Database Engineer exam often tests the misconception that relational concepts like normalization and joins can be directly applied to NoSQL databases, when in fact Bigtable requires denormalization and careful row key design to achieve performance.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Denormalize orders, customers, and products into a single table with a composite row key.
Bigtable is a wide-column NoSQL database optimized for high-throughput, low-latency access, and it does not support SQL-style joins or secondary indexes in the traditional relational sense. Denormalizing orders, customers, and products into a single table with a composite row key (e.g., customer_id#order_id#product_id) allows all related data to be co-located and retrieved with a single row scan, eliminating the need for joins and aligning with Bigtable's key-value access pattern.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Store each entity in a separate table and use secondary indexes.
Why it's wrong here
Bigtable does not support secondary indexes natively (until recently, but still not recommended for joins).
- ✓
Denormalize orders, customers, and products into a single table with a composite row key.
Why this is correct
Denormalization avoids joins and aligns with Bigtable's access patterns.
- ✗
Use Cloud SQL as a lookup table for joins.
Why it's wrong here
Cross-service joins introduce latency and complexity.
- ✗
Keep the normalized structure and use MapReduce to perform joins.
Why it's wrong here
MapReduce is not real-time and adds latency; Bigtable is designed for direct access.
Go deeper
Related to this question
About these practice questions
One of 1,446 original PCDE practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
Same concept, more angles
3 more ways this is tested on PCDE
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. A company is migrating a relational database to Cloud Bigtable. The source schema has a customers table and an orders table with a foreign key. Which data model approach is recommended for Bigtable?
medium- A.Create a view to join the tables
- B.Maintain two separate tables with foreign keys
- C.Use Cloud Spanner to maintain relational structure
- ✓ D.Denormalize and store orders as a column family within the customer row
Why D: Bigtable is a wide-column NoSQL database, so denormalization is recommended to avoid joins. Embedding order data within customer rows (or using a single table with composite keys) is common. Referential integrity is not enforced.
Variation 2. You are migrating a relational database to Cloud Bigtable. The source schema has a Users table and an Orders table with a one-to-many relationship. The application frequently queries all orders for a user. Which three Bigtable schema design practices should you apply?
hard- ✓ A.Denormalize by storing orders as multiple columns or a serialized column in the Users row
- B.Maintain 3NF to avoid data duplication
- ✓ C.Use a row key that includes a hash prefix to distribute writes
- D.Keep the foreign key relationship by storing UserId in the Orders row key
- ✓ E.Create a separate column family for user attributes and orders
Why A: Cloud Bigtable is a wide-column NoSQL database that does not support joins. To efficiently query all orders for a user, you must denormalize the one-to-many relationship by storing orders as multiple columns (e.g., order_1, order_2) or as a serialized JSON/protobuf column within the user's row. This avoids the need for a separate lookup or join, enabling single-row reads for the user's orders.
Variation 3. A company is migrating a MySQL OLTP database to Bigtable for a time-series application. The current schema uses a relational model with normalized tables. Which two actions should the team take when designing the Bigtable schema? (Choose TWO.)
medium- ✓ A.Denormalize the data into a single wide-column table.
- B.Maintain transactional integrity using Bigtable transactions.
- ✓ C.Salting the row key to distribute writes across nodes.
- D.Create secondary indexes on timestamp columns.
- E.Normalize the schema to reduce data duplication.
Why A: Bigtable is a NoSQL wide-column store optimized for time-series data. Denormalization (option A) is recommended because it avoids joins and creates a single wide table that enables efficient scans over time ranges. Salting the row key (option C) distributes writes across nodes, preventing hot spotting on heavily written time-series data. Option B is incorrect because Bigtable only supports single-row transactions, not multi-row transactions. Option D is incorrect because Bigtable does not support secondary indexes; queries must rely on row key design. Option E is incorrect because normalization leads to multiple tables, which are inefficient in Bigtable.
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This PCDE practice question is part of Courseiva's free Google Cloud certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the PCDE exam.