CKAD field manual

terraform apply example

A .tf file is desired state, same idea as a Deployment YAML — but for the boxes under the cluster, not the cluster's objects. plan is the dry-run, apply is the real thing, state is Terraform's memory of what it already built.

Core loop

terraform init
terraform plan
terraform apply
terraform destroy

main.tf

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

provider "aws" {
  region = "eu-west-3"
}

variable "instance_type" {
  type    = string
  default = "t3.medium"
}

resource "aws_instance" "gateway" {
  ami           = "ami-0123456789abcdef0"
  instance_type = var.instance_type
  tags = {
    Name = "kubelab-gateway-2"
  }
}

output "gateway_ip" {
  value = aws_instance.gateway.public_ip
}

Inspect

terraform validate
terraform fmt
terraform state list
terraform output
terraform apply -var="instance_type=t3.large"

Fields

provider: Which cloud/API this file talks to. Needs a matching required_providers entry above so the version is pinned.
resource: One real thing Terraform creates and tracks in state. The second string is a local name — never sent to the cloud.
variable: An input, optional default. Fill unset ones with -var, a .tfvars file, or a TF_VAR_ environment variable.
output: Printed after apply, and readable by other Terraform configs. Use it to hand the new box's IP to whatever provisions it next.
terraform init: Downloads providers, sets up the backend. Re-run after adding a provider or changing the backend.
terraform plan: Dry-run. Shows +/-/~ per resource. Nothing changes until apply.
terraform apply: Runs the plan for real. Prompts for confirmation unless -auto-approve.
terraform destroy: Tears down everything currently in state. No undo.
terraform state: Lists or edits what Terraform believes exists. This is the source of truth it diffs against, not the .tf files.

Watch

Not a CKAD object — infrastructure-as-code for what the exam cluster runs on, not the cluster itself.
state is the source of truth for what Terraform thinks exists. Delete a resource block and apply destroys the real thing — no undo.
plan is the dry-run. Nothing is created or destroyed until apply — read the +/-/~ diff before typing yes.
Instance/server sizing here is just RAM/CPU. It says nothing about nested-virtualization (KVM) support, which Kata Containers needs — check that separately per provider and instance type.

Official docs Terraform docs Configuration language

Practice these objects on a live cluster →