Create Maintainable Terraform Modules: Encapsulate Logic and Extract Iterations

EPISODE 118
In today’s video, we dive into a code review that tackles a common pain point in Terraform module design: nested iterations and complex logic.

Join me as I review a channel member’s pull request and demonstrate how to encapsulate logic and extract iterations outside the module boundary for cleaner, more scalable Terraform code. Whether you're a Terraform pro or just getting started, you'll learn practical tips to simplify your infrastructure-as-code projects.

🌟 Topics Covered:

The problem with nested for_each loops
Encapsulation techniques for Terraform modules
Refactoring for better readability and maintainability

📖 Read the full blog here:

🔗 Important Links:
1. **Read my book**: Mastering Terraform, A practical guide to building and deploying infrastructure on AWS, Azure, and GCP
5. **Become an Official Azure Terraformer**: For those who want to dive deeper into the world of Terraform, join my channel for exclusive benefits. As an Azure Terraformer Code Ninja, you'll get elite access to my Terraform code reviews. For those in my inner circle, there's even a monthly virtual 1-on-1 session with me!

Don't forget to like, share, and subscribe for more Terraform and Azure content. Your engagement helps this channel grow and allows me to continue providing high-quality tutorials. If you have any questions or suggestions, feel free to drop them in the comments section below.

Happy Azure Terraforming! 🌍💻🚀

[dankitch]

Thanks for the review and tips, really appreciate it. Will look to refactor based on the encapsulation :)

[ttf]

Thanks! Will buy your book right away.

[danielrogers]

This was really great thank you. I have been learning terraform/working with bicep for a while now but the way you broke this down really helped me understand where to set the iteration boundaries; your book has been requested through my work learning system!

I wrote a very similar tf module for managing PIM groups (not Entra roles) and this will really help with refactoring in a similar way. Hopefully I could ask a question though:

For managing PIM things the `azuread_users` and `azuread_groups` data sources are required for mapping users/groups to their object ids. For _n_ items if the data source call was encapsulated within the module would that not perform _n_ entra ad calls for potentially thousands of users/groups on every iteration of the module?

Would it be reasonable to perform the initial data source call in the parent module and pass it in for re-use? I do not know enough about terraform to know if there's already some internal optimisation/caching but whenever I am doing things with Entra objects I try to do a single data lookup and reuse that list wherever possible.

[dascomp]

If it's privileged, you DO want to setup a scheduled just-in-time group membership for the users in the list. If the role isn't privileged, you can let them always keep the role.
This makes sure admins assume privileged roles for short periods only when they need them