Ensure solution and operations reliability practice questions

Cloud Router: A managed service that provides outbound internet access for private instances via NAT.

Why wrong: Wrong. The definition describes Cloud NAT, not Cloud Router. Cloud Router uses BGP to exchange routes between VPC and on-premises.

Cloud NAT: A managed service that dynamically exchanges routes between VPC and on-premises networks using BGP.

Why wrong: Wrong. The definition describes Cloud Router, not Cloud NAT. Cloud NAT provides outbound internet access for private instances.

Increase the rate limiting threshold

Why wrong: Static threshold changes may not adapt to patterns and could still block legitimate spikes.

Disable the Web Application Firewall (WAF) rules

Why wrong: This removes protection and increases vulnerability.

Use the JSON Web Token (JWT) authentication to filter requests

Why wrong: JWT checks identity but doesn't prevent DDoS at the edge.

Enable cluster autoscaling.

Why wrong: Autoscaling helps with capacity but not with availability during upgrades.

Use StatefulSets instead of Deployments for all services.

Why wrong: StatefulSets are for stateful apps; not needed for all services.

Use node pools with multiple node types.

Why wrong: Different node types do not directly improve availability during upgrades.

Requester pays.

Why wrong: Requester pays is a billing configuration.

Lifecycle management.

Why wrong: Lifecycle management is for automated deletion, not protection.

Uniform bucket-level access.

Why wrong: Uniform access controls access, not durability.

Change the request-path to a different value.

Why wrong: Changing path does not resolve the name conflict.

Delete the existing health check and recreate it.

Why wrong: Deleting may cause disruption if the health check is in use.

Add the --global flag to the command.

Why wrong: Health checks are already global by default.

Use --load-balancer-type internal to create a new health check with the same name.

Why wrong: Load balancer type does not affect health check name uniqueness.

Spanner is already resilient across zones; use backup/restore for regions.

Why wrong: Backup/restore does not provide real-time failover and involves data loss and downtime.

Use multiple instances in different regions.

Why wrong: Multiple independent instances in different regions would require application-level coordination and cannot provide strong consistency globally.

Enable leader placement option.

Why wrong: Leader placement option controls which region hosts the leader but does not handle regional outages automatically.

The MIG is regional and one zone failed.

Why wrong: Regional MIGs automatically redistribute instances across zones; a single zone failure would cause instance recreation in other zones.

The instance template has a startup script error.

Why wrong: A startup script error would cause instances to never become healthy but would not prevent replacement of already unhealthy instances.

The HTTP load balancer's health check is failing.

Why wrong: The load balancer health check determines traffic routing, not instance replacement by the MIG.

Export the database daily using gsutil and import in the other region using pg_restore.

Why wrong: Exporting daily and importing via pg_restore results in RPO of up to 24 hours and RTO much longer than 10 minutes due to restore time, so this does not meet the requirements.

Automated backups with point-in-time recovery to a new instance in the other region.

Why wrong: Automated backups with point-in-time recovery require restoring a backup to a new instance, which can take longer than 10 minutes for a 500 GB database, and RPO depends on backup frequency, typically 1-7 days, so it does not meet the requirements.

Increase the number of nodes in the Spanner instance.

Why wrong: Adding nodes increases capacity but does not directly reduce contention-induced aborts.

Reduce the number of indexes on frequently updated columns.

Why wrong: Fewer indexes reduce write overhead but not transaction aborts due to contention.

Use interleaved tables to co-locate related data.

Why wrong: Interleaving improves join performance but does not directly reduce contention.

CPU requests are too low, causing throttling and eventual crash.

Why wrong: CPU throttling does not cause OOMKill; it slows the pod but memory is the issue.

The node pool is too small, causing memory pressure on the node.

Why wrong: Node memory pressure can cause pod eviction, but if limits are set, pods are killed due to limit, not node pressure.

Memory limits are set higher than the node's allocatable memory.

Why wrong: The scheduler will not place a pod with limits exceeding node capacity, so this would prevent scheduling, not cause crashes.

Increase the maximum number of concurrent function instances.

Why wrong: More instances do not increase memory per instance; the existing instances will still hit the limit.

Enable Pub/Sub batching to reduce the number of function invocations.

Why wrong: Batching reduces invocations but each invocation may still process a large message and exceed memory.

Split the function into multiple smaller functions, each handling a subset of the data.

Why wrong: Splitting functions increases complexity and may not solve the per-message memory issue if each message is large.

Use a Deployment with a PVC that has allowedTopologies restricting to the desired zone.

Why wrong: Deployment pods are not guaranteed to have stable identities, and PVC binding can break on rescheduling.

Use a Deployment with a persistent volume that is manually attached after pod creation.

Why wrong: Deployments do not guarantee persistent pod identity, and manual attachment is error-prone.

Use a StatefulSet with a persistent disk that has access mode ReadOnlyMany.

Why wrong: StatefulSet requires ReadWriteOnce for stateful workloads to allow the pod to write.

Set up alerting on each data point individually.

Why wrong: Alerting on every data point increases noise and false positives.

Decrease the threshold to 400 ms.

Why wrong: Lower threshold increases sensitivity and may cause more false positives.

Change the metric to average latency instead of 99th percentile.

Why wrong: Average latency hides tail latency issues and may miss real problems.

Configure DNS-based failover using Cloud DNS with health checks.

Why wrong: DNS failover is slower and less reliable than load balancer-based failover.

Use an internal load balancer to route traffic between regions.

Why wrong: Internal load balancers handle internal traffic and are not suitable for external user traffic.

Use a regional external HTTP load balancer with a multi-region backend.

Why wrong: Regional load balancers only serve traffic within one region; they cannot failover across regions.

The content is compressed with gzip.

Why wrong: Compression does not affect cache staleness.

The CDN is configured with signed URLs.

Why wrong: Signed URLs control access, not cache freshness.

Use a single-zone node pool with multiple replicas.

Why wrong: Single-zone node pools are vulnerable to zone failures and may become unavailable during upgrades in that zone.

Enable cluster autoscaling to add nodes during upgrades.

Why wrong: Autoscaling adds nodes based on resource demand, not to maintain availability during upgrades.

Enable regional clusters for multi-zone control plane.

Why wrong: Regional clusters provide high availability for the control plane, but node pools must also be multi-zone for workload availability.

Increase the maximum number of Cloud Run instances to 20 to handle more requests.

Why wrong: More instances increase the number of database connections, potentially exceeding the limit further.

Upgrade the Cloud SQL instance to db-n1-standard-4 (15 GB memory) to handle more connections.

Why wrong: A larger machine provides more memory and CPU but does not automatically increase max_connections; also cost increases significantly.

Reduce the concurrency setting on Cloud Run from 80 to 40.

Why wrong: Reducing concurrency reduces throughput and may not fully solve the connection limit issue if the number of instances remains high.

Increase the node pool's machine type to a larger size.

Why wrong: Larger nodes don't help if the application pods are not configured to scale horizontally.

Enable Cluster Autoscaler to add more nodes.

Why wrong: Cluster Autoscaler adds nodes but doesn't scale pods; the issue is pod-level scaling.

Deploy the application in a regional cluster for higher availability.

Why wrong: Regional clusters improve availability but do not address scalability during spikes.

Deploy on GKE with StatefulSets and use Cloud Spanner for global consistency.

Why wrong: Overly complex and costly; Cloud Spanner may not provide low-latency if not regionally deployed.

Deploy on App Engine Standard Environment and use Cloud Firestore in Datastore mode.

Why wrong: App Engine is stateless and Firestore is NoSQL, not suitable for legacy relational app.

Deploy on Cloud Run and use Cloud SQL with read replicas.

Why wrong: Cloud Run is stateless and not ideal for long-running stateful applications.

Increase the number of CPUs on the primary Cloud SQL instance.

Why wrong: Upgrading the primary instance helps but is less cost-effective than read replicas.

Use Cloud SQL Proxy with connection pooling.

Why wrong: Connection pooling helps with connection management, not read throughput.

Enable automatic storage increase to allow more data.

Why wrong: Storage increase does not improve read performance.