What does TFLint catch in Terraform code that `terraform validate` cannot, and how does it know?

## The gap TFLint fills After `terraform validate`, you know the configuration is internally consistent and matches the provider schema. You still know nothing about two large categories of defect: 1. **Values the provider or API will reject.** The schema says `instance_type` is a string. It does not enumerate which strings exist. `"t3.mikro"` is a perfectly valid string. 2. **Things that are legal but wrong.** A variable nobody references. A deprecated idiom. A resource named inconsistently with the rest of the repo. A missing `required_version`. None of these is a schema violation, so validate is silent. TFLint is the linter for exactly that band — above schema correctness, below security policy. ## Two sources of rules TFLint ships a **bundled Terraform ruleset** covering tool-level and style concerns. Well-known rules include: - `terraform_unused_declarations` — variables, locals or data sources that nothing consumes; - `terraform_deprecated_interpolation` — the legacy `"${var.x}"` wrapping where a bare expression now belongs; - `terraform_required_version` — the root module fails to pin a Terraform version constraint; - `terraform_naming_convention` — resource and variable names that do not match the configured convention. Separately, **provider rulesets** are installed as plugins. You declare them in `.tflint.hcl` and run `tflint --init` to download them: ```hcl plugin "aws" { enabled = true version = "0.31.0" source = "github.com/terraform-linters/tflint-ruleset-aws" } rule "terraform_naming_convention" { enabled = true } ``` The AWS ruleset is where value knowledge lives — rules like `aws_instance_invalid_type` are generated from the provider's known-valid values and shipped inside the plugin. That is the answer to the "how does it know" half of the question: it is not calling an API at lint time, it is consulting a table that was baked into the plugin when it was released. The consequence is good and bad. Good: the check is fast, deterministic, and needs no credentials, so it belongs in the same early CI stage as fmt and validate. Bad: the table has a release date. A newly launched instance family can be flagged as invalid until the ruleset is upgraded, so pin the plugin version and expect to bump it. ## Running it ```bash tflint --init # download the plugins named in .tflint.hcl tflint --recursive # lint the root module and everything beneath it tflint --format=json # machine-readable output for CI annotation ``` Like `terraform fmt`, TFLint examines a single directory unless you ask it to recurse — the same trap where a root-level lint passes while `modules/` goes unchecked. It also supports SARIF output, which is what you want if your platform ingests findings into a code-scanning view. Rules are individually enablable and disablable in `.tflint.hcl`, and inline comments can suppress a specific finding. Both matter in practice, because a linter that fires on things a team has consciously decided to do gets switched off entirely rather than tuned — and a disabled linter finds nothing. ## What TFLint is not It is not a security scanner. "This security group allows 0.0.0.0/0 on port 22" and "this bucket has no encryption configured" are compliance findings, and the tools for those are Checkov, Trivy and the like, whether run over HCL or over JSON plan output. Some overlap exists at the edges, but treating TFLint as your control coverage is a mistake reviewers notice. It is also not a test framework. It never evaluates whether your module produces the right resources for a given set of inputs — that is `terraform test` with `.tftest.hcl` files, or a Go integration test. ## How to frame it in an interview The crisp version: validate checks the shape, TFLint checks the content and the conventions, scanners check the risk, and the test framework checks the behaviour. Naming the boundary between the first two — schema versus bundled value knowledge — is what shows you have actually run the tool rather than read its README.