Terraform & IaC: The Myths That Cost You Money and How Infrastructure as Code Actually Works

A few months ago, a team I know needed to spin up a staging environment in AWS. The lead engineer said, "We have Terraform, just run terraform apply." Twenty minutes later, they were staring at a plan that wanted to destroy the production database. The state file had been generated from a different workspace. Nobody had locked it. Nobody had reviewed the plan. That's the moment the myths about Infrastructure as Code (IaC) stop being abstract.

Terraform & IaC is often sold as a magic wand: write a few lines of HCL, and your cloud manages itself. In reality, it's a discipline of managing state, dependencies, and drift. Get it right, and you get repeatable, versioned environments. Get it wrong, and you get a very fast, very automated way to break things.

This article isn't a syllabus. It's what you actually need to know before you trust your infrastructure to code.

Why IaC Is Not Just Fancy Scripting

If you've ever clicked through a cloud console to set up a VPC, you know the pain: nobody remembers which subnet has the NAT gateway, and the security group rules are a mystery. IaC solves that by making infrastructure declarative and version-controlled. You describe the desired state, and the tool figures out how to get there.

But the core mechanism is not the code itself. It's the state file — a JSON (or similar) record of what the tool believes exists. Terraform uses state to map your configuration to real resources. Pulumi, an alternative, uses general-purpose languages and stores state similarly. The state is the source of truth, and it's also the biggest source of trouble.

Key distinction: IaC tools don't just run scripts; they reconcile the real world with your declared state. If the state is wrong, everything downstream is wrong.

A Real Walkthrough: Adding a Database to an Existing VPC

Let's say you have a working VPC managed by Terraform, and you need to add a PostgreSQL RDS instance. Here's how a practitioner does it — and where it can go sideways.

1. Check the current state. Run terraform state list to see what Terraform thinks it owns. If the VPC isn't there, you have a problem. Maybe it was created manually, or the state is stale.
2. Write the resource block. For example:

   resource "aws_db_instance" "main" {
     allocated_storage = 20
     engine            = "postgres"
     instance_class    = "db.t3.micro"
     name              = "appdb"
     username          = "admin"
     password          = var.db_password
     skip_final_snapshot = true
   }

1. Run terraform plan and read it. This is where people skip ahead. The plan will show what will be created, changed, or destroyed. If you see any -/+ (destroy and recreate), stop. That might be fine for a stateless resource, but not for a database.
2. Apply. terraform apply will create the instance. But here's the non-obvious part: Terraform will also try to update the VPC's security groups if you reference them. If you haven't set up proper dependencies (using depends_on or implicit references), you might get a race condition where the database is created before the security group rule that allows access.

What breaks if you do it differently: If you skip the plan review, you might miss that Terraform wants to replace the database because of a changed parameter (like name). That means downtime and data loss. If you don't lock the state (using a backend like S3 with DynamoDB locking), two engineers applying at the same time can corrupt the state file. Recovery involves manually editing the state or importing resources — hours of pain.

Where the IaC Mechanism Itself Breaks

Even if you follow best practices, IaC has failure modes built into its design.

State Drift and Manual Changes

Someone logs into the console and resizes an instance. Terraform doesn't know. The next plan will show a change back to the declared size, potentially causing a reboot. How to spot it early: run terraform plan regularly in CI (a "drift detection" job). If the plan is not empty, investigate.

Provider Bugs and API Changes

Cloud providers change APIs. A Terraform provider update might introduce a breaking change. For example, a new version might require a field that didn't exist before, causing a forced replacement. What to do: pin provider versions in your configuration (required_providers block) and test upgrades in a non-production environment first.

The "Works on My Machine" State

If you store state locally, collaboration is impossible. New team members can't apply changes without risking conflicts. The fix: use a remote backend with locking from day one. Terraform Cloud, S3 + DynamoDB, or similar.

Tip-box: Always run terraform plan in CI and require approval before apply. A plan is cheap; a mistake is not.

Terraform vs. Pulumi: The Trade-off

Terraform uses HCL, a declarative language. Pulumi lets you use TypeScript, Python, Go, or C#. The trade-off is real:

• Terraform: mature ecosystem, huge provider support, but HCL can feel limiting for complex logic.
• Pulumi: real programming languages mean you can use loops, conditionals, and existing libraries. But it's younger, and the state management is similar (you still need a backend).

If your team is already fluent in TypeScript, Pulumi might reduce the learning curve. If you need the broadest provider coverage, Terraform is safer. Neither is "better" — they solve the same problem with different ergonomics.

Learning Paths: Self-Study vs. Structured Courses

You can learn IaC on your own: read the Terraform docs, follow tutorials, and experiment. That works if you have a sandbox account and time to break things. But self-study has a hidden cost: you don't know what you don't know. You might never encounter state locking until you corrupt a state file in production.

A structured course, like Terraform & IaC, walks through exactly these scenarios — state management, modules, drift detection — with feedback. It's not the only way, but it closes the gap between "I can write HCL" and "I can safely manage infrastructure."

If you prefer to go it alone, start with the official Terraform tutorials (HashiCorp Learn) and set up a free-tier AWS account. Just be prepared to spend hours debugging cryptic errors.

Who This Is For (and Who It Isn't)

This path suits engineers who already understand cloud basics (VPCs, subnets, IAM) and want to automate provisioning. It's also for DevOps folks tired of snowflake servers. It is not for beginners to cloud computing — you'll drown in concepts like state backends and provider plugins if you don't know what an EC2 instance is.

If you're a developer who just wants to deploy a side project, a simpler tool like AWS CDK or even manual setup might be enough. IaC shines when you have multiple environments, a team, and compliance requirements.

A Non-Obvious Insight: Modules Are Not Libraries

People treat Terraform modules like npm packages — grab one, use it everywhere. But modules are more like templates. A public module for a VPC might have 50 variables, and you'll spend more time configuring it than writing your own. The real value is in internal modules tailored to your organization's standards. Write your own, version them, and treat them as code. That's where the leverage is. For a deeper dive into this topic, see CI/CD as an Art: A Real Pipeline Breakdown and Costly Mistakes.

Infrastructure as code is a skill that pays off in fewer 3 a.m. pages and more predictable deployments. If you want a structured path that covers state, modules, and the failure modes above, the Terraform & IaC course on asibiont.com offers personalized lessons adapted to your level. Start with the basics of state management, and build from there.