Not all Terraform backends are created equal. Some backends act like plain "remote disks" for state files; others support locking the state while operations are being performed, which helps prevent conflicts and inconsistencies.

Kubernetes, Consul, and S3 backends all support state locking. S3 supports state locking with the help of DynamoDB.

WRONG ANSWERS:

The etcd backend doesn't support state locking. While the local backend does support locking via system APIs, you can't use the local backend to share the state across your team.

https://www.terraform.io/language/settings/backends

This is true. When you create a new workspace using Terraform OSS/CLI using the terraform workspace new command, you will be working with a separate state file when working with that workspace. You can easily change between workspaces and their respective state file using the terraform workspace select command.

The same is true in Terraform Cloud/Enterprise. When you create a new workspace, you'll be working with a dedicated state file for that particular workspace. It doesn't share a state file with any other workspace.

https://www.terraform.io/cli/workspaces#the-purpose-of-workspaces

https://www.terraform.io/cli/workspaces#interactions-with-terraform-cloud-workspaces

For a collection type such as alist, the provided values are referenced using an index that starts with [0]. In this case, the strings would be represented as such:

[0] = vault

[1] = consul

[2] = terraform

[3] = boundary

[4] = nomad

When referencing a variable that contains a list, you reference it almost identically to a regular variable, except you just add the index on the end of the variable. So for terraform, it would simply be var.products[2].

WRONG ANSWERS:

var.products[3] = actually equals boundary since an index starts with 0

var.list.products[2] = this isn't a valid way to reference a variable in Terraform

var.default.products["terraform"] = this isn't a valid way to reference a list variable in Terraform. If you remove the default from the answer, it could be a valid option if the variable was of type map, though.

https://www.terraform.io/language/values/variables

The terraform init command performs several different initialization steps in order to prepare the current working directory for use with Terraform. Some of these steps include downloading any referenced providers (like AWS, Azure, GCP, etc.), caching the source code for modules in the local directory so they can be used, and other steps to prepare the working directory to be used with Terraform.

Note that there are quite a few options that you can use with terraform init to perform operations that you might need when using Terraform. These operations might include state migrations or upgrading providers.

WRONG ANSWERS:

terraform init does NOT create a sample Terraform configuration file. Actually, I don't know if there are any native Terraform commands that will create a .tf file for you.

You can run terraform init over and over again and it will not change/modify your state file.

https://www.terraform.io/cli/commands/init

https://learn.hashicorp.com/collections/terraform/aws-get-started

Some backends allow providing access credentials directly as part of the configuration for use in unusual situations, for pragmatic reasons. However, in normal use, HashiCorp does not recommend including access credentials as part of the backend configuration. Instead, leave those arguments completely unset and provide credentials via the credentials files or environment variables that are conventional for the target system, as described in the documentation for each backend.

WRONG ANSWERS:

Use a variable? Well, you could use a variable but that wouldn't really improve security here, since variable defaults or configurations are also stored in plaintext.

On the remote system? I don't think this is even a viable option. The creds would need to be read by the local system that is executing Terraform.

https://www.terraform.io/language/settings/backends/configuration

State locking prevents others from acquiring the lock and potentially corrupting your state. If Terraform didn't use state locking, multiple people could try to make changes to your infrastructure and corrupt the state file. At that point, Terraform would no longer understand how to manage the resources deployed since the state file wouldn't be consistent.

State locking happens automatically on all operations that could write state. You won't see any message that it is happening. If state locking fails, Terraform will not continue.

WRONG ANSWERS:

Committing code? State locking wouldn't prevent somebody from committing code to your code repository.

Moving the state file!..Even after you run your first terraform apply, you can move the state file by modifying your state block and running a terraform init. State locking does not prevent you from moving state in the future.

Changing Infrastructure Even with state locking, somebody could make manual changes to your infrastructure using the API, CLI, or console if they wanted to. State locking doesn't prevent this.

https://www.terraform.io/language/state/locking

https://www.terraform.io/language/state

To configure each provider, you need to define a provider block and provide the configuration within that block. You would need to do this for each provider that you need to configure. For example, if you needed to customize the aws, gcp, and vault provider, you'd need to create three separate provider blocks, one for each provider.

Don't forget that configurations for a provider go inside of a provider block, but any provider constraints go inside of the terraform --> required_providers block.

https://www.terraform.io/language/providers

https://www.terraform.io/language/providers/configuration#provider-configuration-1

The terraform destroy command is a convenient way to destroy all remote objects managed by a particular Terraform configuration.

While you will typically not want to destroy long-lived objects in a production environment, Terraform is sometimes used to manage ephemeral infrastructure for development purposes, in which case you can use terraform destroy to conveniently clean up all of those temporary objects once you are finished with your work.

This command is just a convenience alias for the following command:

terraform apply -destroy

For that reason, this command accepts most of the options that terraform apply accepts, although it does not accept a plan file argument and forces the selection of the "destroy" planning mode.

WRONG ANSWERS:

While terraform plan -destroy is a valid command, it only creates a speculative destroy plan to see what the effect of destroying would be

terraform apply -delete is not a valid Terraform command

https://www.terraform.io/cli/commands/destroy

Using interpolation, you can reference the output of an exported value by using the following syntax: module.<module name>.<output name>

Don't forget that before you can reference data/values from a module, the module has to have an output declared that references the desired value(s).

WRONG ANSWERS:

None of the wrong answers are valid interpolation syntax to reference an output that originates from a module.

https://www.terraform.io/language/modules/syntax#accessing-module-output-values

https://learn.hashicorp.com/collections/terraform/modules

Terraform workspaces (OSS) allow you to create a new workspace to execute the same Terraform but with a different state file. This feature will enable you to run the same Terraform with different configurations without modifying Terraform code or impacting any existing workspaces. Terraform states out with the default workspace, and that's the workspace you are using unless you create and switch to a new workspace.

IMPORTANT - PLEASE READ:

Remember that Terraform Cloud and Enterprise also have Workspaces, but they behave slightly differently. In Cloud and Ent, each workspace is still isolated from others, meaning it has its own state. Still, often these workspaces point to different code repositories and use completely different Terraform configuration files.

To create a new workspace, you'd run:

$ terraform workspace new btk

Created and switched to workspace "btk"!

You're now on a new, empty workspace. Workspaces isolate their state, so if you run "terraform plan" Terraform will not see any existing state for this configuration.

To list all of the existing workspaces, you can run (note the * indicates the workspace you are using):

$ terraform workspace list

default*

btk

bryan-dev

temp-workspace

WRONG ANSWER:

When using workspaces, you're essentially using the same Terraform configuration files. Therefore the backend will remain the same for all of your workspaces. That makes this answer incorrect.

https://www.terraform.io/language/state/workspaces

https://www.terraform.io/cli/commands/workspace/list

https://www.terraform.io/cli/commands/workspace/new