Firestore collections and documents in GCP - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding Firestore Document Paths

Which of the following is a valid Firestore document path?

A projects/myproject/databases/(default)/collections/users/user123

B projects/myproject/databases/(default)/documents/users/user123

C projects/myproject/databases/(default)/documents/users

D projects/myproject/databases/(default)/documents/user123/users

💡 Hint

Remember that documents are stored inside collections, and the path includes 'documents'.

A Firestore document path includes the 'documents' segment and alternates between collections and documents. Option B correctly shows a collection 'users' and a document 'user123'. Option B incorrectly uses 'collections' instead of 'documents'. Option B points to a collection, not a document. Option B reverses the order of collection and document.

❓ service_behavior

intermediate

Firestore Document Creation Behavior

What happens if you try to create a Firestore document with a path to a non-existing parent collection?

A Firestore throws an error because the parent collection does not exist.

B The document is created but the parent collection remains empty and invisible.

C Firestore automatically creates the parent collection and then the document.

D Firestore queues the creation until the parent collection is manually created.

💡 Hint

Think about how Firestore handles collections and documents dynamically.

Firestore creates collections implicitly when you create a document inside them. You do not need to create collections manually. So, if the parent collection does not exist, Firestore creates it automatically.

❓ Architecture

advanced

Designing Firestore Data Model for Nested Collections

You want to store user profiles and each user's orders as nested collections. Which Firestore structure best supports efficient queries for all orders across users?

A Store all orders in a top-level collection with a userId field (orders/{orderId}).

B Store orders as fields inside each user document as arrays.

C Store orders as a subcollection under each user document (users/{userId}/orders/{orderId}).

D Store orders in a separate database instance linked to users.

💡 Hint

Consider how to query all orders regardless of user efficiently.

Storing orders as a top-level collection with a userId field allows querying all orders across users efficiently. Nested subcollections require collection group queries, which are more complex and less performant for large datasets. Arrays inside documents are limited and not suitable for large or complex order data. Separate databases complicate data access.

❓ security

advanced

Firestore Security Rules for Nested Collections

You want to allow users to read and write only their own orders stored in a nested collection users/{userId}/orders/{orderId}. Which security rule correctly enforces this?

GCP

match /users/{userId}/orders/{orderId} {
  allow read, write: if request.auth.uid == userId;
}

A allow read, write: if request.auth.token.email_verified == true;

B allow read, write: if request.auth.uid == orderId;

C allow read, write: if request.auth.uid != userId;

D allow read, write: if request.auth.uid == userId;

💡 Hint

Match the authenticated user ID with the userId in the path.

The rule allows access only if the authenticated user's ID matches the userId in the document path, ensuring users can access only their own orders. Option D incorrectly compares to orderId. Option D denies access to the owner. Option D checks email verification but does not restrict by user.

✅ Best Practice

expert

Optimizing Firestore Document Size and Structure

Which approach best follows Firestore best practices to avoid exceeding document size limits and maintain efficient queries?

A Store large lists of items as subcollections instead of arrays inside documents.

B Store all related data in a single document to reduce reads.

C Use arrays inside documents to store thousands of items for fast access.

D Duplicate all data in multiple documents to avoid joins.

💡 Hint

Think about Firestore document size limits and query efficiency.

Firestore documents have a size limit of 1 MiB. Storing large lists as subcollections keeps documents small and allows efficient querying and pagination. Storing all data in one document risks exceeding size limits. Large arrays are inefficient and limited. Data duplication can cause consistency issues.