Terraform validate catches syntax errors and schema violations — it tells you whether your HCL is well-formed and whether you have used the correct argument names for each resource type. What it cannot catch is semantic incorrectness within the schema: using a deprecated instance type like t2.micro when t3.micro is the modern equivalent, referencing a non-existent AWS region like 'ap-south-99', specifying an invalid RDS engine version, or omitting a required tag that your organisation mandates on all resources. These are errors that Terraform will happily accept and attempt to apply, only to fail with a cryptic AWS API error message like 'InvalidParameterValue: The DB engine version 14.99 is not supported for the postgres engine'. tflint fills this gap — it performs static analysis of Terraform configurations using provider-specific rule sets that encode the constraints and best practices of each cloud provider's API.
tflint's plugin architecture is the key to its effectiveness. The core tflint engine handles rule execution and output formatting, while provider-specific plugins (tflint-ruleset-aws, tflint-ruleset-azurerm, tflint-ruleset-google) contain the actual rules derived from each provider's current API documentation. The AWS plugin's rules include: validating that EC2 instance types are valid and current, checking that AMI IDs match the expected format, verifying RDS engine versions are supported, and flagging deprecated arguments. The terraform ruleset checks Terraform-level issues: unused variables, unused declarations, and naming convention violations. Custom rulesets can encode your organisation's specific conventions — required tag keys, approved CIDR ranges, allowed instance families — as tflint rules that run automatically on every PR.