Explanation
The persistent data stored in the backend belongs to a workspace. Initially, the backend has only one
workspace, called “default”, and thus there is only one Terraform state associated with that configuration.

Explanation
If a resource successfully creates but fails during provisioning, Terraform will error and mark the resource as
“tainted”. A resource that is tainted has been physically created, but can’t be considered safe to use since
provisioning failed. Terraform also does not automatically roll back and destroy the resource during the apply
when the failure happens, because that would go against the execution plan: the execution plan would’ve said a
resource will be created, but does not say it will ever be deleted.

Explanation
Terraform is built on a plugin-based architecture. All providers and provisioners that are used in Terraform
configurations are plugins, even the core types such as AWS and Heroku. Users of Terraform are able to write
new plugins in order to support new functionality in Terraform.

The Terraform language will automatically convert number and bool values to string values when needed, and vice-versa as long as the string contains a valid representation of a number or boolean value.
Example
* true converts to “true”, and vice-versa
* false converts to “false”, and vice-versa
* 15 converts to “15”, and vice-versa
Where possible, Terraform automatically converts values from one type to another in order to produce the expected type. If this isn’t possible, Terraform will produce a type mismatch error and you must update the configuration with a more suitable expression.
https://www.terraform.io/docs/configuration/expressions.html#type-conversion

terraform workspace list
The command will list all existing workspaces.
Reference: https://www.terraform.io/docs/cli/commands/workspace/list.html

Explanation
Terraform Cloud always encrypts state at rest and protects it with TLS in transit. Terraform Cloud also knows
the identity of the user requesting state and maintains a history of state changes. This can be used to control
access and track activity. Terraform Enterprise also supports detailed audit logging.
https://www.terraform.io/docs/state/sensitive-data.html#recommendations

Explanation
https://www.terraform.io/docs/provisioners/index.html

Explanation
“You can use terraform state rm in the less common situation where you wish to remove a binding to an
existing remote object without first destroying it, which will effectively make Terraform “forget” the object
while it continues to exist in the remote system.” https://www.terraform.io/cli/commands/state/rm

Explanation
For small infrastructures, Terraform can query your providers and sync the latest attributes from all your resources. This is the default behavior of Terraform: for every plan and apply, Terraform will sync all resources in your state.
For larger infrastructures, querying every resource is too slow. Many cloud providers do not provide APIs to query multiple resources at once, and the round trip time for each resource is hundreds of milliseconds. On top of this, cloud providers almost always have API rate limiting so Terraform can only request a certain number of resources in a period of time. Larger users of Terraform make heavy use of the -refresh=false flag as well as the -target flag in order to work around this. In these scenarios, the cached state is treated as the record of truth.
https://www.terraform.io/docs/state/purpose.html

Explanation
By default, Terraform will clone and use the default branch (referenced by HEAD) in the selected repository.
You can override this using the ref argument:
module “vpc” {
source = “git::https://example.com/vpc.git?ref=v1.2.0”
}
The value of the ref argument can be any reference that would be accepted by the git checkout command, including branch and tag names.
https://www.terraform.io/docs/modules/sources.html

Explanation
Command: force-unlock
Manually unlock the state for the defined configuration.
This will not modify your infrastructure. This command removes the lock on the state for the current configuration. The behavior of this lock is dependent on the backend being used. Local state files cannot be unlocked by another process.
https://www.terraform.io/docs/commands/force-unlock.html
https://www.terraform.io/docs/state/locking.html
Terraform has a force-unlock command to manually unlock the state if unlocking failed.
If you unlock the state when someone else is holding the lock it could cause multiple writers. Force unlock should only be used to unlock your own lock in the situation where automatic unlocking failed.

thelocalfiledatasource

Explanation
Import will find the existing resource from ID and import it into your Terraform state at the given ADDRESS.
ADDRESS must be a valid resource address. Because any resource address is valid, the import command can import resources into modules as well directly into the root of your state.
Terraform is able to import existing infrastructure. This allows us take resources we’ve created by some other means (i.e. via console) and bring it under Terraform management.
This is a great way to slowly transition infrastructure to Terraform.
The terraform import command is used to import existing infrastructure.
To import a resource, first write a resource block for it in our configuration, establishing the name by which it will be known to Terraform. For example:
resource “aws_instance” “import_example” {
# …instance configuration…
}
Now terraform import can be run to attach an existing instance to this resource configuration:
$ terraform import aws_instance.import_example i-03efafa258104165f
aws_instance.import_example: Importing from ID “i-03efafa258104165f”…
aws_instance.import_example: Import complete!
Imported aws_instance (ID: i-03efafa258104165f)
aws_instance.import_example: Refreshing state… (ID: i-03efafa258104165f) Import successful!
The resources that were imported are shown above. These resources are now in your Terraform state and will henceforth be managed by Terraform.
This command locates the AWS instance with ID i-03efafa258104165f (which has been created outside Terraform) and attaches its existing settings, as described by the EC2 API, to the name aws_instance.import_example in the Terraform state.
As a result of the above command, the resource is recorded in the state file. We can now run terraform plan to see how the configuration compares to the imported resource, and make any adjustments to the configuration to align with the current (or desired) state of the imported object.
https://www.terraform.io/docs/commands/import.html

Explanation
If a creation-time provisioner fails, the resource is marked as tainted. A tainted resource will be planned for destruction and recreation upon the next terraform apply. Terraform does this because a failed provisioner can leave a resource in a semi-configured state. Because Terraform cannot reason about what the provisioner does, the only way to ensure proper creation of a resource is to recreate it. This is tainting.
You can change this behavior by setting the on_failure attribute, which is covered in detail below.
https://www.terraform.io/docs/provisioners/index.html#creation-time-provisioners
https://www.terraform.io/docs/provisioners/index.html#destroy-time-provisioners
https://www.terraform.io/docs/provisioners/index.html#failure-behavior

Implicit dependency works only if there is some reference of one resource to another. Explicit dependency is the option here.

Outputs can be marked as containing sensitive material by setting the sensitive attribute to true, like this:
output “sensitive” {
sensitive = true
value = VALUE
}
When outputs are displayed on-screen following a terraform apply or terraform refresh, sensitive outputs are redacted, with <sensitive> displayed in place of their value.
Limitations of Sensitive Outputs
The values of sensitive outputs are still stored in the Terraform state, and available using the terraform output command, so cannot be relied on as a sole means of protecting values.
Sensitivity is not tracked internally, so if the output is interpolated in another module into a resource, the value will be displayed.

Explanation
tonumber and tostring are Type Conversion function
https://www.terraform.io/docs/configuration/functions.html

State is a necessary requirement for Terraform to function. It is often asked if it is possible for Terraform to work without state, or for Terraform to not use state and just inspect cloud resources on every run.
Purpose of Terraform State
State is a necessary requirement for Terraform to function. It is often asked if it is possible for Terraform to work without state, or for Terraform to not use state and just inspect cloud resources on every run. This page will help explain why Terraform state is required.
As you’ll see from the reasons below, state is required. And in the scenarios where Terraform may be able to get away without state, doing so would require shifting massive amounts of complexity from one place (state) to another place (the replacement concept).
1. Mapping to the Real World
Terraform requires some sort of database to map Terraform config to the real world. When you have a resource resource “aws_instance” “foo” in your configuration, Terraform uses this map to know that instance i- abcd1234 is represented by that resource.
For some providers like AWS, Terraform could theoretically use something like AWS tags. Early prototypes of Terraform actually had no state files and used this method. However, we quickly ran into problems. The first major issue was a simple one: not all resources support tags, and not all cloud providers support tags.
Therefore, for mapping configuration to resources in the real world, Terraform uses its own state structure.
2. Metadata
Alongside the mappings between resources and remote objects, Terraform must also track metadata such as resource dependencies.
Terraform typically uses the configuration to determine dependency order. However, when you delete a resource from a Terraform configuration, Terraform must know how to delete that resource. Terraform can see that a mapping exists for a resource not in your configuration and plan to destroy. However, since the configuration no longer exists, the order cannot be determined from the configuration alone.
To ensure correct operation, Terraform retains a copy of the most recent set of dependencies within the state. Now Terraform can still determine the correct order for destruction from the state when you delete one or more items from the configuration.
One way to avoid this would be for Terraform to know a required ordering between resource types. For example, Terraform could know that servers must be deleted before the subnets they are a part of. The complexity for this approach quickly explodes, however: in addition to Terraform having to understand the ordering semantics of every resource for every cloud, Terraform must also understand the ordering across providers.
Terraform also stores other metadata for similar reasons, such as a pointer to the provider configuration that was most recently used with the resource in situations where multiple aliased providers are present.
3. Performance
In addition to basic mapping, Terraform stores a cache of the attribute values for all resources in the state. This is the most optional feature of Terraform state and is done only as a performance improvement.
When running a terraform plan, Terraform must know the current state of resources in order to effectively determine the changes that it needs to make to reach your desired configuration.
For small infrastructures, Terraform can query your providers and sync the latest attributes from all your resources. This is the default behavior of Terraform: for every plan and apply, Terraform will sync all resources in your state.
For larger infrastructures, querying every resource is too slow. Many cloud providers do not provide APIs to query multiple resources at once, and the round trip time for each resource is hundreds of milliseconds. On top of this, cloud providers almost always have API rate limiting so Terraform can only request a certain number of resources in a period of time. Larger users of Terraform make heavy use of the -refresh=false flag as well as the -target flag in order to work around this. In these scenarios, the cached state is treated as the record of truth.
4. Syncing
In the default configuration, Terraform stores the state in a file in the current working directory where Terraform was run. This is okay for getting started, but when using Terraform in a team it is important for everyone to be working with the same state so that operations will be applied to the same remote objects.
Remote state is the recommended solution to this problem. With a fully-featured state backend, Terraform can use remote locking as a measure to avoid two or more different users accidentally running Terraform at the same time, and thus ensure that each Terraform run begins with the most recent updated state.

https://www.terraform.io/docs/configuration/variables.html

Explanation
https://docs.hashicorp.com/sentinel/intro/what
https://medium.com/hashicorp-engineering/enforcing-aws-s3-security-best-practice-using-terraform-sentinel-ddc

Explanation
Manually unlock the state for the defined configuration.
Reference: https://www.terraform.io/docs/cli/commands/force-unlock.html