README.md

what if you delete remote backend from terraform

If you delete remote backend configuration from Terraform code and run terraform apply , it will detect backend change and throw an error. You need to reinitialize Terraform again, and it will prompt you to migrate existing remote state to the local backend so that it can still manage resources managed by the remote state.

terraform locking state

Image source - Internet Why state locking? Storing the state remotely lets you collaborate smoothly. It allows each of your team members to access the latest state files, but it also brings a risk of accidental state file corruption, especially when two team members are running Terraform at the same time you may run into race conditions as multiple terraform apply commands make concurrent updates to the same state files, leading to conflicts and data loss, and state file corruption. State lock, a feature that prevents opening a state file while already in use, will resolve this problem. Please note that not all backends support locking. If your backend supports it and is enabled, Terraform will lock your state for all operations that could write state. This prevents others from acquiring the lock and potentially corrupting your state. NOTE: Not all backends support locking. Please view the list of backend types for details on whether a backend supports locking or not. You can implement the lock by creating an AWS DynamoDB Table. Image source - Internet To use DynamoDB for locking with Terraform, you must create a DynamoDB table with a primary key called LockID with this exact spelling and capitalization. Here’s what the sample backend configuration looks like for an S3 backend with state lock: ``` terraform { backend "s3" { # Replace this with your bucket name. bucket = "quiz-experts-terraform-bucket" key = "global/quiz-experts/stats/terraform.tfstate" region = "us-east-2" # Replace this with your DynamoDB table name. dynamodb_table = "quiz-experts-terraform-locks" encrypt = true } } ``` Remember to run terraform init again after making any change in the remote backend configuration. This command can not only download provider code, but also configure your Terraform backend. Moreover, the init command is idempotent, so it’s safe to run it over and over again.

🌟🌟🌟

state migration

Whenever a configuration's backend changes, you must run terraform init again to validate and configure the backend before you can perform any plans, applies, or state operations. Re-running init with an already-initialized backend will update the working directory to use the new backend settings. Either -reconfigure or -migrate-state must be supplied to update the backend configuration.

When changing backends, Terraform will give you the option to migrate your state to the new backend. This lets you adopt backends without losing any existing state.

🌟🌟🌟

most secure place to store credentials when using a remote backend

Anytime you can configure these credentials outside of Terraform is your best choice. Environment variables would be the second most-secure choice here. The primary focus is to ensure your credentials are not stored in plaintext and committed to a code repository. NOTE: You could use an encrypted file to store credentials and that encrypted file could be accessed by Terraform to read the creds.