Cloud Digital Leader Practice Question: Google Cloud products, services, and solutions

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Cloud SQL with read replicas in multiple regions

  Why it's wrong here

  Cloud SQL with read replicas provides read scaling but writes remain single-region. Global write consistency across regions requires manual application-level sharding, complex failover, and introduces latency inconsistencies. Cloud SQL does not natively provide globally consistent low-latency writes.

• ✓

  Cloud Spanner, Google's globally distributed relational database with ACID transactions and horizontal scalability

  Why this is correct

  Cloud Spanner uniquely satisfies all three requirements: full ACID compliance for financial transactions, global distribution with strong consistency for low-latency global reads and writes, and horizontal scaling without downtime. It was purpose-built by Google for exactly this class of globally consistent, highly available transactional workloads.

• ✗

  Firestore in Datastore mode with multi-region replication

  Why it's wrong here

  Firestore in Datastore mode is a NoSQL entity/record store whose ACID transactions are confined to entity groups, meaning they can only span a small, pre-defined set of related records and cannot provide the arbitrary multi-record atomicity that financial transactions require. While multi-region replication does copy data across locations, it does not make every read globally strongly consistent—replica propagation is eventually consistent, so write latency and visibility vary by region. Ledger postings, fund transfers, and similar operations need serializable isolation across accounts, which this schema-free, entity-group-limited model cannot offer. Hence, it lacks the global ACID guarantees needed for complex relational financial transaction processing.

• ✗

  BigQuery with streaming inserts for real-time transaction processing

  Why it's wrong here

  BigQuery with streaming inserts is an analytical data warehouse ingestion path, not a transactional OLTP database. Streaming inserts are effectively append-only events that land in a temporary write buffer optimised for bulk analytics, and BigQuery does not support high-concurrency, row-level point updates with locking or multi-record ACID transactions. Although it has some multi-statement SQL transaction support within a single query job, that mechanism is not designed for interactive, low-latency read-modify-write operations from global applications. Thus, using it for real-time financial transaction processing mismatches its columnar, scan-centric architecture and fails to provide the strong consistency and concurrency control required.

Go deeper

Related to this question