<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Infrastructure-as-Code on RLGeeX</title><link>https://www.rlgeex.com/tags/infrastructure-as-code/</link><description>Recent content in Infrastructure-as-Code on RLGeeX</description><generator>Hugo</generator><language>en-us</language><copyright>RLGeeX © 2025 - Real-Life Geeks providing expert IT consulting</copyright><lastBuildDate>Thu, 29 Jan 2026 09:00:00 -0500</lastBuildDate><atom:link href="https://www.rlgeex.com/tags/infrastructure-as-code/index.xml" rel="self" type="application/rss+xml"/><item><title>Reusable Terraform modules for a GCP foundation: draw boundaries by ownership</title><link>https://www.rlgeex.com/news/reusable-terraform-modules-for-a-gcp-foundation-draw-boundaries-by-ownership/</link><pubDate>Thu, 29 Jan 2026 09:00:00 -0500</pubDate><guid>https://www.rlgeex.com/news/reusable-terraform-modules-for-a-gcp-foundation-draw-boundaries-by-ownership/</guid><description>&lt;p>This post is for cloud engineers building a GCP foundation with Terraform who have reached the point where the same networking or logging configuration keeps reappearing and someone suggests making it a module. My argument is about where to draw the module boundaries. Split modules by who is allowed to change the infrastructure and how often it changes. Keep each module narrow, and version it like a library. Getting the boundaries right early costs far less than refactoring a foundation that everything else sits on.&lt;/p></description></item></channel></rss>