Infrastructure as Code Fundamentals

Infrastructure as Code means describing the desired state of your infrastructure in a file rather than clicking through a console. The tool then figures out what needs to change to reach that state. This gives you three things manual configuration can't: a version history of every infrastructure change, the ability to review changes before they happen, and the ability to recreate an environment reliably from the same definition.

The Terraform Workflow

Terraform's core workflow has three steps. terraform plan compares your configuration against the current real-world state and shows exactly what would change — resources to create, modify or destroy — without making any changes. terraform apply executes that plan. terraform destroy tears down what Terraform manages. The plan step is what makes Terraform safe to use on production infrastructure: nothing changes without first being shown, in detail, what will change.

Providers, Resources and Variables

A provider is a plugin that knows how to talk to a specific platform's API — AWS, Azure, Google Cloud, Kubernetes and many others each have one. Resources are the individual pieces of infrastructure you define using that provider's building blocks. Variables let the same configuration be reused with different inputs, which is what makes a single set of Terraform files usable across multiple environments.

variable "environment" {
  type = string
}
resource "aws_s3_bucket" "assets" {
bucket = "isha-${var.environment}-assets"
tags = { Environment = var.environment }
}

Modules and Reusable Infrastructure

A module is a self-contained, reusable Terraform configuration — for example, a "standard VPC" module that always creates the same subnet layout, route tables and NAT gateways, parameterized by CIDR range and environment name. Modules let a platform team encode organizational standards once and let application teams consume them with a handful of input variables, instead of every team reinventing networking from scratch.

State Management and Remote State

Terraform tracks what it has created in a state file, which maps your configuration to real resource IDs. For anything beyond a single person experimenting locally, that state needs to live somewhere shared and lockable — commonly an object storage bucket with a locking mechanism (like a database table or native locking support) so two people running apply at the same time don't corrupt each other's changes.

Environment Management

Separate environments should use separate state files, not just separate variable values against shared state — mixing them risks a mistake in one environment affecting another. A common pattern is one state file per environment (dev, staging, production), often organized with Terraform workspaces or simply separate directories per environment referencing the same modules.

Code Review and CI/CD Integration

Because Terraform configuration is just code, it can go through the same review process as application code: pull requests, automated linting, and a plan output posted for reviewers to read before merge. Running plan in CI on every change and apply only after merge and approval keeps infrastructure changes auditable in exactly the same way as application deployments.

Drift Management and Security Considerations

Drift happens when real infrastructure is changed outside of Terraform — a manual console edit, for example — so the actual state no longer matches the configuration. Regularly running plan against production (even without applying) surfaces drift early. On the security side, state files can contain sensitive values, so they need the same access controls and encryption as any other sensitive data, and the credentials Terraform runs with in CI should be scoped narrowly to what that pipeline actually needs to manage.