Practice Test #1

Incorrect. Managed instance group (MIG) health checks apply to Compute Engine VM-based workloads behind load balancers, not to Kubernetes Pods in a GKE Autopilot cluster. In GKE, Pod health and traffic eligibility are controlled by Kubernetes readiness/liveness probes and (optionally) load balancer integrations, not MIG health checks.

Incorrect. A scheduled task that checks availability is a reactive, external mechanism and typically runs at coarse intervals. It cannot reliably gate traffic at the moment new Pods come online during a rolling update, nor does it integrate with Kubernetes endpoint readiness to automatically exclude unhealthy Pods from receiving requests.

Incorrect. Uptime alerts in Cloud Monitoring detect outages and notify operators after symptoms appear. They do not prevent traffic from reaching newly started Pods, and they do not influence Kubernetes readiness or rollout behavior. Alerts are important for operations, but they are not a preventive rollout control.

Cloud NAT provides outbound (egress) NAT for instances without external IPs so they can reach the internet. It does not create an inbound endpoint you can SSH to, and you cannot “SSH to the Cloud NAT IP” to reach a VM. NAT is not a reverse proxy or port forwarder. This option confuses outbound connectivity with inbound administrative access.

An external TCP Proxy Load Balancer would expose a public IP and accept inbound connections on port 22, effectively creating new inbound internet access. It also adds unnecessary complexity and is not a recommended pattern for SSH. Additionally, it conflicts with the requirement to avoid opening new inbound access and undermines least-privilege security posture.

A bastion host with an external IP introduces a new public ingress path, which violates the requirement to avoid opening new inbound internet access. It may also be blocked by the organization policy prohibiting any VM from having an external IP. Even if allowed, bastions increase operational overhead (patching, hardening, key management) compared to IAP’s managed, identity-centric approach.

Unmanaged instance groups with a Network Load Balancer are primarily for distributing inbound network traffic to VMs. They don’t provide built-in autoscaling, autohealing, or declarative instance templates, which increases operational overhead for creating/tearing down up to 800 workers. A load balancer also doesn’t solve batch scheduling; the workload is job-driven, not request-driven. You’d end up scripting your own fleet management, which conflicts with “minimal operational overhead.”

Dataproc is designed for managed Hadoop/Spark clusters and data processing frameworks. The question explicitly says the harness runs Linux-native binaries and shell scripts and must be parallelized without rewriting tests. Moving to Dataproc would either require packaging tests as Spark/Hadoop jobs or running them awkwardly on cluster nodes, adding complexity and cost (cluster lifecycle, YARN/Spark overhead) without clear benefit for simple VM-based workers.

App Engine is a PaaS for web applications with specific runtimes and request-driven execution. It is not intended for running arbitrary Linux binaries and long-running shell scripts with large local artifacts. While Cloud Logging helps observability, it doesn’t address the core need: rapidly scaling a fleet of ephemeral Linux VMs to run batch jobs. App Engine scaling semantics and sandbox constraints make it a poor match for this workload.

Incorrect. Assigning 10.20.0.0/16 to the Google Cloud subnet overlaps with an on-premises range. With HA VPN + Cloud Router (BGP), both sides would have routes to 10.20.0.0/16, causing ambiguous routing and likely blackholing or asymmetric paths. Mirroring on-prem addressing only works if you are not connected simultaneously or if you use NAT, which is explicitly disallowed.

Incorrect. Even though it adds a non-overlapping secondary range for GKE, it still uses 10.20.0.0/16 as the primary subnet range in Google Cloud, which overlaps with on-prem. That overlap will break reachability during coexistence when routes are exchanged dynamically. The requirement is end-to-end reachability without NAT, which requires all routed prefixes to be unique across the hybrid boundary.

Incorrect. Reusing 10.20.0.0/16 as a GKE secondary range still creates an overlap with on-prem. GKE Pod/Service CIDRs are part of the VPC’s IP space and can be advertised/learned across the VPN, leading to conflicting routes. “Policy routing” is not a robust or standard solution for overlapping private ranges across BGP domains and undermines HA and operational simplicity during migration.

Cloud Router does not magically make VPCs reachable. It is a control-plane component used to exchange routes dynamically over Cloud VPN or Cloud Interconnect (BGP). Without an underlying connectivity mechanism (VPN/Interconnect/peering), advertising routes from subnet #2/#3 to subnet #1 does not create data-plane connectivity. Also, even with VPN/Interconnect, this would be network-level connectivity, not the “only Instance #1” scoped access requested.

Two Cloud VPN tunnels would establish VPC #1-to-#2 and VPC #1-to-#3 network connectivity. That violates the requirement that subnets/VPCs must remain isolated, because VPN routing typically enables any permitted resources in VPC #1 to reach VPC #2/#3 (subject to routes and firewall). It also adds operational complexity (HA VPN, Cloud Router/BGP, monitoring) and recurring costs, which is unnecessary for a single-instance requirement.

VPC Network Peering is a network-to-network connectivity feature. Peering VPC #1 with VPC #2 and VPC #1 with VPC #3 would allow resources in VPC #1 (not just Instance #1) to reach resources in VPC #2 and VPC #3 using internal IPs (subject to firewall). This breaks the “must remain isolated” constraint and expands the blast radius. Peering is appropriate when you want broad private connectivity between VPCs, not a single VM exception.

Incorrect. Separate get operations perform 50 independent RPCs (or at least many more than necessary), increasing cold-start time and tail latency and consuming more Datastore API quota/overhead. While each get is still a key lookup (so it avoids indexes), the question explicitly asks to minimize RPCs and retrieval latency, which batch lookup addresses better.

Incorrect. Building a query to filter by IDs is not the optimal Datastore pattern. Queries rely on indexes and query execution, which adds overhead compared to direct key lookups. Datastore does not support a simple, efficient “ID IN (…)” query equivalent for arbitrary sets of keys in the same way as SQL; even if emulated, it would increase index usage and latency.

Incorrect. One query per entity is the worst of both worlds: it increases RPC count (50 queries) and forces index-based query execution for each entity. This maximizes operational overhead and latency, directly conflicting with the requirement to minimize RPCs and index usage. If you know the IDs, queries are unnecessary; use key lookups instead.

Updating the managed instance group for the node pool is an infrastructure rollout (nodes/OS/Kubernetes version), not an application rollout. It does not directly change the container image used by matcher-deploy. It can also cause multiple Pods to be evicted simultaneously during node upgrades unless carefully drained and budgeted, increasing disruption risk. The requirement explicitly says not to change the node pool.

Deleting and recreating the Deployment causes unnecessary disruption: all existing Pods are terminated, and new Pods are created from scratch, which can violate the “no more than 1 pod unavailable” constraint. Even if the Service remains, there will be a period with reduced or zero ready endpoints depending on startup time and readiness. Best practice is to update/apply the Deployment, not delete it.

Services do not reference container images; they select Pods via labels and provide stable networking (ClusterIP) and load balancing. Deleting and recreating the Service can change the ClusterIP (unless explicitly preserved) and can disrupt the Internal HTTP(S) Load Balancer/NEG associations, causing avoidable downtime. Application versioning belongs in the Deployment/Pod template, not the Service.

Cloud Pub/Sub is an excellent managed ingestion service and can scale to very high throughput with low latency. However, its delivery model is at-least-once, and Pub/Sub alone does not provide end-to-end exactly-once delivery to an application. Ordering can be improved with ordering keys, but strict per-merchant FIFO plus exactly-once processing typically requires a processing layer to enforce sequencing and deduplicate.

Cloud Logging is not an event-stream ingestion and processing platform for high-volume payment events. It is optimized for log collection, retention, and analysis, not for strict FIFO ordering, exactly-once delivery, or sub-second stream processing at 80,000 events/sec. Using Logging as an intermediary would add latency, cost, and complexity without providing the required delivery and ordering guarantees.

Cloud SQL is a relational database, not a high-throughput streaming ingestion layer. Writing 80,000 events/sec directly into Cloud SQL would likely hit connection, write throughput, and scaling limits, and it would not inherently provide per-merchant FIFO processing semantics for a downstream microservice. It also risks increased latency and operational constraints compared to a purpose-built streaming pipeline.

Incorrect. Cloud Storage buckets are not zonal resources, so “one bucket per zone” is not a valid or recommended design pattern. Even if interpreted as “one per region,” a single regional location would increase latency for users far from that region and does not meet the requirement to minimize latency for a global audience while following Google-recommended practices.

Incorrect. This option is doubly problematic: it relies on a zonal bucket concept that doesn’t apply to Cloud Storage, and it adds significant operational complexity (multiple buckets, coordination of releases, duplicated IAM/policies, and potential for inconsistent content). While multi-region distribution can reduce latency, Google-recommended practice for simplicity is to use multi-regional storage (and optionally CDN), not many regional buckets.

Incorrect. Creating multiple multi-regional buckets (one per multi-region such as US/EU/ASIA) increases operational overhead and complicates publishing and access management. It can also fragment the dataset and require users to choose the “right” bucket. If the goal is simplicity with broad global access, a single multi-regional bucket is the best fit among the options.