Workspaces are similar concepts in all versions of Terraform, although they behave differently depending on the platform they are being used on.

https://www.terraform.io/docs/cloud/workspaces/index.html

https://www.terraform.io/docs/state/workspaces.html

The terraform apply -refresh-only command is used to reconcile the state Terraform knows about (via its state file) with the real-world infrastructure. This can be used to detect any drift from the last-known state, and to update the state file.

https://learn.hashicorp.com/tutorials/terraform/refresh

Any values that are retrieved in a data block or referenced as variables will show up in the state file.

https://www.terraform.io/docs/state/sensitive-data.html

When you add a data block to your configuration, Terraform will retrieve all of the available data for that particular resource. It is then up to you to reference a specific attribute that can be exported from that data source. For example, if you include a data block for the aws_ami resource, Terraform will get a ton of attributes about that AMI that you can use elsewhere in your code - check out this link to see the list of attributes specific to the aws_ami, for example. https://registry.terraform.io/providers/hashicorp/aws/latest/docs/data-sources/ami#attributes-reference

Within the block body (between { and }) are query constraints defined by the data source. Most arguments in this section depend on the data source, and indeed in this example most_recent, owners and tags are all arguments defined specifically for the aws_ami data source.

https://www.terraform.io/docs/configuration/data-sources.html#using-data-sources

Terraform is designed to work with almost any infrastructure that provides an API. Terraform is very frequently used to provision infrastructure atop VMware infrastructure, along with traditional, physical security or infrastructure service solutions. Additional information can be found in this article referenced by the Exam Objective #1 - https://www.hashicorp.com/blog/infrastructure-as-code-in-a-private-or-public-cloud

To set lots of variables, it is more convenient to specify their values in a variable definitions file (with a filename ending in either .tfvars or .tfvars.json)

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

When using modules installed from a module registry, HashiCorp recommends explicitly constraining the acceptable version numbers to avoid unexpected or unwanted changes. The version argument accepts a version constraint string. Terraform will use the newest installed version of the module that meets the constraint; if no acceptable versions are installed, it will download the newest version that meets the constraint.

A version number that meets every applicable constraint is considered acceptable.

Terraform consults version constraints to determine whether it has acceptable versions of itself, any required provider plugins, and any required modules. For plugins and modules, it will use the newest installed version that meets the applicable constraints.

To test this, I ran a terraform init with the code as shown in the file:

1. $ terraform init
2. Initializing modules...
3. Downloading hashicorp/consul/aws 0.0.5 for consul...
4. - consul in .terraform\modules\consul
5. - consul.consul_clients in .terraform\modules\consul\modules\consul-cluster
6. - consul.consul_clients.iam_policies in .terraform\modules\consul\modules\consul-iam-policies
7. - consul.consul_clients.security_group_rules in .terraform\modules\consul\modules\consul-security-group-rules
8. - consul.consul_servers in .terraform\modules\consul\modules\consul-cluster
9. - consul.consul_servers.iam_policies in .terraform\modules\consul\modules\consul-iam-policies
10. - consul.consul_servers.security_group_rules in .terraform\modules\consul\modules\consul-security-group-rules

Then I removed the constraint from the configuration file and ran a terraform init again:

1. $ terraform init
2. Initializing modules...
3.  
4. Initializing the backend...
5.  
6. Initializing provider plugins...
7. - Reusing previous version of hashicorp/aws from the dependency lock file
8. - Reusing previous version of hashicorp/template from the dependency lock file

Terraform did not download a newer version of the module. It reused the existing one.

https://www.terraform.io/docs/configuration/blocks/modules/syntax.html#version

https://www.terraform.io/docs/language/expressions/version-constraints.html

A local path must begin with either ./ or ../ to indicate that a local path is intended, to distinguish from a module registry address.

https://www.terraform.io/docs/modules/sources.html#terraform-registry

Modules on the public Terraform Registry can be referenced using a registry source address of the form <NAMESPACE>/<NAME>/<PROVIDER>, with each module's information page on the registry site including the exact address to use.

https://www.terraform.io/docs/modules/sources.html#terraform-registry

Terraform relies on plugins called "providers" to interact with remote systems.

Terraform configurations must declare which providers they require so that Terraform can install and use them. Additionally, some providers require configuration (like endpoint URLs or cloud regions) before they can be used.

https://www.terraform.io/docs/configuration/blocks/providers/index.html