Hard Difficulty Questions

Use the read timestamp to read the latest data

Why wrong: That is essentially a strong read, which causes the latency.

Create a global secondary index on frequently read columns

Why wrong: Indexes can speed up queries but do not reduce read latency for stale reads.

Use DML instead of mutations for writes

Why wrong: DML affects write path, not read latency.

Increase container memory from the default to reduce startup time.

Why wrong: More memory may help but not guarantee warm instances.

Use a larger container image to include more dependencies.

Why wrong: Larger images increase cold start time.

Enable CPU always on allocation.

Why wrong: CPU always on does not keep instances alive if min instances is 0.

Use Cloud Build to deploy with a script that gradually increases traffic using the Cloud Run API.

Why wrong: This is a custom solution and not a managed feature of Cloud Deploy.

Use a Cloud Deploy pipeline with a blue-green strategy that swaps all traffic at once.

Why wrong: Blue-green is an all-at-once switch, not gradual canary.

Use Cloud Run's built-in traffic splitting with `gcloud run deploy --traffic` and manage manually.

Why wrong: This bypasses Cloud Deploy's automation and pipeline management.

Persistent disk with periodic snapshots to a different zone

Why wrong: Snapshots are not frequent enough to achieve 5-second RPO.

Managed instance group with autoscaling and health checks

Why wrong: This handles compute but does not replicate stateful data across zones.

Two instances in different zones with data replicated via rsync

Why wrong: rsync-based replication is asynchronous and unlikely to meet 5-second RPO.

Create a Cloud Build trigger to redeploy on test success.

Why wrong: That creates a new release, not promotion of existing release.

Configure a manual approval gate between staging and production in the delivery pipeline.

Why wrong: Manual approval requires human action, not automatic.

Set the 'automaticPromotion' flag to true on the staging target.

Why wrong: Automatic promotion is based on rollout success, not artifact verification.

Cloud Run with ingress control

Why wrong: Cloud Run ingress control is limited to external access, not fine-grained service-to-service.

Cloud Armor with IAM

Why wrong: Cloud Armor is for DDoS protection, not for service-to-service authentication.

Cloud Endpoints with API keys

Why wrong: Cloud Endpoints is for API management, not for service-mesh level security.

Automated backups are not enabled.

Why wrong: Backups are separate from failover replication.

The failover replica is configured as a read replica instead of a failover replica.

Why wrong: Read replicas cannot be promoted during failover.

The database is not using regional persistent disks.

Why wrong: Regional persistent disks provide durability but not synchronous replication between zones.

Metric type: custom.googleapis.com, condition: metric lower bound, duration: 60s

Why wrong: Metric lower bound is not a valid condition type in Cloud Monitoring.

Metric type: custom.googleapis.com, condition: metric change, duration: 60s

Why wrong: Metric change detects rate of change, not absolute values.

Metric type: custom.googleapis.com, condition: metric absence, duration: 60s

Why wrong: Absence fires when data stops being reported, not when values are below threshold.

Upgrade Cloud SQL to a higher tier with more CPU.

Why wrong: This is costly and does not address the need to reduce database load.

Increase the number of replicas in GKE to reduce load per pod.

Why wrong: This would increase load on Cloud SQL as more pods query it.

Add read replicas to Cloud SQL.

Why wrong: Read replicas help with read scaling but not if the primary is overloaded with writes.

Denormalize by storing post data as a repeated field in Users table

Why wrong: Cloud Spanner does not support repeated fields; that's a Bigtable or Firestore pattern.

Use a local secondary index on user_id in the Posts table

Why wrong: Local indexes are scoped to a split; they do not provide the same locality as interleaved tables.

Create a global secondary index on user_id in the Posts table

Why wrong: A global index would require an extra lookup and does not guarantee locality.

Invoke the function synchronously to avoid duplicates.

Why wrong: Synchronous invocation is not supported for background functions.

Set the function timeout to maximum (540 seconds) to ensure processing completes.

Why wrong: Timeout does not prevent duplicates.

avg(rate(order_processing_duration_seconds_sum[5m])) / avg(rate(order_processing_duration_seconds_count[5m]))

Why wrong: This computes average, not 95th percentile.

histogram_quantile(0.95, sum(rate(order_processing_duration_seconds_bucket[5m])))

Why wrong: Sum is unnecessary and may produce incorrect results.

histogram_quantile(0.95, order_processing_duration_seconds_bucket)

Why wrong: Missing rate function, needed for correct calculation.

The Dataflow pipeline reads from Bigtable using a snapshot read

Why wrong: Snapshot reads are consistent but do not capture changes between snapshots.

The Bigtable table has no primary key

Why wrong: Bigtable tables have row keys, which are primary.

The Dataflow pipeline is using the wrong sink

Why wrong: The sink is BigQuery, which is correct.

Firestore indexes

Why wrong: Indexes improve query performance, not real-time propagation.

Security rules

Why wrong: Security rules control access, not real-time updates.

Offline persistence

Why wrong: Offline persistence lets clients read cached data offline, not real-time sync.

Change the trigger to HTTP

Why wrong: Changing the trigger type changes the event source but doesn't fix the timeout issue.

Reduce the number of function instances

Why wrong: Instance count affects concurrency, not execution time per request.

Increase the function timeout to 9 minutes

Why wrong: Increasing timeout is a temporary fix; the root cause is the slow code that should be optimized.

Set a time-to-live (TTL) on the table

Why wrong: Bigtable does not support TTL at the table level; garbage collection is per column family.

Use a cron job to manually delete rows with timestamps older than 30 days

Why wrong: While possible, it is not efficient; garbage collection is the intended mechanism.

Enable compaction and set a TTL on the table

Why wrong: Compaction is separate from deletion; TTL is not a table-level setting.

Change the source database to use synchronous replication with DMS

Why wrong: Synchronous replication would slow down the source and is not supported for DMS logical replication.

Reduce the maximum WAL size (max_wal_size) on the source to generate smaller logs

Why wrong: Reducing max_wal_size might cause more frequent WAL switches but does not help DMS keep up; it could even increase overhead.

Increase the maintenance_work_mem parameter on the source database

Why wrong: maintenance_work_mem affects maintenance operations (VACUUM, etc.) and does not impact replication lag.

Enable read replicas in different zones

Why wrong: Replicas do not automatically failover, require manual promotion.

Use external read replicas with a failover script

Why wrong: External replicas add complexity and latency, not automatic.

Use Cloud SQL Enterprise Plus edition

Why wrong: Cloud SQL Enterprise Plus edition is available for MySQL and PostgreSQL, not just SQL Server. However, choosing this edition alone does not enable automatic failover across zones; a regional instance with automatic failover must be configured.

Enable point-in-time recovery

Why wrong: Provides backup recovery, not high availability or automatic failover.

Eventual consistency

Why wrong: Eventual consistency does not guarantee immediate visibility of writes.

Global consistency

Why wrong: Global consistency is not a term used in Cloud Spanner; Spanner uses strong consistency.

Bounded staleness

Why wrong: Bounded staleness allows reads to see data that is at most a certain time old, not necessarily the latest write.

Use Cloud SQL with a cross-region replica and configure failover with gcloud

Why wrong: Cross-region replicas are for disaster recovery, not automatic HA within a region.

Set up a Cloud SQL instance with multiple read replicas and use failover via the Cloud SQL Proxy

Why wrong: Cloud SQL Proxy does not handle failover; HA must be configured at the instance level.

Create a read replica in a different zone and configure automatic failover using a load balancer

Why wrong: Read replicas are asynchronous and not used for automatic failover; Cloud SQL HA uses synchronous replication.