kb/state

Terraform state: what is inside, why it is risky

Terraform state is the snapshot of what is against the HCL of what should be. Local state (terraform.tfstate), remote backends (S3, GCS, Terraform Cloud), sensitive outputs, drift and refresh. State is the most sensitive part of a terraform project, and protecting it decides everything.

tf-state-importImport: bringing an existing resource under Terraform management
Import means: this resource already exists in the cloud; start managing it. The old way: `terraform import <address> <cloud_id>`, and you write the HCL yourself. The new way (TF 1.5+): an `import` block directly in HCL. Plan shows what will happen; apply commits it. Import does not write HCL for you. That is your job.
tf-remote-backend-s3Remote state in S3: bucket, DynamoDB lock, encryption
S3 backend stores `terraform.tfstate` in a bucket. A DynamoDB table provides locking so only one apply runs at a time. Configuration goes in the `backend "s3"` block inside `terraform { ... }`. State lives in S3. It is the single source of truth; there is no local file anymore. Migrate from local to S3 with `terraform init -migrate-state`.
tf-state-manipulationstate mv, state rm, state pull/push: manual operations
`terraform state mv` renames a resource address in state without destroy/recreate. `terraform state rm` removes a resource from state but not from the cloud. `terraform state pull/push` downloads or uploads state as a file. All four are sharp operations; do them with a backup and a clear reason. For declarative alternatives, see [[tf-moved-block]] and [[tf-removed-block]].
tf-stateState: Terraform's memory of what it created
State is the JSON file `terraform.tfstate` where Terraform records what it created in the cloud. Without it, Terraform would have no way to tell which bucket is "its own" and which belongs to something else. The file holds resource IDs, all attributes, and often secrets. It is the most sensitive part of any project.

kb/state

Terraform state: what is inside, why it is risky

tf-state-importImport: bringing an existing resource under Terraform management
Import means: this resource already exists in the cloud; start managing it. The old way: `terraform import <address> <cloud_id>`, and you write the HCL yourself. The new way (TF 1.5+): an `import` block directly in HCL. Plan shows what will happen; apply commits it. Import does not write HCL for you. That is your job.
tf-remote-backend-s3Remote state in S3: bucket, DynamoDB lock, encryption
S3 backend stores `terraform.tfstate` in a bucket. A DynamoDB table provides locking so only one apply runs at a time. Configuration goes in the `backend "s3"` block inside `terraform { ... }`. State lives in S3. It is the single source of truth; there is no local file anymore. Migrate from local to S3 with `terraform init -migrate-state`.
tf-state-manipulationstate mv, state rm, state pull/push: manual operations
`terraform state mv` renames a resource address in state without destroy/recreate. `terraform state rm` removes a resource from state but not from the cloud. `terraform state pull/push` downloads or uploads state as a file. All four are sharp operations; do them with a backup and a clear reason. For declarative alternatives, see [[tf-moved-block]] and [[tf-removed-block]].
tf-stateState: Terraform's memory of what it created
State is the JSON file `terraform.tfstate` where Terraform records what it created in the cloud. Without it, Terraform would have no way to tell which bucket is "its own" and which belongs to something else. The file holds resource IDs, all attributes, and often secrets. It is the most sensitive part of any project.