GCP Cloud Engineering Patterns

GCP Enterprise Cloud Engineering & Organization Governance

When to Use This Skill

Triggers — load this skill when:

• A GCP organization needs hierarchy, policy constraints, or Shared VPC design
• External CI or workloads need keyless access via Workload Identity Federation
• Data-perimeter controls (VPC Service Controls) must be planned

Route elsewhere when:

• GKE cluster and tenancy design -> gcp-gke-autopilot-multi-tenant
• Cross-cloud posture benchmarks -> cloud-security-posture-cspm-cis

1. GCP Organization Resource Hierarchy (Terraform)

resource "google_folder" "department_folder" {
  display_name = "Core-Engineering"
  parent       = "organizations/123456789012"
}

resource "google_project" "production_project" {
  name       = "prod-workloads"
  project_id = "corp-prod-workloads-4092"
  folder_id  = google_folder.department_folder.name
  billing_account = "01ABCD-23EFGH-45IJKL"
}

# Enforce Organization Policy (e.g. restrict public IP on Compute Engine)
resource "google_organization_policy" "restrict_public_ip" {
  org_id     = "123456789012"
  constraint = "compute.vmExternalIpAccess"

  list_policy {
    deny {
      all = true
    }
  }
}

2. Best Practices & Anti-Patterns

• Do: Use Shared VPC to centralize network administration and firewall rules in a dedicated host project.
• Do: Bind Kubernetes Service Accounts to GCP Service Accounts using Workload Identity Federation instead of exporting JSON private keys.
• Don't: Avoid using the default Service Account ({project_number}-compute@developer.gserviceaccount.com) for production workloads.

3. Keyless CI with Workload Identity Federation & BigQuery Operations

GitHub Actions to GCP with no service account key. Exported SA keys are the most common GCP credential leak; federation removes them entirely:

gcloud iam workload-identity-pools create github --location=global
gcloud iam workload-identity-pools providers create-oidc github-actions \
  --workload-identity-pool=github --location=global \
  --issuer-uri="https://token.actions.githubusercontent.com" \
  --attribute-mapping="google.subject=assertion.sub,attribute.repository=assertion.repository" \
  --attribute-condition="assertion.repository_owner=='acme'"

gcloud iam service-accounts add-iam-policy-binding deployer@PROJECT.iam.gserviceaccount.com \
  --role=roles/iam.workloadIdentityUser \
  --member="principalSet://iam.googleapis.com/projects/NUM/locations/global/workloadIdentityPools/github/attribute.repository/acme/payments"

permissions: { id-token: write, contents: read }
steps:
  - uses: google-github-actions/auth@v3
    with:
      workload_identity_provider: projects/NUM/locations/global/workloadIdentityPools/github/providers/github-actions
      service_account: deployer@PROJECT.iam.gserviceaccount.com

Always set --attribute-condition on the provider: without it, any GitHub repository in the world can mint tokens for the pool.

BigQuery platform operations. Cost and governance are the same problem here:

-- Partitioned + clustered: scanned bytes, not stored bytes, drive the bill
CREATE TABLE analytics.events (
  event_ts TIMESTAMP, user_id STRING, event_type STRING, payload JSON
)
PARTITION BY DATE(event_ts)
CLUSTER BY event_type, user_id
OPTIONS (partition_expiration_days = 400, require_partition_filter = TRUE);

• require_partition_filter = TRUE makes an unbounded full-table scan impossible by accident.
• Set custom quotas per project and reservation-based (slot) pricing once on-demand spend is predictable; alert on INFORMATION_SCHEMA.JOBS_BY_PROJECT for queries above a byte threshold.
• Authorized views and column-level policy tags, inside a VPC Service Controls perimeter, are what keep analyst access from becoming an exfiltration path.