Choosing a module by its evidence
Every module in this catalogue carries a record of what was actually done to it. That record is the product. This guide is about reading it, and about the decision it exists to inform: how much proof does this particular use need?
The four rungs, and what each one costs
The rungs differ in one way that matters more than any other: whether producing the evidence required a real cloud account. That is why the ladder stops where it does for some modules, and it is the honest reason, not a technical one.
| Rung | What was actually done | Needs an account? |
|---|---|---|
| parses | The HCL is syntactically valid. | No |
| static-validated | Formatting, validate, tflint, and a Checkov security scan. Ansible roles get yamllint and ansible-lint instead, and the receipt names which ran rather than implying all of them did. | No |
| plan-validated | A plan against mocked providers. Catches wiring errors that syntax checks miss, without touching a cloud. | No |
| live-tested | Really applied to a cloud account, asserted against, then destroyed, with the teardown confirmed. An apply that was never torn down is an incident, not a pass, and does not earn this rung. | Yes, a real one |
Right now that is 116 live-tested and 67 that stop short of it, out of 183 published. Security scanning is a separate axis, not a rung: 132 pass a Checkov scan, 50 have no policy that applies to them at all, and 1 currently fail. A module with no applicable policy is not a module that passed; the catalogue keeps those apart on purpose.
Deciding which rung you need
The useful question is not “is this module verified?” but “what would go wrong if this specific module were subtly broken, and would a live test have caught it?” Those have different answers per module.
A live test catches the class of failure where the provider rejects what the module asks for: an invalid attribute combination, a resource that cannot actually be created with those inputs, a dependency the graph got wrong, a resource that will not delete cleanly. Those are common, and they are exactly what a plan against mocked providers cannot see.
A live test does not tell you the module is appropriate for your environment, that its defaults match your policy, or that it will behave the same with your inputs. That is a separate question and it is covered in what our verification does not prove.
When static-validated is the honest answer
Most modules that stop at static validation do so for one reason: no sandbox account exists for that cloud yet. The module is not lower quality, it is less proven, and the catalogue refuses to blur those. Each such module says so on its own page and in its README, in the same words.
Taking one is a reasonable decision when you are going to review the plan yourself before applying, which you should be doing regardless. It is a bad decision when you intend to apply it unattended, into an environment where a failed create or a resource that will not destroy is expensive.
Checking the evidence yourself
None of the above is worth anything if you have to take our word for it. Every module publishes a machine-readable receipt, and it needs no account:
curl -s https://www.iac-bazaar.com/api/artifacts/aws-s3-bucket/verificationThe receipt names each check that ran, when it ran, and the SHA-256 of the archive it describes. Where a release is signed it carries the cosign bundle and the exact command to verify it, so the claim can be checked against the artifact rather than against the page making the claim.
One field is worth understanding: asOf is the timestamp of the newest evidence on the record, not the day the module was written. A module live-tested in June and re-scanned for security last week reports last week.
Where to go next
The module reference lists every published module with both evidence axes in one table, filterable. How we verify is the ladder itself in more detail. And comparing the same service across clouds is the next decision once you know which rung you need.