Use this skill when architecting on Google Cloud Platform, selecting GCP services, or implementing data and compute solutions. Triggers on Cloud Run, BigQuery, Pub/Sub, GKE, Cloud Functions, Cloud Storage, Firestore, Spanner, Cloud SQL, IAM, VPC, and any task requiring GCP architecture decisions or service selection.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Une commande directe contourne le prompt de vérification. Examinez la source avant de l'exécuter.
Use this skill when architecting on Google Cloud Platform, selecting GCP services, or implementing data and compute solutions. Triggers on Cloud Run, BigQuery, Pub/Sub, GKE, Cloud Functions, Cloud Storage, Firestore, Spanner, Cloud SQL, IAM, VPC, and any task requiring GCP architecture decisions or service selection.
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
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
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.
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.
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.
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.
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.
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 expirationCREATE SCHEMA my_project.analytics
OPTIONS (
location ='us-central1',
default_table_expiration_days =365
);
-- Partition tables by date to control scan costsCREATE TABLE analytics.events (
event_id STRING,
user_id STRING,
event_ts TIMESTAMP,
payload JSON
)
PARTITIONBYDATE(event_ts)
CLUSTER BY user_id;
-- Use partition filters to avoid full-table scansSELECT user_id, COUNT(*) as cnt
FROM analytics.events
WHEREDATE(event_ts) BETWEEN'2024-01-01'AND'2024-03-31'GROUPBY 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 cost (~$0.65/hr per node); not worth it under 1 TB
Configure IAM with least privilege
# Create a service account for a Cloud Run service
gcloud iam service-accounts create my-service-sa \
--display-name "my-service runtime SA"# Grant only the permissions it needs
gcloud projects add-iam-policy-binding PROJECT \
--member "serviceAccount:my-service-sa@PROJECT.iam.gserviceaccount.com" \
--role "roles/bigquery.dataViewer"
gcloud projects add-iam-policy-binding PROJECT \
--member "serviceAccount:my-service-sa@PROJECT.iam.gserviceaccount.com" \
--role "roles/pubsub.publisher"# For GKE: bind Kubernetes SA to GCP SA via Workload Identity
gcloud iam service-accounts add-iam-policy-binding my-service-sa@PROJECT.iam.gserviceaccount.com \
--role "roles/iam.workloadIdentityUser" \
--member "serviceAccount:PROJECT.svc.id.goog[NAMESPACE/KSA_NAME]"
Never create and download service account key JSON files for workloads running on
GCP. Use Workload Identity for GKE, and the automatic metadata server for Cloud Run.
Key files leak, expire, and are a primary source of GCP credential breaches.
Set up Cloud CDN and Load Balancer
For a Cloud Run service that needs CDN caching:
# Create a serverless NEG pointing at Cloud Run
gcloud compute network-endpoint-groups create my-service-neg \
--region us-central1 \
--network-endpoint-type serverless \
--cloud-run-service my-service
# Create backend service and enable CDN
gcloud compute backend-services create my-service-backend \
--global \
--enable-cdn \
--cache-mode CACHE_ALL_STATIC \
--custom-response-header "Cache-Control:public, max-age=3600"
gcloud compute backend-services add-backend my-service-backend \
--global \
--network-endpoint-group my-service-neg \
--network-endpoint-group-region us-central1
# Create URL map, target proxy, and forwarding rule# (typically done via Terraform for production)
Use Cloud Armor on the backend service to add WAF rules and rate limiting at the
edge. Attach Cloud CDN only to responses that are safe to cache - set
Cache-Control: private on auth-gated endpoints.
Implement event-driven architecture with Pub/Sub and Cloud Functions
# Create a topic
gcloud pubsub topics create order-created
# Create a dead-letter topic for failed messages
gcloud pubsub topics create order-created-dlq
# Create a push subscription that triggers Cloud Functions (gen2)
gcloud pubsub subscriptions create order-created-sub \
--topic order-created \
--ack-deadline 60 \
--dead-letter-topic order-created-dlq \
--max-delivery-attempts 5
# Deploy a Cloud Function triggered by the topic
gcloud functions deploy process-order \
--gen2 \
--runtime nodejs20 \
--trigger-topic order-created \
--region us-central1 \
--service-account processor-sa@PROJECT.iam.gserviceaccount.com \
--set-env-vars "PROJECT_ID=PROJECT"
Pattern notes:
Always configure a dead-letter topic - without one, a poison-pill message retries
indefinitely and blocks the subscription.
Set --ack-deadline to at least 2x your function's expected execution time.
Use --max-delivery-attempts 5 with exponential backoff before DLQ.
For high-throughput scenarios (>10k msg/s), use Dataflow instead of Functions.
Anti-patterns / common mistakes
Mistake
Why it's wrong
What to do instead
Downloading service account key files
Credentials that leak, don't auto-rotate, and are hard to audit
Use Workload Identity (GKE) or the metadata server (Cloud Run)
SELECT * on large BigQuery tables
Scans entire table regardless of filters, costs multiply
Select only needed columns; partition + cluster the table
No dead-letter topic on Pub/Sub subscriptions
Poison-pill messages block the subscription indefinitely
Always configure a DLQ with --max-delivery-attempts
Spanner for a single-region OLTP app
5-10x the cost of Cloud SQL with no benefit
Use Cloud SQL (Postgres) unless global writes are required
Granting roles/editor to a service account
Overly broad; can read/write all project resources
Grant narrowest predefined role needed; use custom roles if required
Cloud Run without max-instances
Unexpected traffic spike can exhaust downstream DB connections
Always set --max-instances and size connection pools accordingly
Gotchas
Cloud Run without max-instances is a database killer - Cloud Run scales to hundreds of instances on traffic spikes. Each instance holds its own connection pool. Without --max-instances, a traffic spike can open thousands of database connections and exhaust Cloud SQL or Spanner limits. Always set --max-instances and size --concurrency to match your downstream connection budget.
BigQuery charges for scanned bytes, not returned rows - A SELECT * on a 10 TB table bills for 10 TB even if you filter to one row. Always select only the columns needed and add partition filter clauses. Without a WHERE DATE(event_ts) BETWEEN ... condition on a partitioned table, the query scans all partitions.
Pub/Sub without a dead-letter topic blocks the subscription - A single malformed message that causes the consumer to throw an exception will be retried indefinitely (up to --max-delivery-attempts, but that defaults to unlimited without a DLQ configured). Always set --dead-letter-topic and --max-delivery-attempts together - one without the other provides incomplete protection.
Service account key files are a persistent credential leak vector - Downloaded JSON key files don't expire, are easy to commit to git, and can't be audited as precisely as Workload Identity. GCP's metadata server and Workload Identity provide automatic, rotating credentials for every compute surface. Never create key files for workloads that run on GCP infrastructure.
Firestore billing on aggregation queries - Firestore bills per document read. A query that counts documents in a collection reads every document to compute the count. At scale, this means SELECT COUNT(*) equivalents are extremely expensive. Maintain aggregation counters as separate documents and update them via Cloud Functions triggered on writes.
References
For detailed patterns and reference tables on specific GCP topics, read the relevant
file from the references/ folder:
references/service-map.md - quick lookup of use case to GCP service
Only load a references file if the current task requires it - they add context length.
Companion check
On first activation of this skill in a conversation: check which companion skills are installed by running ls ~/.claude/skills/ ~/.agent/skills/ ~/.agents/skills/ .claude/skills/ .agent/skills/ .agents/skills/ 2>/dev/null. Compare the results against the recommended_skills field in this file's frontmatter. For any that are missing, mention them once and offer to install:
