Google Cloud Professional Cloud Architect: Design and plan a cloud solution architecture Practice Questions

Cloud Run is the best fit because it is a fully managed serverless container platform that scales automatically from zero to hundreds of instances, charges only for request processing time, and handles HTTP traffic natively. It is well-suited for stateless HTTP services with variable traffic. Cloud Functions (2nd gen) is also serverless and pay-per-execution, but Cloud Run is preferred for HTTP microservices that may have longer execution times or need container-level control — both are viable, but Cloud Run is the more architecturally idiomatic choice for a persistent HTTP endpoint at this traffic level. A single Compute Engine instance does not scale automatically and would be a single point of failure. GKE Autopilot reduces node management but still requires cluster-level management, persistent costs, and is overengineered for this simple stateless HTTP use case.

Bigtable is designed for extremely high-throughput, low-latency reads and writes at massive scale (millions of QPS), making it the best fit for a high-frequency leaderboard. With multi-cluster routing, reads can be served from the nearest cluster with single-digit millisecond latency. Cloud Spanner (E) offers global consistency and horizontal scaling, but its typical read latency is in the low tens of milliseconds due to distributed consensus overhead — it may not reliably achieve sub-10ms globally. Cloud SQL (C) is a managed relational database but is not designed to handle thousands of writes per second at global scale; cross-region read replicas also introduce replication lag. Firestore (A) is a great fit for document-oriented, mobile/web use cases but is not optimized for the extremely high write throughput of a global gaming leaderboard at this scale. Memorystore (D) provides in-memory speed but is regional; cross-region replication is not natively supported and would require significant custom engineering.

Option C (Organization Policy constraints) provides preventive, policy-as-code controls: 'constraints/gcp.resourceLocations' enforces which regions resources can be created in, and service usage constraints can restrict which Google APIs are enabled—exactly matching both requirements. Option A (Assured Workloads) is designed for regulated workloads and automatically configures data residency and access controls including region restrictions and restricted API services based on compliance regimes (e.g., FedRAMP, IL4); it directly addresses both requirements in an integrated, compliance-validated way. Together, these two provide robust preventive enforcement. Option D (VPC Service Controls) addresses data exfiltration between services, not region or API enablement restrictions. Option F (Cloud Asset Inventory with BigQuery) is detective and after-the-fact, not preventive. Option B (IAM conditions) can restrict API call destinations in some cases but is not the standard mechanism for restricting resource creation regions across an org or controlling which services are enabled. Option E (SCC with alerting) is also detective and reactive, not preventive enforcement.

Option D is correct. Cloud NAT in a Shared VPC is configured at the host project level, but it must be explicitly associated with the specific subnets whose instances should use it. If the Cloud NAT gateway is associated only with certain subnets (or set to 'Custom' subnet mode without including the service project's subnets), instances in unincluded subnets will not have outbound internet access. Option C is incorrect: Cloud NAT in the host project can serve instances in service projects that use subnets from the shared VPC — it is not restricted to host project instances. Option A is a misconception: service project instances with no external IP can absolutely use Cloud NAT; that is one of the primary use cases for Cloud NAT in Shared VPC environments. Option B is plausible but incorrect as the primary cause: GCP VPC firewall rules have no default egress deny rule (default egress is allow-all); a misconfigured NAT subnet association is a much more common and specific root cause.

Option C is mathematically correct. Each n2-standard-8 node has 8 vCPU and 32 GB RAM. After Kubernetes system reservations (0.5 vCPU, 1.5 GB RAM), the allocatable capacity is 7.5 vCPU and 30.5 GB RAM. Each pod requests 2 vCPU and 4 GB RAM. Packing by vCPU: floor(7.5 / 2) = 3 pods per node. Packing by RAM: floor(30.5 / 4) = 7 pods per node. CPU is the binding constraint, so each node can schedule 3 pods. To schedule 100 pods: ceil(100 / 3) = 34 nodes. Options A and D contain arithmetic errors and self-contradictions, making them clearly wrong. Option B correctly walks through the math but then presents an incorrect final answer (34 nodes but labels it as '14'), making it internally inconsistent and wrong. Option C presents the correct full calculation and arrives at the right answer of 34 nodes.