Deploy scalable and highly available databases in Google Cloud practice questions

RPO is asynchronous (replication lag); use 'any-replica' routing policy

Why wrong: Ly uses 'any-replica' routing policy. The standard policy for automatic read failover is 'multi-cluster routing', not 'any-replica'.

RPO is up to 1 hour; use 'single-cluster' routing

Why wrong: RPO is not up to 1 hour; it is typically seconds to minutes. Also, 'single-cluster routing' does not provide failover to another cluster.

RPO is synchronous (near zero); use 'read-failover' routing policy

Why wrong: RPO is not synchronous, and 'read-failover' is not a standard Bigtable routing policy.

Use Bigtable replication with 'read-failover' routing policy and use Cloud Functions to failover

Why wrong: Wrong. 'read-failover' routing policy only handles read requests, not writes, and Cloud Functions do not provide automatic failover for writes. This option does not meet the RTO of 10 minutes.

Use Cloud SQL for MySQL with cross-region replica for better RPO

Why wrong: Wrong. Cloud SQL for MySQL is not Bigtable. The question specifically asks about Cloud Bigtable, so using a different database is not a valid solution.

Create a scheduled backup every 5 minutes to Cloud Storage and restore in another region on failure

Why wrong: Wrong. Scheduled backups every 5 minutes can achieve RPO of 5 minutes, but restoring from backup typically takes longer than 10 minutes, so it does not meet the RTO. Also, backups are point-in-time and may lose recent writes.

A script to create a new read replica in the DR region

Why wrong: The replica already exists; creating a new one is not part of failover automation.

A Cloud DNS managed zone with a weighted routing policy to split traffic evenly across regions

Why wrong: Weighted routing is not needed; after failover, all traffic should go to the new primary. A simple update to the DNS record is sufficient.

Use Cloud Backup for DR (CBR) to create backup plans

Why wrong: Cloud Backup for DR (CBR) is designed for Spanner, not Cloud SQL, so it is not suitable.

Schedule on-demand backups every 5 minutes and restore to another region

Why wrong: Scheduling on-demand backups every 5 minutes and restoring to another region would result in a higher RPO because restoring from a backup takes longer than 5 minutes.

Use a Cloud SQL HA instance with automatic failover

Why wrong: Cloud SQL HA instances provide automatic failover but only within the same region, so they do not meet the cross-region disaster recovery requirement.

Cloud Spanner

Why wrong: Spanner is a globally distributed relational database optimised for ACID transactions, not single-digit ms time-series reads at millions of QPS.

BigQuery

Why wrong: BigQuery is an analytics data warehouse with query latency measured in seconds. It is not designed for millisecond lookups at IoT scale.

Firestore

Why wrong: Firestore is a document database suited for mobile/web apps with hierarchical data. It does not scale to millions of QPS for time-series workloads.

RPO: up to 1 hour; RTO: up to 24 hours

Why wrong: This is more typical of backup restore, not a read replica promotion.

RPO: near zero (loss of last few transactions); RTO: under 60 seconds

Why wrong: That describes same-region HA failover, not cross-region read replica promotion.

RPO: zero; RTO: less than 1 minute

Why wrong: Only synchronous replication can achieve zero RPO; cross-region read replicas are asynchronous.

A single-region configuration with read replicas in multiple zones

Why wrong: Single-region Spanner does not support failover to another region, so RTO would be higher in a regional outage.

A dual-region configuration with two read-write regions and one read-only region

Why wrong: Spanner multi-region configurations do not have 'dual-region' with two read-write regions; there is only one leader region per instance. This is not a valid config.

A three-region multi-region configuration (e.g., nam-eur-asia1)

Why wrong: Three-region configs have higher write latency due to intercontinental distance, which may impact write latency, but still RPO=0. However, it's overkill for writes from one primary region.

Use a primary instance with a standby in the same zone; RTO less than 10 seconds

Why wrong: A standby in the same zone does not protect against a zone failure. AlloyDB HA requires the standby in a different zone.

Use a primary instance with multiple read pools; RTO less than 5 seconds

Why wrong: Multiple read pools do not provide automatic failover for writes; they are for read scaling.

Use a primary instance with a cross-region read replica; RTO less than 1 minute

Why wrong: Cross-region replicas require manual promotion, not automatic failover in <30s.

The instance must have a backup window configured within the last 2 hours

Why wrong: The backup window is for automatic backups, not directly for PITR. PITR uses transaction logs, not backups.

The instance must have at least one automatic backup taken after the desired restore time

Why wrong: Automatic backups are not needed for PITR; PITR replays transaction logs from a backup, but you can restore from any point within the log retention period.

The instance must be stopped before initiating the restore

Why wrong: You do not need to stop the instance; you can restore to a new instance while the original continues running.

Create a backup with 365-day retention, and before it expires, create another backup to extend coverage

Why wrong: This approach works if you maintain overlapping backups, but it's not a single backup solution; however, the question asks for optimal approach. It's feasible but not the only way.

Create a backup and set the expiration time to 400 days using the gcloud command

Why wrong: Spanner backup expiration max is 365 days. You cannot set it to 400 days.

Use continuous PITR to retain transaction logs for 400 days

Why wrong: Spanner does not support PITR with configurable retention beyond 7 days (default).

Automated backups with PITR

Why wrong: Backups restore in hours, not seconds.

Cross-region read replica

Why wrong: Cross-region read replicas require manual promotion, with RTO in minutes, not seconds.

Enable deletion protection

Why wrong: Deletion protection prevents accidental deletion, but does not provide failover.

Writes continue with increased latency because us-central1 is still available for reads

Why wrong: If us-central1 is down, writes cannot go there; failover to us-east1 occurs.

The Spanner instance becomes read-only until an operator manually fails over

Why wrong: Failover is automatic; no manual intervention needed.

Writes are blocked until the us-central1 region recovers

Why wrong: Spanner automatically fails over to the other region; writes are not blocked.

Promote the cross-region read replica to a standalone instance, then re-create the replica after testing

Why wrong: Promoting the production replica interrupts replication and could cause data loss if not recreated quickly.

Use point-in-time recovery to restore the primary to a new instance in the secondary region

Why wrong: This tests backup/restore, not read replica promotion.

Create a new read replica in the secondary region and promote that

Why wrong: Promoting a new replica also stops replication from the primary, but it's a different replica; however, it does not test the existing DR replica.

Cloud Bigtable

Why wrong: Bigtable offers only eventual consistency across regions, not strong consistency.

Cloud SQL

Why wrong: Cloud SQL is regional and does not offer a multi-region SLA.

Firestore

Why wrong: Firestore provides strong consistency only within a single region; multi-region is eventual.

Set up a load balancer in front of Bigtable instances

Why wrong: Bigtable is accessed via gRPC; putting a load balancer in front is not supported natively.

Create a third cluster in a third region for quorum

Why wrong: Additional clusters are not required for failover; two clusters are sufficient.

Configure Cloud DNS with a health check that points to the secondary cluster

Why wrong: Cloud DNS health checks can be used to route traffic, but Bigtable applications typically connect directly to the Bigtable endpoint; this is not a standard Bigtable failover method.

Point-in-time recovery enabled with 7-day retention

Why wrong: PITR helps with data restoration, but does not provide fast regional failover.

Automated backup with 5-minute frequency

Why wrong: Backups are not suitable for RTO of minutes; restoration takes hours.

Add a cross-region read replica to the existing single-region instance

Why wrong: Spanner does not support cross-region read replicas; multi-region is an instance-level configuration.

Enable point-in-time recovery (PITR) with 7-day retention

Why wrong: PITR does not provide cross-region failover with RPO=0 and RTO<5s; it is for point-in-time recovery within a region.

BigQuery

Why wrong: BigQuery is an analytics data warehouse with query latency measured in seconds. It is not designed for millisecond lookups at IoT scale.

Cloud Spanner

Why wrong: Spanner is a globally distributed relational database optimised for ACID transactions, not single-digit ms time-series reads at millions of QPS.

Firestore

Why wrong: Firestore is a document database suited for mobile/web apps with hierarchical data. It does not scale to millions of QPS for time-series workloads.

Perform regular backups to Cloud Storage and restore in a different zone.

Why wrong: Backup restore has RPO = backup interval (hours) and RTO = hours (restore time). Not acceptable.

Enable cross-region replication using a read replica.

Why wrong: Cross-region read replicas have RPO = replication lag (could exceed 1 minute during peak) and RTO = minutes (manual promotion). Not best for <2 min RTO.

Enable point-in-time recovery (PITR) with transaction log backups.

Why wrong: PITR is used for recovering to a specific point in time, not for zone failover. It does not provide automatic failover to a different zone.

Configure a separate Spanner instance for European traffic and split the database.

Why wrong: Splitting the database would complicate global transactions and is not required. Multi-region configuration is designed to handle global traffic with a single instance.

Add more read-write replicas in the European region.

Why wrong: Adding more read-write replicas does not directly reduce read latency; reads can be served by any replica. The leader region determines write commit location, not read latency.

Use a regional Spanner instance in Europe coupled with a copy of the data in Bigtable.

Why wrong: This would introduce data inconsistency and additional complexity. Spanner multi-region handles both reads and writes globally.