= Chapter 3: How to Manage Terraform State
== what is?
  * terraform.tfsate JSON file
  * output **terraform plan** is a "diff" with **terraform.tfstate**
  * state file is a private API, for internal use of terraform and can change in any moment
    * to modify, **terraform import** and **terraform state**
  * share state in workgroups
    * shared location
      * not good idea to share in a git (manual errors, forget commit last update, no-locking, secrets exposed, etc)
      * local backend VS remote backend (supported by Amazon S3, Azure Storage, Google Cloud Storage, Hashicorp's Terraform Cloud)
    * locked
      * **-lock-timeout=10m** waits for locked state to relaunch command
    * isolation (big structures, environments)
  * terraform backends limitations
    * chicken-and-egg situation (create local backend to create the instrastructure needed for remote backend)
    * no variables or references in backend block (copy-and-paste in all projects)
      * be aware to use unique "key" (paths) to store terraform.tfstate of every project
      * use **backend.hcl** for fixed information in backend block and **backend.tf** for variable informacion (like path), and ''terraform init -backend-config=backend.hcl''
      * use **terragrunt**
  * Isolating State Files
    * separate by environment
      * what happens when terraform brokes: [[https://charity.wtf/2016/03/30/terraform-vpc-and-why-you-want-a-tfstate-file-per-env/
]]
    * by workspaces
      * ''terraform workspace show''
      * ''terraform workspace new <NAME>''
      * ''terraform workspace list''
      * ''terraform workspace select <NAME>''
      * variables
        * ''terraform.workspace''
      * drawbacks((inconvenientes)):
        * all state files (for each workspace) are in the same backend -> same crendentials/authentication
        * workspaces are not visible in the code, more dificult to have a global point of view
        * human errors applying changes on the incorrect workspace
    * by Isolation via File Layout