Terraform for IAM policies always begins with a noble dream. Someone looks at a sprawling identity environment, full of hand-crafted roles and permissions, and says, “What if we wrote this down?” Not documented, but codified. Versioned. Repeatable. Immutable, even. This is the moment Infrastructure as Code enters the room wearing a clean hoodie and promising order, accountability, and fewer late-night emergencies.
At first, it feels magical. IAM policies become files instead of folklore. Roles stop being created by clicking around with hope in your heart. You can see permissions, review them, and even argue about them in pull requests like responsible adults. Terraform turns identity from a whispered tradition into a declarative statement. This is what access should look like. If it doesn’t, the plan will tell you, calmly and without judgment.
Then reality joins the conversation. IAM is not just infrastructure. It’s politics. Terraform wants a single source of truth, but identity has many. There’s the policy someone added for a vendor. The exception made during an outage. The role that exists because removing it would require a meeting no one wants to attend. Terraform notices these things immediately. It doesn’t care why they exist. It just wants to reconcile them, preferably by deleting them while you’re not looking.
The first plan output is always longer than expected. Lines scroll by describing changes you didn’t know existed. Resources you swear you never created. Permissions that appear to grant far more access than anyone is comfortable admitting. Terraform is not being dramatic. It’s being honest. This is what your IAM environment actually looks like, not what the architecture diagram claims it looks like.
IAM policies themselves are where Terraform truly shines and occasionally terrifies. Writing permissions as code forces precision. No more “just in case” access hidden behind checkboxes. Every action, resource, and condition is spelled out. You learn very quickly how much access a role really has when it’s expressed in plain text and reviewed by peers who ask uncomfortable questions. Terraform doesn’t allow vague intentions. It requires decisions.
State management becomes the silent protagonist in this story. IAM managed by Terraform depends entirely on the state file knowing the truth. Lose it, corrupt it, or share it carelessly and identity chaos follows. Suddenly Terraform isn’t sure who owns what, and IAM resources start behaving like cats introduced to a new house. Everything still exists, but no one trusts anyone anymore.
There’s also the joy of provider differences. Azure, AWS, and others all agree on the idea of IAM but disagree on the grammar. Terraform smooths this over just enough to be useful, but not enough to be painless. You learn that a role assignment in one platform behaves nothing like a policy attachment in another. Terraform doesn’t hide this. It simply hands you the abstraction and watches you learn the boundaries.
Despite the challenges, something profound happens over time. IAM changes slow down. Not because they’re harder, but because they’re intentional. Access reviews become diff reviews. Audits turn into repository walkthroughs. When someone asks why a permission exists, the answer is no longer a shrug. It’s a commit message. Identity gains memory.
Terraform also teaches humility. You learn that deleting IAM resources is scarier than creating them. You learn to plan, apply carefully, and sometimes accept that certain permissions will remain until the organization is ready, not just the code. Infrastructure as Code doesn’t eliminate risk. It makes risk visible, and visibility is uncomfortable at first.
Using Terraform for IAM policies is not about automation for its own sake. It’s about discipline. It’s about admitting that identity is too important to live only in portals and muscle memory. Terraform doesn’t make IAM perfect. It makes it accountable. And in a world where access defines impact, that’s a trade worth making.
In the end, Terraform doesn’t manage identity for you. It holds up a mirror and says, “This is who you are.” What you do with that information is where architecture begins.