Practice Test #1

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.