Terraform Module Review Checklist

When to Use This Checklist

Use this when reviewing a Terraform module before publishing it to a shared registry, or when auditing modules already in use. Shared modules are leverage: one good module improves every consumer, and one insecure or brittle module spreads its flaws everywhere. This checklist applies equally to Terraform and OpenTofu.

Review both new modules and inherited ones, since modules accrete complexity and risk as they are extended.

How to Use This Checklist

Start with design intent: a module should do one thing well, with a clean variable interface. Confirm variables are typed, described, and validated, and that outputs do not leak secrets in plaintext. Then move to security: run a static scanner, check for hardcoded credentials, and confirm state is encrypted and locked.

Prove behavior, not just code: apply the module, then apply again to confirm idempotence, and confirm destroy leaves nothing orphaned. Automated tests make this repeatable for future changes.

What Good Looks Like

A good module has a single responsibility and a typed, documented, validated interface. Provider and module versions are pinned, a static security scan passes, and no secrets are hardcoded or exposed in state. The module applies idempotently, destroys cleanly, and follows tagging and naming standards. Remote state and locking are configured, an example and README exist, and automated tests guard against regressions.

Common Pitfalls

The most common pitfall is a god-module that tries to provision everything, making it impossible to reuse. Unpinned versions cause silent drift between applies. Untyped or unvalidated variables push errors to apply time instead of plan time. Hardcoded secrets and unencrypted state are serious security gaps. Skipping the second apply hides non-idempotent resources, and a module that cannot destroy cleanly leaves expensive orphaned resources behind.

Related Resources

Ground the review in Terraform module design patterns and the IaC security playbook. Pipeline-as-code and configuration-as-code practices place the module in a safe delivery flow, and the migration guides help when moving from CloudFormation or to OpenTofu/Pulumi.