Terraform in the IaC Landscape

Scenario: A team uses cloud-native templates, configuration management, and Terraform, then argues that only one tool should survive.

Terraform is provider-based and service-agnostic: one workflow can manage public clouds, SaaS, DNS, certificates, source-control settings, and on-prem APIs. Cloud-native tools can expose new platform features sooner; configuration-management tools excel at changing operating systems after machines exist. Terraform usually owns resource lifecycle and relationships, while image baking, cloud-init, Ansible, or Kubernetes owns software configuration. Multi-cloud capability means a common workflow—not that providers expose identical abstractions.

Analogy: Terraform is a general contractor coordinating specialist trades. It does not pretend plumbing and electrical work are identical; providers translate the shared plan into specialist operations.

A worked configuration

resource "fakecloud_server" "api" {
  name       = "api-01"
  network_id = fakecloud_network.app.id
}

resource "fakecloud_certificate" "edge" {
  common_name = "api.example.test"
}

A useful boundary is ownership: one system should be authoritative for a given object. If Terraform and a console automation both modify the same field, perpetual drift follows. Pick the tool whose lifecycle model matches the object, then document the handoff.

Note: Treat the plan as a change contract: understand every create, update, replacement, and destroy before approving it.

Goal: Reinforce this lesson in the tf-dependency-ordering Terraform lab. Open /labs/terraform and choose slug tf-dependency-ordering; the lab runs real Terraform against the offline FakeCloud provider.