A terraform apply will run its own state refresh and see the configuration matches the deployed infrastructure, so no changes will be made to the infrastructure.

WRONG ANSWERS:

Terraform will detect the drift and return an error - since terraform apply will refresh state, it will see that the configuration has changed and now meets the desired state, therefore it won't do anything.

the security group will be changed back to the original configuration - this won't happen because the Terraform configuration now states it should have the new port. If Terraform changed it back to the original configuration, the real-world resources would NOT match the desired state

the terraform apply command will require you to re-run the terraform plan command first - terraform plan is not a requirement of the terraform apply command, so this won't happen

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

The terraform workspace show command is used to output the current workspace.

WRONG ANSWERS:

terraform workspace new will create a new workspace

terraform workspace select will tell Terraform what workspace to change to and use

terraform workspace is just a container that requires additional subcommands

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

We can utilize Terraform provisioners to deploy a web app onto an instance we've created. In order to run these steps, Terraform needs a connection block along with our generated SSH key from the previous labs in order to authenticate into our instance. Terraform can utilize both the `local-exec` provisioner to run commands on our local workstation (that is executing Terraform) and the `remote-exec` provisioner to execute commands against a resource that has been provisioned with Terraform.

Note: Provisioners should only be used as a last resort. For most common situations there are better alternatives.

https://www.terraform.io/language/resources/provisioners/syntax

When you develop new Terraform code, and you're ready to test it out, the first thing you need to do is run terraform init in order to initialize the working directory and download any required providers or referenced modules. Even if you're in a directory that has some of these plugins, you should still run terraform init to make sure all the providers have been downloaded. You could even run a terraform init -upgrade to ensure you have the latest versions of the plugins that meet your requirements.

WRONG ANSWERS:

None of these commands would work if you haven't initialized the working directory yet. You would get an error similar to this:

│ Error: Could not load plugin

│

│

│ Plugin reinitialization required. Please run "terraform init".

│

│ Plugins are external binaries that Terraform uses to access and manipulate

│ resources. The configuration provided requires plugins which can't be located,

│ don't satisfy the version constraints, or are otherwise incompatible.

│

│ Terraform automatically discovers provider requirements from your

│ configuration, including providers used in child modules. To see the

│ requirements and constraints, run "terraform providers".

│

│ failed to instantiate provider "registry.terraform.io/hashicorp/aws" to obtain schema:

│ unknown provider "registry.terraform.io/hashicorp/aws"

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

Child modules can only access variables that are passed in the calling module block.

The resources defined in a module are encapsulated, so the calling module cannot access their attributes directly. However, the child module can declare output values to selectively export certain values to be accessed by the calling module.

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

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

As a fallback for the other ways of defining variables, Terraform searches the environment of its own process for environment variables named TF_VAR_ followed by the name of a declared variable.

WRONG ANSWERS:

None of the other environment variables shown as answers will successfully set a value for a Terraform variable.

https://www.terraform.io/language/values/variables#environment-variables

To upgrade an existing provider that you have already downloaded, you need to run terraform init -upgrade . This command will upgrade all previously-selected plugins to the newest version that complies with the configuration's version constraints. This will cause Terraform to ignore any selections recorded in the dependency lock file, and to take the newest available version matching the configured version constraints.

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

The resources defined in a module are encapsulated, so the calling module cannot access their attributes directly. However, the child module can declare output values to selectively export certain values to be accessed by the calling module.

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

A Terraform module (usually the root module of a configuration) can call other modules to include their resources into the configuration. A module that has been called by another module is often referred to as a child module.

Child modules can be called multiple times within the same configuration, and multiple configurations can use the same child module.

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

Workspaces in OSS are often used within the same working directory while workspaces in Enterprise/Cloud are often (but not required) mapped to unique repos.

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

https://www.terraform.io/cloud-docs/workspaces