6  Review tools

Several tools can automate checks that would otherwise need to be done manually. Running these before requesting a review — and checking their output as part of your review — saves time and catches a consistent set of common problems.

This chapter covers the four tools used in this organisation:

These tools complement each other. None of them replaces human review. They catch different things, and all four should pass before a PR is merged.

6.1 terraform fmt

terraform fmt reformats Terraform code to the canonical style defined by HashiCorp. It handles indentation, spacing, and alignment of = signs.

Why it matters for review: Consistent formatting makes diffs easier to read. A PR that mixes formatting changes with functional changes makes it harder to spot the actual logic change.

Run it:

# Format all files in the current directory and subdirectories
terraform fmt -recursive

# Check without writing (useful in CI)
terraform fmt -recursive -check

As a reviewer: If a PR introduces files with inconsistent formatting, ask the author to run terraform fmt first. Most CI pipelines run this as a check.

If you are using VS Code, the HashiCorp Terraform extension can run terraform fmt automatically on save.

6.2 terraform validate

terraform validate checks that the configuration is syntactically correct and internally consistent. It checks that all required arguments are present, that references between resources are valid, and that variable types are correct.

What it does not check: It does not make API calls to your cloud provider. It does not know whether a referenced project, service account, or resource actually exists. It does not check whether your IAM bindings are appropriate.

Run it:

# Initialise first (needed to download providers)
terraform init

# Then validate
terraform validate

As a reviewer: terraform validate should always pass. A PR that does not pass validation has a fundamental configuration error. Check that the CI pipeline includes a validate step and that it passed.

terraform validate requires the providers to be initialised (terraform init) but does not need real credentials or network access to a cloud environment. It is safe to run locally.

6.3 tflint

TFLint is a linter that catches issues that terraform validate misses. It includes rules for:

  • Invalid resource configurations that Terraform accepts but cloud providers reject
  • Deprecated arguments that still parse but will be removed in future provider versions
  • Missing required tags or labels
  • Naming convention violations

TFLint works through a plugin model. To enable provider-specific rules, install the relevant plugin. For GCP, use the tflint-ruleset-google plugin.

Run it:

# Initialise plugins (first time or after config changes)
tflint --init

# Run against the current directory
tflint

# Run recursively across all modules
tflint --recursive

Configuration: TFLint is configured via a .tflint.hcl file. The terraform-template repository includes a shared configuration in configs/. Use it as your starting point.

As a reviewer: Check that TFLint has been run and that any findings are either fixed or have a clear justification for being ignored. A .tflint.hcl that disables most rules is a red flag — ask why the rules are disabled.

GCP-specific: The tflint-ruleset-google plugin can catch GCP-specific issues such as invalid machine types, deprecated API versions, and missing required labels. Enable it in your .tflint.hcl:

plugin "google" {
  enabled = true
  version = "0.30.0"
  source  = "github.com/terraform-linters/tflint-ruleset-google"
}

6.4 checkov

Checkov is a static analysis tool for infrastructure as code. It scans Terraform (and other IaC formats) against a library of security and compliance checks. These checks cover things like:

  • Storage buckets with public access enabled
  • Databases without encryption at rest
  • Firewall rules that allow unrestricted access
  • Missing logging or audit configuration
  • IAM roles with excessive permissions

Install it:

pip install checkov

Run it:

# Scan a directory
checkov -d terraform/01_sandbox

# Output results in a more readable format
checkov -d terraform/01_sandbox --output cli

# Run only specific check IDs
checkov -d . --check CKV_GCP_28,CKV_GCP_29

Understanding the output: Checkov reports findings as PASSED, FAILED, or SKIPPED. A failed check means the code does not meet a defined security standard. Review failed checks carefully before deciding whether to fix them or accept the risk.

Suppressing findings: Some findings may be intentionally accepted — for example, a sandbox storage bucket that is publicly readable for a legitimate reason. Use inline suppressions with a comment explaining the rationale:

resource "google_storage_bucket" "public_dataset" {
  name = "my-public-dataset"

  #checkov:skip=CKV_GCP_62:Bucket is intentionally public for published open data
  #checkov:skip=CKV_GCP_78:Access logging not required for public read-only bucket
}

As a reviewer: Every suppressed finding should have a comment. If a finding is suppressed without explanation, ask why. If a finding is suppressed with an explanation that does not make sense for the environment (for example, disabling an encryption check in production), block the PR.

GCP-specific: Checkov includes a large set of GCP-specific checks (prefixed CKV_GCP_). The most important ones to watch for in review include:

  • CKV_GCP_28 — ensure that Cloud Storage buckets are not anonymously or publicly accessible
  • CKV_GCP_62 — ensure that Cloud Storage buckets have access logging enabled
  • CKV_GCP_78 — ensure that Cloud SQL instances have deletion protection enabled
  • CKV_GCP_111 — ensure that Cloud Storage buckets have uniform bucket-level access enabled

6.5 Summary

Tool What it checks Must pass?
terraform fmt Code formatting Yes — no exceptions
terraform validate Syntax and internal consistency Yes — no exceptions
tflint Best practices, deprecated usage, provider rules Yes — findings must be fixed or suppressed with a comment explaining why
checkov Security and compliance posture Yes — findings must be fixed or suppressed with a comment explaining why

All four tools must have a clean result before a PR is approved. “Clean” means either all checks pass, or any that do not pass are explicitly suppressed with an inline comment explaining the reason. A finding that is silently ignored — no suppression, no explanation — is not acceptable.

The PR author is responsible for running all tools and resolving or suppressing findings before requesting review. Most tools also run in CI. As a reviewer, check the CI status and read every suppression before approving — an unexplained suppression should be treated the same as a failing check.