Multi-Service Tradeoff — GCP Professional Cloud Architect (PCA)

Whether automating node management alone (GKE Autopilot) satisfies the 'no Kubernetes expertise' constraint, or whether eliminating the Kubernetes control plane entirely (Cloud Run) is required when the workload is stateless, HTTP-driven, and the team cannot absorb pod-spec or cluster lifecycle complexity.

Whether the multi-region external consistency requirement eliminates Cloud SQL and AlloyDB (both regional ACID-compliant, neither providing global external consistency) in favor of Cloud Spanner (multi-region configuration with 99.999% SLA and external consistency).

Whether GKE Autopilot's node-automation sufficiently removes operational overhead for a stateless scale-to-zero HTTP workload, or whether Cloud Run is the correct abstraction level because no Kubernetes-specific capability — pod networking, stateful workloads, multi-container sidecars — is required and the team cannot absorb the Kubernetes control-plane operational model.

Whether to select Cloud Spanner multi-region (external consistency, horizontal scaling, 99.999% SLA) versus Cloud SQL (regional ACID, single-primary) when the workload explicitly requires globally consistent writes across three geographic regions.

Select the storage service and geographic deployment scope that simultaneously satisfies narrow-column high-throughput write ingestion and cross-regional read locality — requiring Bigtable multi-cluster replication with app-profile routing rather than a single-region deployment or a relational service.

Select the compute abstraction level that eliminates cluster and VM operational overhead for a stateless containerized HTTP service owned by a team with no Kubernetes experience, given a scale-to-zero cost requirement.

When a containerized stateless HTTP workload has no pod networking, persistent volume, sidecar, or multi-container requirements, Cloud Run eliminates the Kubernetes control plane entirely — GKE Autopilot reduces node management but retains control plane overhead and Kubernetes API complexity that provide zero value for this workload class.

Select Cloud Spanner over Cloud SQL when a relational OLTP workload requires externally consistent ACID transactions spanning multiple geographic regions at scale, because Cloud SQL is a regional single-primary service incapable of providing multi-region external consistency regardless of replication configuration.

Which GCP compute service correctly matches a containerised stateless HTTP workload with spike-then-idle traffic to the lowest abstraction level that eliminates cluster management — Cloud Run — versus defaulting to Compute Engine VMs (lift-and-shift) or GKE (over-engineered container platform), where the decisive cue combination is: stateless + no Kubernetes expertise + scale-to-zero traffic pattern.

When the workload requires externally consistent ACID transactions that span multiple GCP regions and supports complex relational SQL queries, Cloud Spanner is the required service; Cloud SQL is disqualified because it is a single-region primary service and cannot provide native multi-region external consistency regardless of read-replica count.

Select Dataflow over Dataproc when the pipeline is stateless streaming with no Hadoop or Spark ecosystem dependency and the team cannot sustain cluster management overhead — Dataflow's serverless Apache Beam execution model satisfies both the streaming execution requirement and the zero-ops-cluster constraint simultaneously.

Whether the combination of a streaming execution requirement and a no-cluster-admin operational constraint selects Dataflow (serverless, native streaming windowing, managed runner) over Dataproc (Hadoop/Spark cluster, requires provisioning and lifecycle management, appropriate for existing Spark ecosystem workloads).

When the data flow is continuous and streaming (Pub/Sub source, sub-minute latency, stateful windowed aggregation) and the team has no cluster management capacity, choose Dataflow over Dataproc — Dataflow's Apache Beam streaming runner is native to this execution model and requires no cluster provisioning, while Dataproc's Spark Streaming capability requires cluster lifecycle ownership the team cannot provide.