Terraform Basics - Providers, Resources and State

Terraform is an open-source Infrastructure as Code (IaC) tool created by HashiCorp that lets you define, provision, and manage cloud infrastructure using a declarative configuration language called HCL (HashiCorp Configuration Language). Instead of clicking through cloud consoles or writing imperative scripts, you describe the desired state of your infrastructure in .tf files and Terraform figures out the sequence of API calls needed to reach that state. This means your infrastructure is versioned, repeatable, and reviewable in pull requests just like application code.

Terraform works through three core concepts. A provider is a plugin that knows how to interact with a specific cloud or service API - there are providers for AWS, GCP, Azure, Kubernetes, GitHub, Datadog, and hundreds more. A resource is the fundamental building block - it represents a single piece of infrastructure such as a VM, a database, a storage bucket, or a DNS record. State is a JSON file (terraform.tfstate) that records the current real-world state of every resource Terraform manages, so it can calculate what changes need to be applied to reach the desired configuration on the next run.

The below example shows a complete Terraform configuration that creates a GCS bucket and a Compute Engine VM on Google Cloud Platform, demonstrating the core workflow of init, plan and apply.

The Terraform workflow - init, plan, then apply,

It gives the following output,

# terraform init output:
Initializing the backend...
Initializing provider plugins...
- Finding hashicorp/google versions matching "~> 5.0"...
- Installing hashicorp/google v5.10.0...
Terraform has been successfully initialized!

# terraform plan output:
Terraform will perform the following actions:

  # google_compute_instance.app_server will be created
  + resource "google_compute_instance" "app_server" {
      + name         = "dev-app-server"
      + machine_type = "e2-medium"
      + zone         = "us-central1-a"
      ...
    }

  # google_storage_bucket.app_bucket will be created
  + resource "google_storage_bucket" "app_bucket" {
      + name     = "my-gcp-project-dev-app-data"
      + location = "us-central1"
      ...
    }

Plan: 2 to add, 0 to change, 0 to destroy.

# terraform apply output (after typing "yes"):
google_storage_bucket.app_bucket: Creating...
google_storage_bucket.app_bucket: Creation complete after 2s
google_compute_instance.app_server: Creating...
google_compute_instance.app_server: Creation complete after 18s

Apply complete! Resources: 2 added, 0 changed, 0 destroyed.

Outputs:
bucket_url   = "gs://my-gcp-project-dev-app-data"
vm_external_ip = "34.72.123.45"

The below example shows how to use a terraform.tfvars file to supply variable values without passing them on the command line every time.

It gives the following output,

# After plan with tfvars:
Plan: 2 to add, 0 to change, 0 to destroy.

# After terraform state list:
google_compute_instance.app_server
google_storage_bucket.app_bucket

Key Terraform concepts to understand:

Idempotency - Running terraform apply multiple times on the same configuration is safe. If the infrastructure already matches the config, Terraform reports "0 to add, 0 to change, 0 to destroy" and makes no API calls.

State locking - When using remote state in GCS or S3, Terraform locks the state file during operations to prevent two team members from running apply simultaneously and corrupting the state.

Resource dependencies - Terraform automatically detects dependencies between resources. If resource B references an attribute of resource A, Terraform knows to create A first. Use depends_on for explicit dependencies that cannot be inferred from attribute references.