Configuration and Working Directories

Scenario: Terraform reports that no configuration exists because the command ran one directory above the intended root module.

A root module is the collection of .tf and .tf.json files in one working directory. Terraform loads them together; filenames and textual order do not define execution order. .terraform/ contains initialized dependencies and backend metadata, while .terraform.lock.hcl records provider selections. Keep generated plans, crash logs, state, and .terraform/ out of version control; commit configuration and the dependency lock file.

Analogy: A root module is a compiled project: several source files become one program, and the build cache is not source code.

A worked configuration

terraform {
  required_providers {
    fakecloud = {
      source  = "shellgenius/fakecloud"
      version = "~> 1.0"
    }
  }
}

Good repositories make execution boundaries obvious. Separate roots prevent an innocent plan for one service from loading state for an entire estate. README files should state backend, required credentials, ownership, and the exact workflow.

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-version-lockfile Terraform lab. Open /labs/terraform and choose slug tf-version-lockfile; the lab runs real Terraform against the offline FakeCloud provider.