Infrastructure as Code: Learn Terraform with a Local Lab

Infrastructure as code means describing infrastructure in files that a tool can read. Instead of clicking through many screens, you can review a proposed change in Git.

It helps make work repeatable. It does not make a wrong plan safe. You still need to understand the resources and access involved.

Learn these parts

• Configuration: What you want to manage.
• Provider: A plugin that talks to a system, such as a cloud API.
• State: The record used to connect configuration with managed objects.
• Plan: The changes the tool proposes.
• Apply: The step that carries out an approved plan.

A lab with no cloud resources

Install Terraform from its official site. The example needs version 1.10 or newer within the 1.x line. Make an empty iac folder and save main.tf inside:

terraform {
  required_version = ">= 1.10, < 2.0"
}

variable "app_name" {
  type    = string
  default = "lecturre-demo"
  validation {
    condition     = can(regex("^[a-z][a-z0-9-]{2,29}$", var.app_name))
    error_message = "Use 3 to 30 lowercase letters, digits or hyphens, starting with a letter."
  }
}

resource "terraform_data" "app" {
  input = {
    name        = var.app_name
    environment = "learning"
  }
}

output "app_config" {
  value = terraform_data.app.output
}

terraform_data is a built-in resource for storing this small value in state. It does not start a cloud server or open a cloud account.

Run and read the plan

cd iac
terraform init
terraform fmt -check
terraform validate
terraform plan -out=lab.tfplan
terraform show lab.tfplan

The plan should propose one terraform_data.app resource. It should show the name lecturre-demo and environment learning.

If you want to complete this local exercise, run terraform apply lab.tfplan. It writes local state for this demo. Review the saved plan before applying. Do not copy an apply command into a different project without checking its target.

Try input validation

Run terraform plan -var='app_name=Bad Name'. The plan should fail because the input breaks the naming rule. Good tools reject a bad input early.

What state means

State is not just a harmless cache. It can contain sensitive values. Marking an output as sensitive mainly changes how it is displayed; it does not encrypt the state file.

Keep state and saved plans out of public Git. Commit configuration and the dependency lock file when your project uses provider dependencies.

Working as a team

Teams normally use a protected remote state store with locking and recovery. Locking helps stop two writers from changing the same state at once.

This separate S3 backend example assumes you already created the bucket and access rules. It is not part of the local-only lab:

# Separate team-backend example. Do not add this to the local-only lab unchanged.
terraform {
  backend "s3" {
    bucket       = "REPLACE_WITH_YOUR_EXISTING_STATE_BUCKET"
    key          = "lecturre/dev/terraform.tfstate"
    region       = "eu-central-1"
    use_lockfile = true
  }
}

Enable bucket versioning and limit access to both the state object and its lock file. Current Terraform supports S3-native locking with use_lockfile. DynamoDB-based S3 locking is deprecated; do not teach it as the default for a new project.

Modules and environments

A module groups related configuration behind a clear input and output interface. It can help teams share a tested pattern.

Separate development and production carefully. A workspace name alone is not a strong access boundary. Distinct accounts, credentials and state locations may be needed.

Terraform, OpenTofu, Pulumi and Ansible

Terraform and OpenTofu use similar configuration ideas, but check compatibility rather than assuming every feature is interchangeable.

Pulumi lets teams describe infrastructure with supported programming languages. Ansible is often used for configuration and task automation. Choose based on the task, team and support needs.

Whatever tool you use, keep the same habits: small changes, review, tested inputs and a record of what happened.

Common mistakes

• Applying without checking the account or state.
• Keeping real credentials inside configuration.
• Editing state by hand to hide a problem.
• Using automatic approval for every change.
• Assuming a successful plan tested the running application.

Practice

Change the app name and compare the next plan. Add a new input with a clear rule. Explain what belongs in Git and what must stay in protected storage.

Official references and further reading

Reviewed on 25 October 2026. Tools change, so check the official documentation for the version you use.

• Terraform built-in data resource
• Terraform S3 backend and locking
• Sensitive data in Terraform state

DevOps learning roadmap · All DevOps & Cloud tutorials