Bird
Raised Fist0
GCPcloud~30 mins

Why NoSQL on GCP matters - See It in Action

Choose your learning style10 modes available
Why NoSQL on GCP Matters
📖 Scenario: You are working for a company that wants to store and manage large amounts of data that changes quickly. They want to use Google Cloud Platform (GCP) to build a system that can handle this data efficiently.
🎯 Goal: Build a simple GCP NoSQL database setup using Firestore to understand why NoSQL is important on GCP.
📋 What You'll Learn
Create a Firestore database instance
Set a configuration variable for the database mode
Write a query to add data to the Firestore collection
Complete the Firestore setup with proper indexing
💡 Why This Matters
🌍 Real World
NoSQL databases like Firestore on GCP are used to store flexible, fast-changing data such as user profiles, chat messages, or product catalogs.
💼 Career
Understanding how to configure and use NoSQL databases on GCP is essential for cloud engineers and developers building scalable, responsive applications.
Progress0 / 4 steps
1
Create Firestore Database Instance
Create a variable called firestore_instance and set it to the string 'projects/my-project/databases/(default)' to represent the Firestore database instance path.
GCP
Hint

Use a string to represent the Firestore database path exactly as shown.

2
Set Firestore Database Mode Configuration
Create a variable called database_mode and set it to the string 'native' to specify the Firestore database mode.
GCP
Hint

The database mode should be set to 'native' as a string.

3
Add Data to Firestore Collection
Write a line of code that adds a dictionary {'name': 'Alice', 'age': 30} to a Firestore collection called users using a variable called add_user to represent this action.
GCP
Hint

Use a dictionary with keys 'collection' and 'data' to represent adding data to Firestore.

4
Complete Firestore Setup with Indexing
Create a variable called index_config and set it to a dictionary with key 'fields' containing a list with one dictionary that has 'fieldPath' set to 'age' and 'order' set to 'ASCENDING' to represent Firestore indexing configuration.
GCP
Hint

Use a dictionary with a 'fields' key containing a list of dictionaries for indexing.

Practice

(1/5)
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
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard