TerraformMonkey

Posted on Jul 3 • Edited on Jul 25

🧭 Navigating the Complexity of Modules in Terraform on Day 2

#devops #terraform #opensource #aws

When your Terraform setup grows beyond a few files and resources, one word starts to dominate the conversation: modules.

Modules are powerful. They bring structure, reusability, and governance. But on Day 2 of your Terraform journey — when you're not just building, but maintaining and evolving cloud infrastructure — they can also become a source of chaos.

Let’s unpack what makes modules so tricky on Day 2, and how you can avoid the most common traps.

🧱 What Are Terraform Modules, Really?

At their core, modules are just folders with Terraform code. You can use them to group resources together and reuse them across your configurations.

You’ve likely seen this before:

module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "3.14.2"
  name    = "prod-vpc"
  cidr    = "10.0.0.0/16"
  ...
}

Clean. Reusable. Simple... right?

Not always.

😬 Where Things Start to Break: Day 2 Realities

On Day 1, you deploy modules. On Day 2, you live with them.

1. Opaque Outputs

Have you ever stared at a resource in the cloud and asked yourself:

“Which module created this?”

Now try doing that across dozens of modules, with nested dependencies, in multiple environments.

There’s no built-in traceability from deployed infra back to the exact line of module code. That’s a problem.

2. Versioning Nightmares

You think semantic versioning will save you — until someone updates a shared module and suddenly

your dev, staging, and prod environments are out of sync.

source = "git::https://github.com/company/modules//vpc?ref=v1.0.3"

That little ref can cause big problems if not managed carefully.

As HashiCorp themselves warn, if you don’t pin versions or manage them centrally, you can introduce unexpected changes across environments.

3. Drift Within Modules

Terraform drift detection tools often operate at the state file level — but inside modules, a change to a single property (e.g., changing a tag or enabling a feature) can silently drift from the source code.

On Day 2, you need more than just "terraform plan". You need visibility into what's changed inside your modules and whether the infrastructure still reflects the desired code.

Learn more about how to detect and remediate drift in cloud infrastructure.

4. ClickOps and the Hidden Cost of Hotfixes

We’ve all been there.

“Just go into the console and fix it real quick.”

Except that quick fix bypasses your module. Now your infra no longer matches the code.

Congratulations — you’ve just created invisible debt.

ClickOps undermines governance, traceability, and your entire GitOps process.

Here’s a deep dive into what ClickOps really is and how to prevent it.

🔍 Why Is Module Governance So Hard?

Because Terraform was designed for flexibility, not control.

And that’s fine on Day 1. But by Day 2, you need:

A clear map from deployed infra → source code
Visibility into which module version is deployed where
Confidence that all environments are aligned and drift-free
Guardrails that prevent risky ClickOps changes
Automation that can roll back, remediate, or re-deploy when something drifts

For example, what if you could run a system-wide integrity check between your Terraform code and your cloud infrastructure?

Here’s how one team did it.

✅ How to Take Back Control

If your Terraform usage has scaled across teams and services, here’s what helps:

Module Catalogs: Define a source of truth for your approved modules.
Version Pinning & Policies: Enforce version locks and promote modules through environments. (See: Module-only Terraform provisioning policy)
Drift Detection: Use tools that go beyond state files and validate live cloud vs. code.
Infrastructure-to-Code Mapping: Ensure every resource is traceable to a module or file.
Self-Service Portals (optional): Give devs a safe way to consume modules without editing code.

🔧 Bonus Tips for Better Day 2 Terraform

Learn how to use Terraform variables effectively across modules and environments.
Know how to debug and handle common Terraform errors before they cascade through your modules.
Review your module structure and inputs regularly — what worked at 10 modules may break at 100.

🛡️ Final Thought

Modules aren’t the problem — unmanaged modules are.

If Day 1 is about building infrastructure, Day 2 is about governing it at scale. And that’s where the real work (and opportunity) begins.

💬 How do you manage module complexity at scale? Have you hit any Day 2 challenges with Terraform?

Let’s share battle stories in the comments 👇

DEV Community