Terraform Change Review Field Notes

Use this matrix to prove VM provisioning guardrails before trusting automation with real vSphere creates. The point is not to make every test pass green. The point is to prove each unsafe condition fails at the correct layer. Baseline Commands Generate a plan and plan JSON: terraform init terraform plan -out=tfplan terraform show -json tfplan > tfplan.json Run preflight: ./scripts/preflight-vm-guardrails.sh --plan-json tfplan.json Confirm clean post-apply state when a test intentionally creates a disposable VM: ...

Terraform can validate its own input, but it cannot automatically prove that the outside world is clear. Before applying a vSphere VM plan, run preflight checks against the systems that already know about names and addresses. After testing a disposable VM, verify destroy cleanup as a separate lifecycle check. Preflight protects allocation. Destroy verification protects source-of-truth hygiene. Generate Plan JSON Use the plan as the preflight input: terraform plan -out=tfplan terraform show -json tfplan > tfplan.json Then run the guardrail script: ...

Azure Kubernetes Service follows the same managed-control-plane pattern as EKS and GKE, but the resource model, networking defaults, and identity system are different enough that provider-specific knowledge matters during provisioning. For a runnable lab, see the azure directory in the IaC repository. Resource Group Structure Everything in Azure lives in a resource group. The AKS cluster, VNet, and NSG are typically in the same group for a lab, but production should separate network infrastructure into a shared resource group owned by the platform team: ...

Concourse requires a set of RSA keys for TSA (Transport Security Authority) authentication between web and worker nodes. Managing these keys is a bootstrapping problem: Concourse needs keys to start, but the keys should live in a secrets store. For a runnable lab, see the concourse-terraform-unix directory in the IaC repository. TSA Key Architecture Concourse uses four key pairs: TSA host key (tsa_host_key + tsa_host_key.pub): identifies the web node to workers. Worker key (worker_key + worker_key.pub): identifies workers to the web node. Authorized worker keys (authorized_worker_keys): the public keys of permitted workers. Session signing key (session_signing_key): signs session tokens for the ATC API. The web node holds the TSA host key and authorized worker keys. Workers connect using their worker key. If any key pair mismatches, the worker cannot authenticate and stays disconnected. ...

The boundary between Terraform and Helm is a common source of confusion. Terraform provisions infrastructure. Helm deploys applications. Terraform’s helm_release resource bridges them, but the chart templates stay in the application repository. For a runnable lab, see the helm-terraform-js-app directory in the IaC repository. The Pattern Terraform manages the Helm release with set blocks that inject environment-specific values: resource "helm_release" "my_app" { name = "my-app" chart = "${path.module}/../helm/myapp" namespace = kubernetes_namespace.my_app.metadata[0].name set { name = "image.repository" value = var.docker_image_repository } set { name = "image.tag" value = var.docker_image_tag } set { name = "replicaCount" value = var.replica_count } } The Helm chart stays portable. Environment-specific values live in Terraform variables. ...

IoT device containers need TLS certificates to authenticate with AWS IoT Core. The certificate path is the critical configuration — if the container cannot find its credentials, it does not connect. For a runnable lab, see the terraform-docker-iot directory in the IaC repository. Certificate Injection Pattern Mount certificates from the host using Terraform volume mounts. Do not bake certs into the image: resource "docker_container" "iot_device" { image = docker_image.iot_device_image.name volumes { host_path = abspath("${path.module}/certs/root-CA.crt") container_path = "/certs/root-CA.crt" } volumes { host_path = abspath("${path.module}/certs/iot-thing.cert.pem") container_path = "/certs/iot-thing.cert.pem" } volumes { host_path = abspath("${path.module}/certs/iot-thing.private.key") container_path = "/certs/iot-thing.private.key" } } abspath(path.module) resolves the relative cert path to an absolute path relative to the Terraform module directory. This avoids path ambiguity when Terraform runs from different working directories. ...

Kafka labs are good at exposing the difference between a container being started and a broker being usable. Terraform can create the Docker network, broker container, application image, and topics, but it needs an explicit readiness boundary. Without that boundary, the next resource may try to create topics or start a processor before Kafka is listening. Readiness Boundary For a local lab, a simple port check is often enough to avoid racing the broker startup: ...

A local SLI lab is useful when the goal is to understand the signal path before introducing production platform complexity. For a live local demo, see the sli_app lab in the IaC repository. If the lab does not run as expected, open a bug fix request against that repository with the failing command, host OS, Docker version, Terraform version, and relevant logs. The important part is not that everything runs on one machine. The important part is that the lab has the same basic observability chain operators rely on later: ...

Local infrastructure labs often start with hardcoded passwords, localhost endpoints, and convenience tokens. That is normal for learning, but dangerous when the lab pattern becomes a production pattern without review. The useful distinction is not “lab bad, production good.” The useful distinction is knowing which shortcuts are temporary and what must change before the pattern is reused. Common Lab Shortcuts Terraform-managed Docker labs often include: Grafana admin credentials in container environment variables. Concourse local users such as admin:admin. Vault dev server tokens in shell environment files. database passwords pulled into Terraform state. generated private keys written to local files. privileged containers for CI workers or system exporters. localhost endpoints that assume a single operator workstation. Each shortcut may be acceptable in a disposable lab. None should cross into shared infrastructure by accident. ...

Remote state has a chicken-and-egg problem: Terraform needs somewhere to store state, but the storage account and container may also be managed by Terraform. The clean approach is to treat backend bootstrapping as a short, explicit phase. Create the state storage resources first, migrate state intentionally, then use the remote backend for the rest of the infrastructure. Target Shape For Azure Blob Storage, the backend needs: a resource group. a storage account. a private blob container. a stable state key per root module or environment. Example backend shape: ...