kb/state
State, снапшот «как есть» против HCL «как должно». Локальный state (terraform.tfstate), remote backends (S3, GCS, Terraform Cloud), sensitive-выходы, drift и refresh. State, самая чувствительная часть terraform-проекта, её защита определяет всё.
S3-backend хранит `terraform.tfstate` в бакете, DynamoDB-таблица даёт блокировку одного-apply-за-раз. Конфигурация, в блоке `backend "s3"` внутри `terraform { ... }`. State в S3. Это единственный source of truth, локального файла больше нет. Переезд с local на S3, через `terraform init -migrate-state`.
`terraform state mv` переименовывает адрес ресурса в state (без destroy/recreate). `terraform state rm` убирает ресурс из state (но не из облака). `terraform state pull/push`, скачать/залить state как файл. Все четыре, резкие операции, делать через backup и понимая зачем. Для декларативных альтернатив есть [[tf-moved-block]] и [[tf-removed-block]].
State. JSON-файл terraform.tfstate, где Terraform записывает, что он создал в облаке. Без него Terraform не знал бы, какой бакет «его», а какой чужой. Содержит ID ресурсов, все атрибуты, и часто секреты. Самая чувствительная часть проекта.
Импорт = «этот ресурс уже создан в облаке, начни им управлять». Старый способ: `terraform import <адрес> <cloud_id>`, ресурс в HCL надо написать руками. Новый (TF 1.5+): `import` блок прямо в HCL, plan показывает что будет, apply закрепляет. Импорт **не пишет HCL**, это твоя работа.