Select Two (Multi-Select) Questions

Use the Compute Engine default service account on each node.

Why it fails: The Compute Engine default service account is shared by all node workloads and typically holds broad project roles, granting every pod the same permissions. Workload Identity Federation for GKE maps distinct Kubernetes service accounts to distinct Google service accounts. The default account suits throwaway nodes, not least-privilege pod access.

Use a secrets management solution like HashiCorp Vault to store service account keys and retrieve them at runtime.

Why it fails: Vault still stores and distributes static service account keys, so key management and rotation remain, failing the keyless requirement. Workload Identity Federation for GKE lets pods obtain short-lived Google Cloud credentials through IAM binding. Vault fits managing secrets for external systems that lack native federation.

Store service account keys in a Kubernetes Secret and mount them into pods.

Why it fails: Storing keys in a Kubernetes Secret still creates long-lived credentials to manage and rotate, contradicting the keyless requirement. Workload Identity Federation for GKE binds a Kubernetes service account to a Google service account via IAM, issuing short-lived tokens. Secrets suit non-GCP credentials that cannot use federation.

Increase the number of CPUs on the primary instance.

Why it fails: Adding CPUs increases compute capacity for performance, not resilience; it provides no cross-region copy or failover path, so the RPO and RTO remain unmet. It is tempting because vertical scaling is a legitimate response to slow queries, but that addresses throughput rather than disaster recovery.

Create a read replica in the same region.

Why it fails: A same-region read replica shares the regional failure domain, so it cannot serve as a cross-region DR target; the replica must be created in a different region. It is tempting because read replicas do offload read traffic and can be promoted, which suits scaling rather than regional disaster recovery.

Enable deletion protection on the database.

Why it fails: Deletion protection only blocks accidental instance removal; it neither replicates data nor enables recovery, so it cannot meet the one-hour RPO or two-hour RTO. It is tempting because it guards against destructive human error, which is a valid control but unrelated to disaster recovery failover.

Deploy changes directly to production

Why it fails: Deploying straight to production skips the staged validation the scenario demands, so performance regressions surface only after full exposure and rollback depends on retained prior revisions. It is tempting because it is the fastest path to release, and it would be correct for throwaway environments where user impact is nil.

Manually monitor and roll back if issues appear

Why it fails: Manual monitoring and rollback relies on human reaction time, so regressions reach users before anyone notices and reversal is slow. It is tempting because operators do watch dashboards, and it would be correct for low-traffic internal services where automated release tooling is not justified.

A single-region deployment for consistency

Why it fails: A single-region deployment is vulnerable to regional outages.

Load testing to validate performance

Why it fails: Load testing is part of performance testing, not core to DR plan.

Act as a network firewall for Compute Engine instances

Why it fails: VPC Service Controls restricts which identities and networks may reach Google Cloud services; it does not filter packets to Compute Engine instances, which VPC firewall rules and hierarchical firewall policies do. It is tempting because a perimeter sounds like a network boundary, but it operates on service APIs, not instance traffic.

Provide encryption of data in transit between on-premises and Google Cloud

Why it fails: VPC Service Controls governs access to Google Cloud APIs and services at the perimeter boundary; it does not encrypt traffic between on-premises and Google Cloud, which Cloud VPN or Interconnect with IPsec provides. It is tempting because perimeters do control data movement, but that is API-level exfiltration control, not transport encryption.

Replace Identity and Access Management (IAM) for service access control

Why it fails: VPC Service Controls supplements IAM rather than replacing it; IAM still grants the underlying permissions, and the perimeter only adds a boundary condition around them. It is tempting because perimeters do constrain service access, but removing IAM would leave no principal-level authorisation.

Use a custom runner.

Why it fails: A custom runner changes where and how pipeline code executes, not the volume of worker compute consumed, so it does not reduce processing charges. It tempts because custom runners can cut costs for non-Dataflow workloads, but Dataflow billing is driven by worker vCPU and memory hours.

Increase the number of workers.

Why it fails: Adding workers increases the total vCPU and memory hours billed, raising processing cost rather than reducing it. It tempts because more workers shorten wall-clock runtime, but Dataflow charges for aggregate resource consumption, so throughput gains do not offset the extra capacity.

Deploy a Transfer Appliance to copy data to another region weekly

Why it fails: Weekly Transfer Appliance shipments give an RPO measured in days, far exceeding the one-hour target. It tempts as a bulk offline migration tool for very large datasets where bandwidth is constrained, but continuous replication or scheduled backups are needed for sub-hour recovery points.

Use a regional managed instance group and rely on Google's automatic failover

Why it fails: A regional managed instance group spreads replicas across zones and fails over automatically, but this covers Compute Engine availability only; Cloud SQL for MySQL needs its own regional HA and backup configuration to meet the RPO. It tempts because zone failure is the obvious risk, yet the database tier remains unprotected.

Set terminationGracePeriodSeconds to 0 for faster pod termination during scale-down

Why it fails: Incorrect: short grace period can kill active requests.

Enable cluster autoscaler to automatically add nodes when pods are pending

Why it fails: Incorrect: autoscaler helps capacity but not directly pod scheduling resilience.

Set resource requests equal to limits to ensure guaranteed QoS class

Why it fails: Incorrect: QoS class does not directly improve reliability for pod scheduling.

Enable automatic schema detection to avoid manual schema definition.

Why it fails: Automatic schema detection only infers column names and types when loading data; it does not reduce bytes scanned or storage billed. Cost reduction comes from partitioning, clustering and query pruning, not from avoiding manual schema definition.

Use flat-rate pricing with reserved slots.

Why it fails: Reserved slots suit steady, predictable query volumes where committed capacity is cheaper than on-demand; ad-hoc bursts leave slots idle, so you pay for unused capacity. On-demand pricing bills per byte scanned, matching sporadic analytical queries.

Enable private IP

Why it fails: Private IP changes the network path to the instance, not connection handling or query execution, so idle connections and slow queries persist. It is chosen when traffic must avoid the public internet; here, connection pooling and query optimisation address the actual symptoms.

Increase disk size

Why it fails: Disk size affects storage capacity and IOPS ceilings, not idle connection handling or query plan efficiency, so it leaves the stated bottlenecks untouched. It is tempting because larger disks can raise throughput on some engines, and would be right when the instance is genuinely storage-bound or nearing capacity limits.

Store session state in memory

Why it fails: In-memory session state is tied to one VM's lifetime, so a zonal failure destroys it and users are logged out; state must be externalised to a shared store such as Memorystore or Cloud SQL. It is tempting because in-memory sessions are the fastest option for a single-instance, non-redundant deployment.

Use a single zone instance group

Why it fails: A single-zone instance group places every replica in one zone, so a zonal outage removes the entire capacity pool; a regional managed instance group spreads instances across zones. It is tempting because single-zone groups are adequate for dev, test, or workloads with no availability requirement.

Cloud Functions

Why it fails: Cloud Functions runs event-driven serverless code and cannot provision or terminate Compute Engine instances, so it cannot drive a managed instance group's scaling. It is tempting because it executes code in response to triggers, which suits glue tasks such as reacting to Pub/Sub messages or HTTP events, not capacity management.

Cloud Load Balancing

Why it fails: Cloud Load Balancing distributes traffic across instances but does not itself add or remove them; the managed instance group performs the scaling action based on the autoscaling policy. It is tempting because load balancers front autoscaled backends, making it correct when the requirement is even traffic distribution rather than capacity adjustment.

Cloud Monitoring

Why it fails: Cloud Monitoring supplies the CPU utilisation metric that triggers scaling, but a managed instance group is the component that actually adds or removes instances; monitoring alone cannot resize capacity. It is tempting because autoscaling policies are defined against monitoring metrics, making it correct when configuring alerting or dashboards rather than the scaling mechanism itself.

Each VPC network is regional in scope.

Why it fails: VPC networks are global, spanning all regions.

By default, no firewall rules are created in a new VPC.

Why it fails: Default VPC includes default firewall rules (allow internal, allow SSH, etc.).

VPC Peering supports transitive routing.

Why it fails: Transitive routing is not supported; peering is non-transitive.

Use sole-tenant nodes to reduce risk of preemption

Why it fails: Sole-tenant nodes only guarantee physical host exclusivity; they do not exempt workloads from preemption, so failures continue. It is tempting because sole-tenant nodes genuinely address compliance and licensing isolation, which is the correct choice when regulatory separation, not preemption resilience, is the requirement.

Switch to regular (non-preemptible) VMs

Why it fails: Regular VMs eliminate preemption entirely but bill at full on-demand rates, breaching the requirement to avoid significant cost increases. It is tempting because non-preemptible instances genuinely suit latency-sensitive or stateful workloads, which is the correct choice when reliability outweighs cost.

Increase the number of preemptible VMs

Why it fails: Adding more preemptible VMs increases parallel capacity but each instance remains reclaimable, so the job still fails when capacity is withdrawn. It is tempting because horizontal scaling genuinely improves throughput for interruption-tolerant work, which is correct when the goal is speed rather than reliability.

Create a snapshot schedule for the persistent disk every 4 hours

Why it fails: Incorrect: 4-hour RPO exceeds 1 hour requirement.

Use regional persistent disks to automatically replicate data to a second zone

Why it fails: Incorrect: regional PD is within region, not cross-region DR.

CPU utilization

Why it fails: CPU utilization is an internal metric, not customer-facing.

Instance count

Why it fails: Instance count is an infrastructure metric, not a direct health indicator.

Firewall rule to allow traffic to metadata server

Why it fails: Workload Identity reaches the GKE metadata server through the cluster's existing network path; no separate firewall rule is required. It is tempting because on Compute Engine you must permit access to 169.254.169.254, so administrators assume the same explicit rule applies inside GKE.

Cloud NAT for outbound access

Why it fails: Cloud NAT provides outbound internet address translation for private nodes; it plays no part in issuing or federating pod credentials. It is tempting because Workload Identity requires outbound calls to the GKE metadata server and IAM endpoints, and NAT is genuinely needed when private nodes lack external IP addresses.

Encrypt secrets and store them in source code repositories.

Why it fails: Secrets should not be stored in source code, even encrypted, due to risk of exposure.

Pass secrets as environment variables to Compute Engine instances.

Why it fails: Environment variables can be visible in logs and process listings; use Secret Manager instead.

Use Cloud CDN to cache all responses from the application servers.

Why it fails: Cloud CDN caches static, cacheable content; it cannot cache dynamic responses from application servers, so it does nothing for compute-side traffic spikes. It is tempting because CDN offloads load generally, and would be correct for serving static assets or cacheable content close to users.

Use a single Compute Engine instance in a single zone with a large machine type.

Why it fails: A single instance in one zone creates both a capacity ceiling and a single point of failure, so it cannot absorb traffic spikes or survive a zone outage. It is tempting because a large machine type appears to add headroom, and would suit a steady, non-critical workload where availability is not required.

Use vertical scaling by selecting a machine type with more vCPUs and memory.

Why it fails: Vertical scaling resizes a single instance, so it cannot absorb sudden spikes without downtime and caps at the largest machine type; horizontal autoscaling adds instances dynamically. It suits predictable, sustained load growth on stateful workloads where distributing across instances is impractical.

Use Cloud Endpoints to manage API traffic and route deployments.

Why it fails: Cloud Endpoints manages API authentication, quotas and monitoring; it does not control App Engine version traffic splitting, so it cannot prevent deployment downtime. It tempts because it sits in front of APIs and appears to route traffic, but version migration on App Engine is governed by traffic splitting and gradual rollout settings.

Increase the number of idle instances to handle traffic during deployment.

Why it fails: Idle instances are pre-warmed residents that reduce cold-start latency; they do not shift traffic between versions or prevent downtime during a deployment. It tempts because extra capacity sounds like resilience, but idle instances serve the same version, whereas the scenario requires gradual traffic migration to the new version.

Set manual scaling to avoid autoscaling delays.

Why it fails: Manual scaling fixes instance counts, so App Engine cannot add capacity during a traffic shift, worsening the downtime. It tempts because removing autoscaling delays sounds like it stabilises deployments, but manual scaling is intended for predictable, steady workloads; the scenario needs gradual traffic migration across versions instead.