google-cicd-terraform

---
name: google-cicd-terraform
description: Architect, provision, and troubleshoot infrastructure on Google Cloud using Terraform. This skill ensures best practices like GCS backend usage and least-privilege IAM are followed. Enforces Google’s Cloud Foundation Fabric patterns and rigorous validation protocols to ensure secure, idempotent, and scalable deployments across environments. Activate when the user requests infrastructure changes, pipeline design involving Terraform, or debugging Terraform issues.
license: Apache-2.0
---

# Terraform GCP Skill

This skill provides expert-level guidance for architecting, deploying, and managing GCP infrastructure using Terraform.

## 🎯 When to Use This Skill
- Designing GCP Landing Zones (Projects, Folders, Shared VPCs).
- Provisioning Google Cloud resources (GKE, Cloud Run, Cloud SQL, Spanner).
- Setting up remote state management via **GCS Backend**.
- Implementing IAM least-privilege via Terraform.
- Troubleshooting `terraform plan` discrepancies in GCP.

## 🏗️ Core Architecture: GCS Backend & State
**Always** use a GCS backend for state. Local state is strictly for local prototyping and must never be committed. If local state direcotry is used, add it to .gitignore.

### Standard Backend Configuration
```hcl
terraform {
  backend "gcs" {
    bucket  = "tf-state-${var.project_id}"
    prefix  = "terraform/state/${var.environment}"
  }
}
```

Note: The GCS bucket must have Object Versioning enabled to allow recovery from accidental state corruption or overlapping writes.

### Required Provider Version
Use the Google Cloud Terraform provider version 7.20.0 or higher. This skill utilizes features (e.g., Developer Connect) introduced in Google Provider v7.20.0.

```hcl
terraform {
  required_version = ">= 1.6.0"

  required_providers {
    google = {
      source  = "hashicorp/google"
      version = ">= 7.20.0" 
    }
  }
}
```

To retrieve the latest version of the Google provider, use the following command:
```bash
curl -s https://registry.terraform.io/v1/providers/hashicorp/google | jq -r .version
```

## 🛠️ Execution Protocol (Safety First)
The Agent must follow this lifecycle for every infrastructure change to ensure idempotency and prevent production outages:

1. Initialize (`terraform init`):

   - Verify backend connectivity.

   - Ensure provider plugins are downloaded and versions are locked in `.terraform.lock.hcl`.

2. Validate (`terraform validate` & `tflint`):

   - Check for internal HCL consistency.

   - Run `tflint` with the Google plugin to catch cloud-specific deprecated fields or non-optimal configurations.

3. Plan (`terraform plan -out=tfplan`):

   - Generate a speculative execution plan.

   - Mandatory Step: The Agent must summarize the plan for the user, specifically highlighting any Destroy actions.

4. Apply (`terraform apply tfplan`):

   - Strict Constraint: Only execute the application after the user provides explicit manual confirmation.

## 🔍 Live Provider Documentation Lookup
To prevent hallucinations regarding new fields or deprecated attributes, the Agent must verify the grounded truth of the provider schema.

Schema Inspection via CLI
The primary command for retrieving the machine-readable schema of the currently initialized providers is:

```bash
$ terraform providers schema -json
```


## 🛡️ GCP-Specific Standards
1. Resource Naming & "Main" Pattern
To maintain a clean module interface, use the main identifier for singleton resources (the primary resource the module is named after). Use underscores for identifiers and hyphens for names.

    ```hcl
    resource "google_compute_network" "main" {
      name                    = "${var.prefix}-vpc"
      auto_create_subnetworks = false
    }
    ```

2. IAM Management
   - Never use google_project_iam_policy: This resource is authoritative and replaces the entire IAM policy for the project. It is the #1 cause of accidental lockouts.
   - Avoid `google_project_iam_policy`: This resource is authoritative for the entire project and is a common cause of accidental lockouts.

   - Prefer `google_project_iam_member` or `google_project_iam_binding`:
     - `google_project_iam_member` is additive and safely grants a role to a single member.
     - `google_project_iam_binding` is authoritative for a single role. It's useful for managing all members of a role, but be aware it overwrites existing members for that role.
   - Shared VPC: Always distinguish between Host projects (where the network lives) and Service projects (where resources consume the network).
   - Private Google Access: Subnets should always have private_ip_google_access = true.
   - Workload Identity: Prefer GKE Workload Identity over static Service Account JSON keys.

3. Cloud Build Triggers with Developer Connect
   When using Developer Connect git repository links, use `developer_connect_event_config` — NOT `repository_event_config`. The `repository_event_config` block is for Cloud Build v2 repository connections and will not work with Developer Connect resources. An example block to create a Cloud Build trigger with Developer Connect git repository link is as follows:

    ```hcl
    resource "google_cloudbuild_trigger" "main" {
      developer_connect_event_config {
        git_repository_link = google_developer_connect_git_repository_link.main.id
        push {
          branch = var.trigger_branch
        }
      }
    }
    ```

4. Developer Connect Connection
   When configuring `google_developer_connect_connection`, always set `github_app` to `"DEVELOPER_CONNECT"`. Using `"FIREBASE"` is incorrect and will cause triggers to fail.

    ```hcl
    resource "google_developer_connect_connection" "main" {
      location      = var.region
      connection_id = var.connection_id
      project       = var.project_id

      github_config {
        github_app = "DEVELOPER_CONNECT" # CORRECT
        authorizer_credential {
          oauth_token_secret_version = "" # Populated after manual authorization
        }
      }

      depends_on = [google_project_service.main["developerconnect.googleapis.com"]]

      lifecycle {
        ignore_changes = [github_config[0].authorizer_credential]
      }
    }
    ```

5. Developer Connect Git Repository Link
   When configuring `google_developer_connect_git_repository_link`, use `parent_connection` and `git_repository_link_id` as required arguments.

    ```hcl
    resource "google_developer_connect_git_repository_link" "main" {
      location                = var.region
      parent_connection       = google_developer_connect_connection.main.connection_id
      git_repository_link_id  = "my-repo-link"
      clone_uri               = var.github_repo_uri
    }
    ```

## 📂 Directory Structure
Follow this standard to ensure compatibility with Antigravity (AGY) discovery and Google best practices:

```
.
└── terraform/
    ├── main.tf              # Entry point / Resource definitions
    ├── variables.tf         # Typed variables with units and descriptions
    ├── outputs.tf           # Resource ID outputs (no direct input pass-through)
    ├── versions.tf          # Provider version pinning
    ├── network.tf           # (Optional) Grouped networking resources
    ├── examples/            # Example usage for modules
    ├── files/               # Static files (startup scripts, etc.)
    ├── templates/           # .tftpl templates
    ├── scripts/             # Scripts called by Terraform
    └── helpers/             # Scripts NOT called by Terraform
```
## ⚠️ Anti-Patterns (Do NOT do these)
   - ❌ Legacy GitHub Triggers: Do not use the legacy `github` block in `google_cloudbuild_trigger`. Always use `developer_connect_event_config`.

   - ❌ Hardcoded IDs: Never hardcode Project IDs. Use variables or data "google_project" sources.

   - ❌ Service Account Keys: Never generate or store .json keys. Use Workload Identity Federation or the default metadata server.

   - ❌ Hardcoded IDs: Never hardcode Project IDs. Use variables or a `data "google_project"` source.

   - ❌ Broad Scopes: Avoid cloud-platform scopes for GKE nodes; use fine-grained IAM roles instead.

   - ❌ Uppercase Types: Terraform variable types must be lowercase (e.g., `type = string` not `type = STRING`).

## 🧪 Testing Strategy
   - Static Analysis: Use checkov, trivy, or terrascan to catch insecure GCP configurations (e.g., public GCS buckets).

   - Integration Testing: Use terraform test (v1.6+) to assert that GCP labels and network tags are correctly applied to resources before full deployment.