Terraform Validate

Terraform Validate

Validates Terraform modules and configurations across CPP 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

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 CPP 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

CPP-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

Source: hmcts/cpp-context-staging-bulkscan — distributed by TomeVault.