Commonly Confused Services on the GCP PCA

Deciding signal

Cloud Pub/Sub is a global, real-time messaging service for event-driven architectures — publishers push messages and one or more subscribers receive them asynchronously. It is the right answer for decoupling services, streaming event data, and fan-out to multiple consumers. Cloud Tasks manages a queue of work to be executed by HTTP endpoints or Cloud Run services — you explicitly enqueue tasks and control retry, rate limiting, and deduplication. It is the right answer for managing a backlog of discrete units of work with controlled execution. Cloud Scheduler is a fully managed cron job service — it sends HTTP/HTTPS requests or Pub/Sub messages on a defined schedule (every hour, at midnight, etc.). When the scenario involves triggering something on a time schedule, Scheduler. Managing a queue of tasks with rate limiting, Tasks. Real-time event messaging between services, Pub/Sub.

Deciding signal

Cloud Dataflow is a fully managed, serverless data processing service based on Apache Beam — it processes both streaming and batch data without managing infrastructure. It is the right answer for ETL pipelines, streaming analytics, and data transformations where serverless management is preferred. Cloud Dataproc is a managed Spark and Hadoop service — you provision clusters and run Spark jobs, Hive queries, or Pig scripts. It is the right answer when the workload requires existing Spark or Hadoop code, libraries, or specific configuration not supported by Dataflow. BigQuery is a serverless analytics warehouse — it runs SQL queries over large stored datasets and is not an ETL or stream processing tool. When the scenario involves SQL analytics on stored data, BigQuery. ETL transformations on streaming or batch data, Dataflow. Custom Spark or Hadoop workloads, Dataproc.

Deciding signal

Cloud SQL is a fully managed MySQL, PostgreSQL, or SQL Server database in a single region — standard relational with up to 96 vCPUs and 624 GB RAM. Best for existing relational workloads with regional scope. Cloud Spanner is a globally distributed, horizontally scalable relational database with strong consistency across regions and ACID transactions — the right answer when the scenario requires relational semantics at global scale that Cloud SQL cannot provide. Firestore is a serverless document database with real-time sync and offline support — best for mobile and web applications with document-based data models. Cloud Bigtable is a NoSQL wide-column store optimized for time-series, IoT, and analytical workloads requiring high write throughput and low latency at petabyte scale.

Deciding signal

Cloud Load Balancing distributes traffic across backend instances — it is the foundational layer for availability and scaling. Cloud CDN caches content at Google edge POPs — it reduces latency and origin load for cacheable static content (images, JavaScript, video). Cloud Armor is a WAF and DDoS protection service that integrates with Cloud Load Balancing — it applies security policies (IP allow/deny, rate limiting, OWASP rule groups, adaptive DDoS protection) to HTTP/HTTPS load-balanced traffic. Armor does not distribute traffic; CDN does not protect against attacks. The architecture is typically: Cloud Load Balancing → Cloud Armor → Cloud CDN → backend. When a scenario involves blocking web attacks or DDoS, Cloud Armor. Caching static content, Cloud CDN. Distributing requests to backends, Cloud Load Balancing.

Deciding signal

For PCA scenarios, the key signal is operational ownership. GKE is the answer when the scenario requires Kubernetes API compatibility, custom operators, specific cluster configuration, or stateful workloads needing persistent volumes and node-level control — situations where the team accepts Kubernetes operational overhead because the workload demands it. Cloud Run is the answer when the scenario describes containerized services where the team wants no cluster management — auto-scaling, scale-to-zero, and fully managed infrastructure. Cloud Functions is for short, stateless, event-triggered tasks. App Engine standard is for managed web app runtimes without containers. PCA tests whether you can recognize which ownership model the scenario implies, not just which service runs containers.

Deciding signal

VPC Peering connects two VPCs privately — traffic routes between them via Google internal network, non-transitive (A-B and B-C does not enable A-C). Shared VPC designates a host project whose VPC is shared with service projects — the service projects use the host VPC subnets, enabling centralized network management and billing. Cloud Interconnect provides a dedicated private circuit from your data center to Google — Dedicated Interconnect for direct colocated connectivity, Partner Interconnect through a provider. Cloud VPN creates an encrypted IPsec tunnel from on-premises to Google over the public internet. When the scenario involves sharing one VPC across multiple GCP projects with centralized management, Shared VPC. On-premises dedicated private connectivity, Cloud Interconnect. On-premises encrypted internet tunnel, Cloud VPN.

Deciding signal

Cloud KMS is a managed key management service — it creates, rotates, and applies encryption keys for encrypting data stored in GCS, BigQuery, and other services. Keys are stored in Google-managed infrastructure. Cloud HSM is a hardware security module backend for Cloud KMS — it provides FIPS 140-2 Level 3 validated hardware for key operations when regulations require hardware-backed key custody. It is not a separate service you deploy; it is a key protection level within Cloud KMS. Secret Manager stores and versions application secrets — API keys, passwords, tokens — with access control, audit logging, and automatic replication. When the scenario involves managing encryption keys for GCP services, Cloud KMS. Hardware compliance for key operations, Cloud HSM (as a KMS protection level). Storing and accessing application secrets, Secret Manager.

Deciding signal

Cloud IAM grants permissions to identities — users, service accounts, groups — at the resource level. It controls what authenticated principals can do: "this service account can create BigQuery tables in this project." Organization Policies define constraints on resource configurations regardless of what users are permitted to do — they can restrict which regions resources can be created in, prevent public IP addresses on Compute instances, disable service account key creation, or require uniform bucket-level access on Cloud Storage. A principal with IAM permission to create a Cloud Storage bucket can still be blocked from creating a bucket without uniform access if an Organization Policy enforces it. IAM controls identities; Org Policy controls resource behavior.