Infrastructure Automation with Terraform

Infrastructure automation replaces clickops with code — every server, database, network, and permission is defined in version-controlled configuration files. Terraform is the dominant tool for this pattern, but the principles apply regardless of tool: declarative definitions, state management, modular composition, and automated validation.

---

Why Terraform

Factor	Terraform	CloudFormation	Pulumi	Bicep
Multi-cloud	✅ Yes	❌ AWS only	✅ Yes	❌ Azure only
Language	HCL	YAML/JSON	TypeScript/Python/Go	DSL
State management	External (S3, TFC)	Managed by AWS	External or managed	Managed by Azure
Community	Largest	Large (AWS)	Growing	Growing (Azure)
Learning curve	Moderate	Low (AWS users)	Low (developers)	Low (Azure users)
Drift detection	terraform plan	Drift detection	pulumi preview	What-if

---

Module Architecture

infrastructure/
├── modules/                    # Reusable modules
│   ├── vpc/
│   │   ├── main.tf
│   │   ├── variables.tf
│   │   └── outputs.tf
│   ├── eks-cluster/
│   ├── rds-database/
│   └── monitoring/
├── environments/               # Environment-specific configs
│   ├── dev/
│   │   ├── main.tf            # Composes modules
│   │   ├── terraform.tfvars   # Dev-specific values
│   │   └── backend.tf         # State backend config
│   ├── staging/
│   └── production/
├── global/                     # Shared resources (DNS, IAM)
│   ├── iam/
│   └── dns/
└── scripts/
    ├── plan.sh
    └── apply.sh

---

State Management

Backend	Best For	Trade-offs
S3 + DynamoDB	AWS-native teams	Reliable, low cost, requires setup
Terraform Cloud	Teams wanting managed state	Easy, collaboration features, cost
Azure Blob	Azure-native teams	Native integration
GCS	GCP-native teams	Native integration
GitLab Managed	GitLab CI users	Integrated, simple setup

State Locking

Without locking:
    Engineer A runs terraform apply
    Engineer B runs terraform apply simultaneously
    → State corruption, resources in unknown state

With locking (DynamoDB/TFC):
    Engineer A runs terraform apply → acquires lock
    Engineer B runs terraform apply → "State locked, try again later"
    Engineer A finishes → releases lock
    Engineer B retries → acquires lock → safe to apply

---

CI/CD Integration

Pull Request:
    → terraform fmt -check (formatting)
    → terraform validate (syntax)
    → terraform plan (preview changes)
    → Plan output posted as PR comment
    → Security scan (tfsec, checkov)

Merge to main:
    → terraform plan (confirm changes)
    → Manual approval gate
    → terraform apply (deploy)
    → Notify team of changes

---

Common Patterns

Pattern	When to Use	Description
Module composition	Always	Build infrastructure from reusable modules
Remote state data sources	Cross-project references	Read outputs from other state files
Workspaces	Same config, different environments	Dev/staging/prod from same code
Import	Existing resources	Bring clickops resources under Terraform
State migration	Restructuring	Move resources between state files
Targeted apply	Emergency changes	Apply specific resources only

---

Security Scanning

Tool	What It Checks	Integration
tfsec	Terraform security misconfigs	CLI, CI, pre-commit
Checkov	Multi-framework security	CLI, CI
Terrascan	Policy violations	CLI, CI
OPA/Conftest	Custom policies	CI
Sentinel	Policy-as-code (TFC Enterprise)	Terraform Cloud

---

Anti-Patterns

Anti-Pattern	Problem	Fix
Local state file	Lost state = orphaned resources	Remote backend with locking
Monolithic config	Single plan takes 30+ minutes	Split by domain/service with modules
Hardcoded values	Can’t reuse across environments	Variables and tfvars per environment
terraform apply without plan	Unexpected changes deployed	Always plan first, review, then apply
Manual changes alongside Terraform	State drift, conflicts	All changes through Terraform; import existing resources
No state locking	Concurrent applies corrupt state	Enable DynamoDB/TFC locking

---

Checklist

• Remote backend configured with state locking
• Module structure: reusable modules + environment-specific composition
• CI/CD pipeline: format → validate → plan → approve → apply
• Security scanning integrated (tfsec or Checkov)
• State backup and versioning enabled on backend
• Variables used for all environment-specific values
• Drift detection scheduled (weekly terraform plan comparison)
• Resource tagging standard enforced (owner, environment, cost center)
• Import plan for any existing clickops resources
• Documentation: module README with inputs, outputs, and usage examples

---

:::note[Source] This guide is derived from operational intelligence at Garnet Grid Consulting. For infrastructure automation consulting, visit garnetgrid.com. :::