Terraform: Plan, State, and Real Infrastructure

Enterprise problem: Ziba needs more schedulable memory, but applying an unreviewed Terraform edit can replace a node pool, race another operator, expose secrets through state, or leave paid resources partially changed while the blog remains unavailable. Whole-course context: The IaC discipline established versioned intent, controlled execution, and evidence; today examines Terraform as one stateful implementation of that discipline. Today’s slice: We connect HashiCorp Configuration Language (HCL), providers, refresh, plan, state, apply, and Google Cloud reality for a bounded GKE node-pool change. End-of-day evidence: A reviewer can explain every proposed create/update/replace/delete action, identify its state binding and physical effect, and prove the served Ziba revision after apply. Still unsolved: Kubernetes application reconciliation, advanced module design, state migration, disaster recovery, and production spend approval remain separate work.

Terraform output is useful only when it protects the customer outcome, so these use cases bind resource mapping and concurrency to Ziba’s availability. One covers change; the other covers drift and failure recovery.

The words “plan succeeded” do not prove what will run, so actors need acceptance conditions across Terraform and Kubernetes. These stories make identity, inputs, resource IDs, and service evidence explicit.

Terraform crosses configuration, state, and remote APIs, so skipping any comparison makes the proposed change misleading. The flows use a saved plan and a recovery decision rather than assuming rerunning apply is always safe.

Terraform state is not the cloud and not merely a cache: it binds resource addresses in configuration to remote object identities and records metadata needed to plan changes. HashiCorp documents that Terraform refreshes resource information before operations and expects a one-to-one mapping between a configured resource instance and a remote object (Terraform state, purpose of state).

Treating the state file as harmless generated output risks credential exposure and concurrent corruption. HashiCorp recommends a secure remote backend for collaboration and warns against storage without appropriate access control and locking because state can contain sensitive values (state storage guidance).

Generated-application database: Not created in this slice — Terraform backend records, provider resources, Kubernetes observations, and release evidence are sufficient; Ziba’s domain data is not owned by infrastructure state.

The shallow model says Terraform reads code and creates infrastructure, but it actually compares three views before issuing operations. Expand the middle box into configuration, prior bindings, refreshed remote attributes, a dependency graph, and an execution result.

Terraform’s language is declarative: resource blocks describe intended infrastructure rather than an ordered procedure (Terraform language). Apply can create, update, destroy, or replace resources and then update state so configuration, remote objects, and state correspond (resource lifecycle overview).

A minimal example can still cause expensive resources and disruption, so treat this HCL as a reviewed lab shape rather than a paste-to-production recipe. It creates a GKE cluster without the default node pool, then a separately managed node pool whose VMs supply pod CPU and memory.

terraform {
  required_version = "~> 1.11"
  required_providers {
    google = {
      source  = "hashicorp/google"
      version = "~> 6.0"
    }
  }
}

provider "google" {
  project = var.project_id
  region  = "europe-west2"
}

resource "google_container_cluster" "ziba" {
  name                     = "ziba-prod"
  location                 = "europe-west2"
  remove_default_node_pool = true
  initial_node_count       = 1
  networking_mode          = "VPC_NATIVE"
  deletion_protection      = true
}

resource "google_container_node_pool" "general" {
  name     = "general"
  cluster  = google_container_cluster.ziba.id
  location = google_container_cluster.ziba.location

  autoscaling {
    min_node_count = 1
    max_node_count = 4
  }

  node_config {
    machine_type = "e2-standard-4"
    disk_type    = "pd-balanced"
    disk_size_gb = 100
  }
}

Do not hard-code credentials. Supply short-lived workload identity to the runner, restrict the backend separately from infrastructure APIs, and review provider/module upgrades because they can change schemas and plans.

HCL names logical resources, while providers translate them into API operations whose software and hardware consequences vary. Review the proposed action, especially replacement, rather than inferring safety from a small text edit.

Rerunning a failed apply without inspection can hide partial success or collide with another writer. Use a bounded sequence, preserve the lock unless you prove it is stale, and never edit state JSON directly.

terraform fmt -check
terraform init -lockfile=readonly
terraform validate
terraform plan -out=ziba.tfplan
terraform show ziba.tfplan
sha256sum ziba.tfplan
terraform apply ziba.tfplan
terraform output -json
kubectl get nodes -o wide
kubectl get pods -n blog -l app=ziba -o wide
curl --fail --show-error "${ZIBA_URL}/healthz"

If reality contains a legitimate object absent from state, inspect and import it under one reviewed resource address, then generate a fresh plan. If configuration and state deliberately change addresses, use supported refactoring operations. terraform state rm forgets an object but does not delete the remote object, so it can create unmanaged paid infrastructure if used casually.

A Terraform failure is not automatically solved by force-unlocking or applying again. Identify whether configuration, binding, remote API execution, persistence, or runtime verification failed.

Terraform implements IaC through declarative configuration, provider plugins, execution plans, and persistent state bindings. None of these alone is the real infrastructure.

• Configuration says what Terraform should manage; state maps addresses to remote object identities.
• Plan compares configuration, state, and refreshed provider reality; apply performs the proposed API operations.
• A VM resource ultimately allocates physical compute, memory, storage, and networking capacity.
• Saved-plan approval, remote locking, state protection, and runtime probes form one safety chain.
• Terraform can create GKE foundations; Argo CD will later complement it by reconciling Kubernetes application manifests.

A Terraform run is complete only when resource ownership and the customer outcome agree. Retain this evidence with the exact configuration revision.

• [ ] Pinned Terraform, provider, and module versions with a committed dependency lock file
• [ ] Encrypted remote backend, restricted access, versioning, and supported locking/concurrency control
• [ ] Fresh saved plan reviewed for create/update/replace/delete and bound to approval
• [ ] Short-lived least-privilege provider identity and separate backend authority
• [ ] State serial, provider IDs, node allocatable values, pod placement, image digest, and Ziba HTTP result captured
• [ ] Recovery procedure covers partial apply, import, refactor, stale lock, and state backup restoration