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 legacy application from a relational database to Cloud Firestore. The existing schema has a Customers table and an Orders table with a foreign key. The application often shows orders for a customer. What is the recommended data modeling approach in Firestore?
⚠ Common exam trap
Many exam-takers default to relational normalization (separate collections with references or indexes) without considering Firestore's document-based nature, where denormalization and embedding are recommended for common read patterns to avoid multiple queries.
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
✓
Store orders as a nested array within the customer document
Cloud Firestore is optimized for denormalized, document-based data models. Storing orders as a nested array within the customer document allows the application to retrieve all orders for a customer with a single document read, which is efficient for the common query pattern of 'showing orders for a customer.' This approach avoids the need for joins or multiple queries, aligning with Firestore's strengths in read-heavy, hierarchical data access.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Use Cloud SQL instead of Firestore for this relationship
Why it's wrong here
The question asks about Firestore modeling; migrating is not a modeling approach.
- ✗
Create a top-level collection 'Orders' and use reference fields to link to customers
Why it's wrong here
This requires multiple reads to get a customer's orders (like a join), which is less efficient.
- ✓
Store orders as a nested array within the customer document
Why this is correct
Embedding orders (as subcollection or array) allows fetching all orders in one document read, which is efficient for this access pattern.
- ✗
Create separate collections for customers and orders, and use composite indexes for queries
Why it's wrong here
This still requires multiple queries or a collection group query, which is more expensive and slower than embedding.
Go deeper
Related to this question
About these practice questions
This PCDE question is part of Courseiva's 1,446-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
Same concept, more angles
2 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 team is designing a Cloud Spanner schema for an e-commerce platform. They have 'Customer' and 'Order' tables and want to ensure that queries for all orders of a specific customer are efficient. Which schema design approach should they use?
medium- ✓ A.Interleave the 'Order' table under the 'Customer' table with CustomerID as the first part of Orders' primary key
- B.Use a single table with denormalized customer and order data
- C.Use a secondary index on CustomerID in the Order table
- D.Create a separate 'Order' table with a foreign key to Customer
Why A: Spanner supports interleaving tables, where child rows are stored physically near the parent row. Interleaving Orders under Customers using the CustomerID as the first part of the primary key in Orders makes queries for all orders of a customer efficient by colocating related data.
Variation 2. A data engineer is designing a schema for Cloud Spanner to store a hierarchy of customers and their orders. Customers have many orders, and queries often retrieve orders for a specific customer. To optimize performance and reduce cross-node reads, which schema design pattern should the engineer use?
medium- A.Denormalize by embedding order details as a repeated field within the customer row.
- ✓ B.Use a parent-child interleaved table structure where Orders are interleaved in Customers.
- C.Normalize customers and orders into separate tables without any relationship.
- D.Create a secondary index with STORING on the order ID.
Why B: Spanner's interleaved tables allow storing child rows (orders) physically co-located with their parent row (customer) using the same primary key prefix. This enables efficient joins and reduces cross-node reads. A secondary index with STORING is useful for other access patterns but not for hierarchical queries. Denormalization is not recommended in Spanner.
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.