Design for Reliability, Scalability, and Disaster Recovery practice questions

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.

RPO is near zero (synchronous replication); use 'multi-cluster' routing

Why wrong: Bigtable does not support synchronous replication. 'Multi-cluster' routing is not a standard term; the correct term is 'cluster-group routing' or 'any-replica' routing.

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

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

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

Why wrong: Bigtable replication is asynchronous, not synchronous. There is no 'read-failover' policy.

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).

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

Why wrong: There is no 'read-failover' routing policy in Bigtable. The correct policy is 'cluster-group routing' (any-replica).

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

Why wrong: Cloud SQL is not designed for Bigtable workloads (petabyte-scale time-series).

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

Why wrong: Backups restore in hours, not minutes; RTO would be much higher than 10 minutes.

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.

Perform daily exports of Bigtable data to Cloud Storage and import into a new cluster in case of failure.

Why wrong: Daily backups have RPO of up to 24 hours, exceeding 5 minutes. Importing takes hours, exceeding 10-minute RTO.

Migrate the workload to Cloud Spanner multi-region for built-in disaster recovery.

Why wrong: Migrating is a major effort and may not be necessary. Bigtable replication already meets requirements.

Use Cloud Scheduler to trigger a script that takes a Bigtable snapshot every hour.

Why wrong: Hourly snapshots have RPO of up to 1 hour, exceeding 5 minutes. Restoring from snapshot also takes time, likely exceeding 10-minute RTO.

Set the backup retention to 400 days in the Cloud SQL instance settings.

Why wrong: Cloud SQL maximum retention is 365 days. You cannot set it to 400 days.

Create a cross-region read replica and use it as a backup source.

Why wrong: A read replica is not a backup; it is a live copy used for reads or failover. It does not serve as a retention archive.

Use the gcloud command: gcloud sql backups create --instance=myinstance --async and rely on default retention.

Why wrong: Default retention is less than 400 days. This does not meet the requirement.