Design and plan a cloud solution architecture: free practice questions

Option A (dedicated project per tenant) provides the strongest isolation boundary on Google Cloud — projects are the primary security and billing boundary. However, at 500 tenants this introduces project management overhead, which is why it works best with strong automation. Option F (pooled tenants per project with IaC automation) balances security isolation (per-tenant datasets and topics) with operational scalability, avoiding the overhead of 500 individual projects while maintaining logical isolation through IAM and resource naming — this is a well-recognized pattern for scaling multi-tenant SaaS on GCP. A single BigQuery dataset with tenant_id (B) provides the weakest isolation — a misconfigured query could expose cross-tenant data, and column-level security alone is not sufficient for strict multi-tenant isolation. Per-tenant datasets with authorized views in a single project (C) is a partial approach but all tenants share project-level resources and quotas, creating noisy-neighbor risks at 500 tenants. Separate GKE clusters per tenant (D) is extremely expensive and operationally prohibitive. A single Pub/Sub topic with filter-based isolation (E) is fragile — subscriber misconfiguration could expose cross-tenant messages and does not provide true isolation.

Dedicated Interconnect with two 10 Gbps circuits is the correct answer. It provides 10+ Gbps of dedicated bandwidth, does not traverse the public internet, and Google offers a 99.9% (single circuit) or 99.99% (redundant circuits) uptime SLA — all three requirements are met. Cloud VPN (A) traverses the public internet and is capped at ~3 Gbps per tunnel; it cannot meet the 5 Gbps non-internet requirement. Direct Peering (B) is used to exchange traffic between a company's network and Google's edge for access to Google Workspace and APIs — it does not connect to a VPC, provides no SLA, and is not a managed hybrid connectivity product. Partner Interconnect (D) does not traverse the public internet and can provide an SLA, but the availability of a 5 Gbps VLAN depends on a third-party provider's topology; Dedicated Interconnect is the more architecturally definitive choice when the bandwidth requirement is at least 10 Gbps and direct physical co-location is available.

Compact placement policies (A) instruct GCP to place instances on physical hosts that are close together in the same zone, minimizing the physical network distance and reducing latency — this is specifically designed for HPC and latency-sensitive workloads. gVNIC (D) is Google's high-performance virtual network interface that supports higher throughput and enables features like higher packet rates and Tier_1 networking, directly improving inter-instance network performance for bandwidth-intensive workloads. Jumbo frames/high MTU (B) reduce per-packet overhead for large transfers but do not meaningfully reduce latency for a message-passing pattern that likely uses smaller messages; also, GCP's default MTU is already 1460 and jumbo frames require specific configuration. External IP addresses (C) would actually route traffic externally and then back in, introducing higher latency — internal IP traffic stays within Google's network fabric and is preferred. Multi-zone placement (E) directly contradicts the co-location requirement and increases latency. Dedicated Interconnect (F) is for connecting on-premises infrastructure to GCP, not for inter-instance communication within GCP.

Cloud Run Jobs are purpose-built for batch workloads: they run a container to completion, then terminate, and you pay only for the execution time. Combined with Cloud Scheduler for triggering, this is the most cost-effective and operationally simple approach for a nightly job. A continuously running Compute Engine instance (A) wastes money for the ~23.5 hours per day when no work is being done. Cloud Composer (B) is a powerful orchestration tool but introduces significant infrastructure overhead and cost for a single simple daily job. Cloud Functions (D) have a maximum execution timeout of 60 minutes (9 minutes for 1st gen), which could be insufficient for a 20–40 minute ETL job, and functions are better suited for event-driven lightweight tasks rather than heavy data transformations.

A modular monolith is a sound recommendation at this stage. With 12 engineers, a 4-month timeline, and unproven service boundaries, the operational overhead of distributed systems (independent deployments, network latency, distributed tracing, service discovery) could slow initial delivery without proportional benefit. Starting with a well-structured monolith allows the team to discover natural service boundaries before committing to distributed architecture. Option A is incorrect — microservices are not universally better; GKE eases deployment but does not eliminate distributed systems complexity. Option C compounds the problem by introducing a service mesh, which adds further operational complexity before boundaries are validated. Option D assumes clear service boundaries exist and that independent deployment is a day-one requirement, both of which are unproven at this stage.