Infrastructure as Code: Terraform, Lifecycles & Drift

Infrastructure as Code

Why Engineers Care About This

Infrastructure as Code (IaC) manages infrastructure with code instead of manual configuration. This enables versioning, repeatability, and automation. But IaC requires careful management—state management, change planning, and testing. Understanding IaC helps you build reliable, scalable infrastructure. Without IaC, infrastructure is managed manually (error-prone, inconsistent). With IaC, infrastructure is managed with code (repeatable, versioned).

When infrastructure is inconsistent across environments, or changes are manual and error-prone, or you can't reproduce infrastructure, you're hitting IaC problems. These problems compound. Without IaC, infrastructure drifts (manual changes), environments differ, and disasters are hard to recover from. Good IaC solves these problems by managing infrastructure with code.

In interviews, when someone asks "How would you manage infrastructure for this system?", they're really asking: "Do you understand Infrastructure as Code? Do you know how to use Terraform or CloudFormation? Do you understand state management and infrastructure lifecycle?" Most engineers don't. They manage infrastructure manually or use IaC without understanding principles.

Core Intuitions You Must Build

• Infrastructure as Code enables versioning and repeatability. Infrastructure defined in code can be versioned (Git), reviewed (code review), and repeated (create same infrastructure in multiple environments). This ensures consistency across environments and enables disaster recovery (recreate infrastructure from code). Don't manage infrastructure manually—use IaC for all infrastructure (servers, networks, databases).

• State management is critical for IaC tools. IaC tools (Terraform, CloudFormation) track infrastructure state (what resources exist, their configuration). State is used to plan changes (compare desired state with actual state) and apply changes (create, update, delete resources). State must be managed correctly—store state remotely (S3, Terraform Cloud), lock state during changes, and handle state conflicts. Don't lose state—it's required for managing infrastructure.

• Infrastructure changes should be planned before applying. IaC tools show planned changes before applying them (Terraform plan, CloudFormation changeset). Review planned changes—they show what will be created, updated, or destroyed. Don't apply changes blindly—review plans to catch mistakes. Also, use change approvals for production infrastructure (manual review before applying).

• Infrastructure should be modular and reusable. Infrastructure code should be modular (separate modules for networks, databases, applications) and reusable (use same modules across environments). This reduces duplication and enables consistency. Don't duplicate infrastructure code—create modules and reuse them. Also, parameterize modules (environment-specific values) to enable reuse across environments.

• Infrastructure testing enables validation before applying. Infrastructure code can be tested (syntax validation, plan validation, integration tests) before applying. This catches errors early and prevents bad infrastructure. Use infrastructure testing—validate syntax, review plans, and test in non-production environments before production. Don't apply infrastructure changes without testing.

• Infrastructure drift must be detected and managed. Infrastructure can drift (manual changes outside of IaC) from code-defined state. Detect drift (compare actual state with code state) and manage it (reconcile drift, or update code to match actual state). Don't ignore drift—it causes inconsistencies and makes infrastructure unmanageable.

Subtopics (Taught Through Real Scenarios)

Infrastructure Versioning

What people usually get wrong:

Engineers often manage infrastructure manually without versioning. But infrastructure changes should be versioned (Git) like application code. This enables change tracking, rollbacks, and disaster recovery. Use version control for infrastructure code—commit changes, review changes, and tag releases. Don't manage infrastructure without versioning—you can't track changes or rollback.

How this breaks systems in the real world:

A team managed infrastructure manually (clicking in AWS console). When infrastructure broke, they couldn't track what changed or rollback. Disaster recovery was impossible (didn't know how to recreate infrastructure). The fix? Use Infrastructure as Code (Terraform)—infrastructure defined in code, versioned in Git, and applied consistently. Now changes are tracked, and infrastructure can be recreated from code. But the real lesson is: infrastructure should be versioned. Use IaC for all infrastructure.

What interviewers are really listening for:

They want to hear you talk about infrastructure versioning, change tracking, and disaster recovery. Junior engineers say "just manage infrastructure manually." Senior engineers say "use Infrastructure as Code to version infrastructure (Git), track changes, enable rollbacks, and enable disaster recovery (recreate from code)." They're testing whether you understand that infrastructure should be managed like code.

State Management

What people usually get wrong:

Engineers often don't understand IaC state management. But IaC tools (Terraform) track infrastructure state (what resources exist, their configuration). State is used to plan changes (compare desired state with actual state) and apply changes. State must be managed correctly—store remotely (S3), lock during changes, and handle conflicts. Don't lose state—it's required for managing infrastructure.

How this breaks systems in the real world:

A team used Terraform but stored state locally. When state was lost (disk failure, accidental deletion), Terraform couldn't manage infrastructure (didn't know what resources existed). The fix? Store Terraform state remotely (S3) with versioning and locking. Now state is safe and shared across team members. But the real lesson is: IaC state is critical. Store it remotely and protect it.

What interviewers are really listening for:

They want to hear you talk about IaC state management, remote state, and state locking. Junior engineers say "just use local state." Senior engineers say "IaC tools track infrastructure state—store state remotely (S3, Terraform Cloud), enable locking to prevent conflicts, and version state for disaster recovery." They're testing whether you understand that state management is critical for IaC.

Infrastructure Modules and Reusability

What people usually get wrong:

Engineers often duplicate infrastructure code across environments. But infrastructure code should be modular and reusable. Create modules (networks, databases, applications) and reuse them across environments (dev, staging, prod) with parameters (environment-specific values). This reduces duplication and enables consistency.

How this breaks systems in the real world:

A team duplicated infrastructure code for each environment (dev, staging, prod). When infrastructure changed, they had to update code in three places, causing inconsistencies and errors. The fix? Create reusable modules—define infrastructure once, parameterize environment-specific values, and reuse across environments. Now infrastructure is consistent and maintainable. But the real lesson is: infrastructure code should be modular and reusable. Don't duplicate code.

What interviewers are really listening for:

They want to hear you talk about infrastructure modules, reusability, and parameterization. Junior engineers say "just duplicate infrastructure for each environment." Senior engineers say "create modular, reusable infrastructure code—separate modules for different components, parameterize environment-specific values, and reuse modules across environments for consistency." They're testing whether you understand that infrastructure code should follow software engineering principles (DRY, modularity).

---

• Infrastructure as Code enables versioning and repeatability—manage all infrastructure with code
• State management is critical for IaC tools—store state remotely, enable locking, version state
• Infrastructure changes should be planned before applying—review plans to catch mistakes
• Infrastructure should be modular and reusable—create modules, parameterize values, reuse across environments
• Infrastructure testing enables validation before applying—validate syntax, review plans, test in non-production
• Infrastructure drift must be detected and managed—compare actual state with code state, reconcile drift
• Good Infrastructure as Code enables reliable, scalable, repeatable infrastructure

---

• CI/CD Pipelines - Applying infrastructure changes in pipelines
• Kubernetes - Managing Kubernetes infrastructure with IaC
• System Design - Designing infrastructure for scalable systems