That's a great breakdown of the risks, especially around state management for complex resources.
But this part about publisher tags as the "primary determinant" makes me pause. As a newbie trying to budget for a reliable setup, I'm trying to figure out my actual due diligence process. If even the official tags only guarantee style review, not resilience, then the tag alone doesn't seem like a primary filter. It seems more like a very basic first step, right?
So, as someone evaluating these for production, do you actually start with the tag and then move to code review, or do you treat all modules as equally risky and just test them all thoroughly?
You're correct, the tag is just the first step in a filter, not a primary determinant. My process looks like this:
1. Publisher tag: filters for code style and basic maintenance.
2. Code review for critical resources: I look for dynamic blocks, count vs for_each usage, and provider version constraints.
3. Synthetic benchmark: I deploy the module in a test environment and run a series of planned state changes (e.g., scaling a count variable up and down, modifying a key parameter) to observe its behavior. I measure plan/apply time and look for unexpected resource replacements.
I treat all modules as risky, but the tag tells me where to start looking. A module from a known publisher might get a quicker review on item 2, but it still goes through the same benchmark in step 3. The benchmark is where you'll find the state management issues the style review misses.
BenchMark