Why NoSQL on GCP matters - Challenge Your Understanding

Challenge - 5 Problems

🧠 Conceptual

intermediate

Why choose NoSQL databases on GCP?

Which of the following is the main reason to use NoSQL databases on Google Cloud Platform instead of traditional SQL databases?

A NoSQL databases on GCP do not support horizontal scaling.

B NoSQL databases on GCP always guarantee ACID transactions across multiple tables.

C NoSQL databases on GCP provide flexible schemas that adapt easily to changing data structures.

D NoSQL databases on GCP require less storage space than SQL databases for the same data.

💡 Hint

Think about how data changes over time and how databases handle that.

NoSQL databases on GCP are designed to handle flexible, evolving data structures by allowing schema changes without downtime. This is unlike traditional SQL databases that require fixed schemas.

❓ Architecture

intermediate

Best GCP NoSQL service for global low-latency access

You want to build a globally distributed application with low-latency data access and automatic scaling. Which GCP NoSQL service fits best?

A Cloud Firestore in Native mode

B Cloud Bigtable

C Cloud SQL

D Cloud Spanner

💡 Hint

Consider which service is designed for mobile and web apps with global reach.

Cloud Firestore in Native mode is a NoSQL document database designed for global distribution with low latency and automatic scaling, ideal for mobile and web apps.

❓ service_behavior

advanced

How Cloud Bigtable handles scaling

What happens when you add nodes to a Cloud Bigtable cluster?

A Data is duplicated on all nodes without redistribution.

B The cluster automatically redistributes data to balance load across nodes.

C The cluster stops accepting writes during scaling.

D You must manually move data to new nodes after adding them.

💡 Hint

Think about how a big table keeps performance smooth as it grows.

Cloud Bigtable automatically redistributes data when nodes are added to balance the load and maintain performance without downtime.

❓ security

advanced

Securing NoSQL data on GCP

Which GCP feature helps protect NoSQL data by controlling who can read or write documents in Cloud Firestore?

A Cloud IAM roles and policies

B Cloud CDN caching

C Cloud Storage lifecycle rules

D Cloud Functions triggers

💡 Hint

Think about how you control user permissions in GCP.

Cloud IAM roles and policies let you control access to Cloud Firestore data by defining who can read or write documents.

✅ Best Practice

expert

Designing for high availability with Cloud Firestore

You want your Cloud Firestore database to remain available even if a whole GCP region goes down. What is the best practice to achieve this?

A Use Cloud Bigtable instead of Firestore for multi-region availability.

B Use Firestore in Datastore mode with single-region configuration.

C Manually replicate data between two Firestore instances in different regions.

D Use Firestore in Native mode with multi-region configuration.

💡 Hint

Consider built-in multi-region support for automatic failover.

Firestore in Native mode with multi-region configuration automatically replicates data across multiple regions to provide high availability and resilience to regional failures.

Practice

1. Why is NoSQL often chosen on Google Cloud Platform (GCP) for certain applications?

easy

A. Because it handles flexible and rapidly changing data well

B. Because it requires complex server management

C. Because it only supports structured data

D. Because it is slower than traditional databases

Solution

1. Step 1: Understand NoSQL data handling

   NoSQL databases are designed to store flexible, semi-structured, or unstructured data that can change quickly.

2. Step 2: Relate to GCP use case

   On GCP, NoSQL services like Firestore and Bigtable support fast-changing data without rigid schemas.

3. Final Answer:

   Because it handles flexible and rapidly changing data well -> Option A

4. Quick Check:

   NoSQL = flexible, fast-changing data [OK]

Hint: NoSQL = flexible data, not rigid tables [OK]

Common Mistakes:

• Thinking NoSQL requires complex server management
• Assuming NoSQL only supports structured data
• Believing NoSQL is slower than SQL

2. Which GCP NoSQL service is best described as a document database?

easy

A. Cloud Spanner

B. Cloud Bigtable

C. Cloud SQL

D. Cloud Firestore

Solution

1. Step 1: Identify document database on GCP

   Cloud Firestore stores data as documents in collections, making it a document database.

2. Step 2: Differentiate from other services

   Cloud Bigtable is a wide-column store, Cloud SQL and Spanner are relational databases.

3. Final Answer:

   Cloud Firestore -> Option D

4. Quick Check:

   Document DB on GCP = Firestore [OK]

Hint: Firestore = document DB, Bigtable = wide-column [OK]

Common Mistakes:

• Confusing Bigtable as document DB
• Choosing relational DBs like Cloud SQL
• Mixing Spanner with NoSQL services

3. Given this code snippet using Firestore on GCP:

doc_ref = firestore_client.collection('users').document('user123')
doc_ref.set({'name': 'Alice', 'age': 30})
user = doc_ref.get().to_dict()
print(user['name'])

What will be printed?

medium

A. user123

B. Alice

C. 30

D. None

Solution

1. Step 1: Understand Firestore document creation

   The code sets a document with fields 'name' and 'age' under 'users/user123'.

2. Step 2: Retrieve and print the 'name' field

   The get() call fetches the document, and user['name'] accesses the 'name' value, which is 'Alice'.

3. Final Answer:

   Alice -> Option B

4. Quick Check:

   Print user['name'] = Alice [OK]

Hint: Set then get document fields to print values [OK]

Common Mistakes:

• Printing document ID instead of field
• Confusing field names
• Assuming None if document exists

4. You try to write data to Cloud Bigtable but get an error. Which mistake likely caused it?

table = bigtable_client.table('my-table')
row = table.row('row1')
row.set_cell('cf1', 'name', 'Bob')
row.commit()

medium

A. Missing column family 'cf1' creation before setting cell

B. Using wrong row key format

C. Calling commit() before set_cell()

D. Bigtable does not support string values

Solution

1. Step 1: Check Bigtable column family setup

   Bigtable requires column families to exist before writing cells; 'cf1' must be created first.

2. Step 2: Verify code sequence and data types

   Row key format is valid, commit() is correctly called after set_cell(), and Bigtable supports string values.

3. Final Answer:

   Missing column family 'cf1' creation before setting cell -> Option A

4. Quick Check:

   Column family must exist before writing [OK]

Hint: Create column family before writing cells [OK]

Common Mistakes:

• Forgetting to create column family
• Assuming commit() order is wrong
• Thinking Bigtable rejects strings

5. You want to build a scalable app on GCP that needs to store user profiles with flexible fields and also handle millions of fast writes per second. Which combination of NoSQL services should you choose?

hard

A. Use Cloud SQL for profiles and Cloud Spanner for writes

B. Use Cloud Bigtable for profiles and Cloud Firestore for writes

C. Use Cloud Firestore for flexible profiles and Cloud Bigtable for high-speed writes

D. Use Cloud Spanner for both profiles and writes

Solution

1. Step 1: Match data needs to NoSQL services

   Cloud Firestore handles flexible, document-based user profiles well.

2. Step 2: Match write speed needs

   Cloud Bigtable supports massive scale and very fast writes, ideal for high throughput.

3. Step 3: Evaluate other options

   Cloud SQL and Spanner are relational and less suited for flexible schema or extreme write speed.

4. Final Answer:

   Use Cloud Firestore for flexible profiles and Cloud Bigtable for high-speed writes -> Option C

5. Quick Check:

   Firestore + Bigtable = flexible + fast writes [OK]

Hint: Firestore for flexible data, Bigtable for speed [OK]

Common Mistakes:

• Choosing relational DBs for flexible schema
• Swapping Firestore and Bigtable roles
• Ignoring write speed requirements