terraform-validate

---
name: terraform-validate
description: Validate Terraform modules and configurations across CP infrastructure repos. Use when checking Terraform code, reviewing infrastructure changes, or verifying module consistency.
---

# Terraform Validate

Validates Terraform modules and configurations across CP infrastructure repositories for consistency, security, and best practices.

## When to Use

- User asks to "validate terraform", "check this module", "review infrastructure changes"
- User is modifying a `cpp-terraform-*` or `cpp-module-terraform-*` repo
- User wants to verify state backend configuration
- User wants to check variable naming conventions across modules

## Process

### Step 1: Identify Module Type

| Prefix | Type | Purpose |
|--------|------|---------|
| `cpp-module-terraform-azurerm-*` | Reusable module | Shared building blocks consumed by other Terraform repos |
| `cpp-terraform-azurerm-*` | Root module | Environment-specific infrastructure provisioning |
| `cpp-terraform-network` | Network | VNet, subnet, NSG, peering configuration |
| `cpp-automation-terraform` | Automation | Terraform automation and orchestration |

### Step 2: Validate Structure

Every Terraform repo should have:

```
├── main.tf                    # Primary resource definitions
├── variables.tf               # Input variable declarations
├── outputs.tf                 # Output value declarations
├── versions.tf                # Provider and Terraform version constraints
├── README.md                  # Auto-generated by terraform-docs
├── .pre-commit-config.yaml    # Pre-commit hooks
├── .terraform-version         # tfversion pinning
└── vars/                      # Environment-specific tfvars (root modules only)
    ├── dev.tfvars
    ├── sit.tfvars
    ├── ste.tfvars
    ├── nft.tfvars
    ├── prp.tfvars
    └── prd.tfvars
```

### Step 3: Validation Checks

#### Variable Declarations
- [ ] All variables have `description` field
- [ ] All variables have `type` constraint
- [ ] Sensitive variables marked with `sensitive = true`
- [ ] Default values only for optional variables
- [ ] Variable names use snake_case

#### Resource Configuration
- [ ] All resources have consistent tagging (environment, team, service)
- [ ] Resource names follow CP naming convention: `{resource-type}-{env}-{purpose}`
- [ ] No hardcoded values that should be variables
- [ ] Lifecycle rules specified where appropriate (prevent_destroy for stateful resources)

#### State Backend
- [ ] Backend configuration uses Azure Storage Account
- [ ] Non-live state: `samdvshared01` in `RG-MDV-SHARED-01`
- [ ] Live state: `sampdshared01` in `RG-MPD-SHARED-01`
- [ ] State container names are unique per workspace

#### Security
- [ ] No secrets in `.tf` files or `.tfvars` (use Key Vault references)
- [ ] NSG rules follow least-privilege principle
- [ ] Private endpoints used for Azure PaaS services
- [ ] Managed identities preferred over service principals
- [ ] No `*` in RBAC role assignments

#### Pre-commit Hooks
- [ ] `.pre-commit-config.yaml` present
- [ ] Hooks include: terraform-fmt, terraform-validate, terraform-docs, tflint
- [ ] Hook versions are current

### Step 4: Environment Consistency

For root modules with per-environment tfvars:

1. Read all `vars/*.tfvars` files
2. Verify each environment defines the same set of variables
3. Flag any environment-specific variables missing from other environments
4. Check that production values are appropriately different from non-prod (e.g., larger SKUs, more replicas)

### Step 5: Module Dependency Check

For root modules that consume reusable modules:

1. Check `module` blocks for source references
2. Verify module versions are pinned (not `ref=main`)
3. Check if newer versions of consumed modules are available
4. Verify required input variables are provided

### Step 6: Generate Report

```
## Terraform Validation Report: [module-name]

### Structure
- [✅/❌] Standard file layout
- [✅/❌] Pre-commit hooks configured
- [✅/❌] README auto-generated

### Variables
| Name | Type | Description | Sensitive | Default | Status |
|------|------|-------------|-----------|---------|--------|

### Security
- [✅/❌] No hardcoded secrets
- [✅/❌] Private endpoints used
- [✅/❌] Managed identities preferred

### Environment Consistency
| Variable | dev | sit | ste | nft | prp | prd |
|----------|-----|-----|-----|-----|-----|-----|

### Issues
- [severity] [description] — suggested fix
```

## CP-Specific Infrastructure Patterns

### AKS Clusters
- System + Worker + Prometheus node pools
- Azure CNI networking with Calico network policy
- OIDC issuer enabled for workload identity
- Cluster naming: `{env}-cs{stack}cl{cluster}`

### PostgreSQL
- Flexible Server (not single server)
- Per-context databases (hearing_db, resulting_db, etc.)
- Admin credentials from Key Vault
- Read-only user for reporting (`pgreadonly`)

### Service Bus
- Per-environment namespace
- Topics per bounded context
- Dead-letter queues configured
- Max delivery count and TTL set per subscription

### Key Vault
- Per-environment vaults
- CSI driver for pod secret injection
- Secret rotation enabled

More agent context in hmcts/claude

15 other files this repository gives its agents.