cloud-gcp

When this skill is activated, always start your first response with the 🧢 emoji.

Google Cloud Platform

GCP is Google's suite of cloud infrastructure and managed services. This skill covers architecture decisions, service selection, and implementation patterns for the most commonly used GCP building blocks: compute (Cloud Run, GKE, Cloud Functions), data (BigQuery, Cloud Storage, Pub/Sub), and databases (Cloud SQL, Firestore, Spanner, Bigtable). The emphasis is on choosing the right service for the problem and configuring it correctly rather than memorizing every API surface.

When to use this skill

Trigger this skill when the user:

• Deploys a containerized service or API to GCP
• Designs a data pipeline (ingestion, transformation, analytics)
• Needs to choose between GCP database offerings (Cloud SQL, Firestore, Spanner, Bigtable)
• Sets up IAM roles, service accounts, or Workload Identity
• Architects an event-driven system with Pub/Sub and Cloud Functions
• Configures networking (VPC, Load Balancer, Cloud CDN, Cloud Armor)
• Estimates or controls GCP costs (BigQuery slot reservations, Cloud Run concurrency)

Do NOT trigger this skill for:

• AWS or Azure architecture (use the corresponding cloud skill)
• Application-level code that happens to run on GCP but has no GCP-specific concerns

Key principles

1. Managed services first - Prefer fully managed services (Cloud Run, BigQuery,

Firestore) over self-managed ones (GCE with custom installs). The operational overhead of managing VMs, patches, and scaling is rarely worth the flexibility.

1. BigQuery is the analytics layer - BigQuery is GCP's default for any analytical

workload at any scale. It is serverless, cost-effective for infrequent queries, and integrates with Dataflow, Pub/Sub, and Looker. Use it unless you need sub-second OLTP latency.

1. Cloud Run is the default compute - For HTTP-serving workloads, Cloud Run

(not GKE, not App Engine) is the right default. It is stateless, auto-scales to zero, and charges per request-second. Move to GKE only when you need persistent connections, GPUs, or complex networking.

1. Pub/Sub for decoupling - Whenever two services need to communicate

asynchronously, route through Pub/Sub. It provides durable delivery, at-least-once semantics, replay, and dead-letter queues without you managing a broker.

1. IAM at project level, fine-grained at resource level - Grant roles at the

lowest resource scope possible. Use service accounts with Workload Identity for workloads running on GCP - never create and download service account key files.

Core concepts

Resource hierarchy

Organization
  └── Folders (teams, environments)
        └── Projects  <-- primary billing and IAM boundary
              └── Resources (Cloud Run services, BigQuery datasets, buckets, etc.)

IAM policies are inherited downward. A role granted at the organization level applies to all projects. Grant permissions at the project or resource level to limit blast radius.

IAM model

Every GCP principal (user, service account, group) is granted roles, which are bundles of permissions. There are three role types:

| Type | Example | When to use | |---|---|---| | Basic | roles/viewer, roles/editor | Never in production - too broad | | Predefined | roles/run.invoker, roles/bigquery.dataViewer | Default choice | | Custom | Built from individual permissions | When predefined is still too broad |

Service accounts are identities for workloads. Use Workload Identity to bind a Kubernetes service account to a GCP service account - no key files needed.

Compute spectrum

| Service | Trigger | State | Scale to zero | Use case | |---|---|---|---|---| | Cloud Functions (gen2) | Event / HTTP | Stateless | Yes | Lightweight event handlers | | Cloud Run | HTTP / gRPC | Stateless | Yes | Containerized APIs, backends | | GKE Autopilot | Always-on | Stateful OK | No | Long-running, GPU, complex networking | | Compute Engine | Always-on | Stateful | No | VMs, custom OS, legacy lift-and-shift |

Storage and database tiers

| Service | Model | Sweet spot | |---|---|---| | Cloud Storage | Object / blob | Files, backups, data lake raw zone | | BigQuery | Columnar OLAP | Analytics, reporting, ad-hoc queries | | Cloud SQL | Relational (Postgres/MySQL) | OLTP, existing SQL apps | | Firestore | Document (NoSQL) | Mobile/web, hierarchical, real-time sync | | Spanner | Globally distributed relational | Finance, inventory, global consistency | | Bigtable | Wide-column NoSQL | Time-series, IoT, >1 TB key-value | | Memorystore | Redis / Memcached | Caching, session storage, leaderboards |

Common tasks

Deploy a containerized service to Cloud Run

# Build and push image to Artifact Registry
gcloud builds submit --tag us-central1-docker.pkg.dev/PROJECT/REPO/my-service:latest

# Deploy with recommended production settings
gcloud run deploy my-service \
  --image us-central1-docker.pkg.dev/PROJECT/REPO/my-service:latest \
  --region us-central1 \
  --platform managed \
  --service-account my-service-sa@PROJECT.iam.gserviceaccount.com \
  --set-env-vars "ENV=production" \
  --memory 512Mi \
  --cpu 1 \
  --concurrency 80 \
  --max-instances 10 \
  --no-allow-unauthenticated   # use --allow-unauthenticated for public APIs

Key dials:

• --concurrency - requests handled per container instance (default 80). Lower it

for CPU-bound work; increase for I/O-bound.

• --max-instances - hard cap to control costs and protect downstream services.
• --no-allow-unauthenticated + roles/run.invoker on the calling service account

is the correct pattern for service-to-service calls.

Design a data pipeline

Standard GCP data pipeline pattern:

Source (app events, CDC, files)
  --> Pub/Sub topic (ingestion buffer, durability)
  --> Dataflow job (transform, enrich, validate)
  --> BigQuery dataset (analytics layer)
  --> Looker / Looker Studio (visualization)

For simpler pipelines without transformation logic, use BigQuery subscriptions directly from Pub/Sub (no Dataflow needed). For batch ingestion from Cloud Storage, use BigQuery Data Transfer Service or a scheduled Dataflow pipeline.

Set up BigQuery for analytics

-- Create a dataset with a region and expiration
CREATE SCHEMA my_project.analytics
  OPTIONS (
    location = 'us-central1',
    default_table_expiration_days = 365
  );

-- Partition tables by date to control scan costs
CREATE TABLE analytics.events (
  event_id STRING,
  user_id  STRING,
  event_ts TIMESTAMP,
  payload  JSON
)
PARTITION BY DATE(event_ts)
CLUSTER BY user_id;

-- Use partition filters to avoid full-table scans
SELECT user_id, COUNT(*) as cnt
FROM analytics.events
WHERE DATE(event_ts) BETWEEN '2024-01-01' AND '2024-03-31'
GROUP BY user_id;

Cost control checklist:

• Always partition large tables by date/timestamp
• Cluster on high-cardinality filter columns (user_id, org_id)
• Use SELECT specific_columns not SELECT *
• Set column-level access policies on PII fields
• Monitor with INFORMATION_SCHEMA.JOBS to catch expensive queries

Choose the right database

Use this decision matrix:

Do you need SQL?
  YES -> Is global multi-region consistency required?
    YES -> Spanner
    NO  -> Cloud SQL (Postgres preferred)
  NO  -> Is data hierarchical / document-shaped?
    YES -> Is real-time sync or offline support needed?
      YES -> Firestore
      NO  -> Firestore (still fine) or BigQuery for analytics
    NO  -> Is it time-series / IoT at >1 TB scale?
      YES -> Bigtable
      NO  -> Cloud Storage (data lake) or BigQuery

Key differentiators:

• Cloud SQL caps at ~10 TB and one primary region - fine for most apps
• Spanner is 5-10x the cost of Cloud SQL; justify with global write requirements
• Firestore bills per operation, not compute - avoid heavy aggregation queries
• Bigtable has a minimum c