The cool part about providers is that anybody can write or contribute to them. This includes individuals would just want to contribute to open-source projects, manufacturers/platform vendors that want to ensure providers are up to date, or HashiCorp themselves. If you find that a provider doesn't provide the capabilities you need, you can develop the new capabilities and submit a PR for review. If approved, those changes would now become part of the Terraform provider that millions of people could use. Pretty cool!

Wrong Answer:

Providers are treated as plugins for Terraform, and during a terraform init process, the required providers are downloaded to the local machine that is executing Terraform so they can be used. Therefore, not all providers are included with Terraform when you download the latest version from terraform.io.

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

https://www.terraform.io/docs/extend/how-terraform-works.html

Terraform enables its users to interact with a platform's API without requiring the end-user to understand individual APIs for the targeted platform. This allows a user to easily provision and manage resources across many different platforms without having to understand the API for each individual backend. This benefit makes users more efficient and reduces the administrative burden for understanding and troubleshooting each one.

Terraform can support any platform that has an API, including public, private, and other offerings on the market today. If it has an API, a provider can be written to allow Terraform to manage it. Don't believe me? Check out the Spotify or Domino's Pizza Terraform provider :)

Lastly, by using providers, HashiCorp can enable the extensibility of Terraform without having to modify Terraform core for each supported platform. Each provider, or plugin, can be downloaded as needed to extend the functionality of Terraform itself.

Wrong Answer:

Now, while Terraform can help you standardize security configurations and settings across multiple clouds, it won't enforce it outside of your terraform apply. In other words, it doesn't act like a configuration management tool that can constantly watch for changes to change the configuration back to the desired state.

https://www.terraform.io/intro/use-cases

https://www.terraform.io/intro

terraform import can be used to import resources into Terraform so they can be managed by Terraform moving forward. Any resources that are imported will be added to Terraform state so they can be managed like any other resource. Before you can use the terraform import command, you MUST develop the resource block for the resource that will be imported. For example, if you are planning to import an Azure virtual machine, you must add an azurerm_virtual_machine block with the proper configurations.

When you run the terraform import command, you will need to reference the resource address - like azure_virtual_machine.web-server - and the resource ID - like the ID of the virtual machine in Azure - as the two required parameters.

terraform import azurerm_virtual_machine.web-server 090556DA-D4FA-764F-A9F1-63614EDA019A

WRONG ANSWER:

IMPORTANT - terraform import will NOT create the resource block for you. You must create the resource block in your Terraform configuration before using the import command

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

https://www.terraform.io/cli/import

https://www.terraform.io/cli/import/usage

There's a lot to this question, but the reasoning is pretty basic. Since a resource was manually changed, it means that Terraform state is no longer accurate. However, before a terraform plan or terraform apply is executed, Terraform refreshes its state to ensure it knows the status of all its managed resources. During this process, Terraform would recognize the change, update state, and compare that to the new configuration file. Assuming the change defined in the configuration is identical to the manual change, Terraform would simply apply any changes (if any), update the state file, and complete the terraform apply.

WRONG ANSWERS:

Change the resource back? Terraform relies on state for everything and any changes are a result of comparing the current state of the resource to the desired configuration (the .tf files). Therefore, Terraform won't revert the resource back to the original configuration because the configuration has been updated for the new change, and that's the desired state.

Return an Error? Since Terraform performs a state refresh before executing a plan or apply, Terraform will recognize any configuration changes and then apply any changes. This will not result in an error being returned.

Will Terraform destroy my resources? It won't destroy the resource since the resource is still defined in the configuration file. The only way that TF would destroy your resource is if you actually remove that resource from your configuration file(s).

https://www.terraform.io/intro/core-workflow

https://learn.hashicorp.com/tutorials/terraform/resource-drift?in=terraform/state

https://learn.hashicorp.com/tutorials/terraform/resource-lifecycle?in=terraform/state

When working with outputs, you need to determine where the value will be coming from and work your way backward from there. For example, if the resource was created inside of a module, then the module will require an output block to export that value. That said, output blocks that are created in a module aren't displayed on the Terraform CLI. Therefore, you need to create an output block in the parent/calling module to output the value while referencing the output in the module. Because of this, the correct answer requires you to create an output in the parent module and reference the output value from the module.

WRONG ANSWERS:

********************

Add the following code to the web module:

output "website" {

 description = "Outputs the URL of the provisioned website"

 value      = "https://${aws_instance.web.public_dns}:8080/index.html"

}

While this could be a way to get the proper URL, the output of a module wouldn't show up in the CLI output, therefore this is incorrect.

******************

Add the following code to the parent module:

output "website" {

 description = "Outputs the URL of the provisioned website"

 value      = aws_instance.web.public_dns

}

The resource was created inside of the web module, therefore you wouldn't be able to access their attributes directly from the parent module, making this an incorrect answer.

******************

Add the following code to the web module:

output "website" {

 description = "Outputs the URL of the provisioned website"

 value      = module.web.public_dns

}

Even if you could output the value from a module to the CLI, the resource ID for the module is incorrect because it is referring to another module, making this answer incorrect.

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

When you need to constrain the provider to a specific version, you would do this under the terraform configuration block. Within that block, you would use the required_providers block to set certain configurations, including the version of each provider you want to lockdown.

Note that even though you would add the provider constraint under the terraform block, you may still indeed have a separate provider block to set certain configurations, like credentials, regions, or other settings specific to the provider. Just keep in mind that each distinct block is used for different settings.

Example:

Set the version of the Azure provider:

terraform {

 required_providers {

   azurerm = {

     source = "hashicorp/azurerm"

     version = "2.90.0"

   }

 }

}

Configure settings for the Azure provider:

provider "azurerm" {

 features {}

}

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

https://www.terraform.io/language/providers/requirements#version-constraints

Ok, so there's a lot to unpack for this question here. First, let's talk about the correct answer. Modules can be called one or more times by a parent module. The configuration file/module that calls a module is often called the parent, root,or calling module. The module that is called is the child module, or sometimes just "module". The whole point of using a module is to be able to call it one or many times to create resources without having to rewrite the same code over and over.

WRONG ANSWERS:

Where do modules live? While modules can be published to the Terraform module registry, they don't have to be. They can be simply stored locally on your machine or in a private code repository. Publishing them to the public registry, or using a private module registry, is completely optional.

Module outputs: While modules are often more valuable when they output values, they don't necessarily have to output values. They can be used to simply manage resources. If you do need values from the module, that's when you'd create outputs. Those outputs can be used just for informational purposes or they can be used as inputs for other modules. For example, you might create a subnet in a public cloud in one module and need to output the subnet ID so you can use it as an input on a second module to deploy application workloads.

Resources in Modules: Modules can be used to deploy and manage one or more resources within the module. For example, you might need to deploy multiple resources needs for a specific application or requirements.

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

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

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.

WRONG ANSWERS:

None of the wrong answers would allow you to migrate state. They are simply other CLI commands that are commonly used with Terraform.

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

https://www.terraform.io/cli/commands/init#backend-initialization

Terraform has detailed logs which can be enabled by setting the TF_LOG environment variable to any value. This will cause detailed logs to appear on stderr.

You can set TF_LOG to one of the log levels TRACE, DEBUG, INFO, WARN or ERROR to change the verbosity of the logs.

WRONG ANSWERS:

None of the incorrect answers are valid environment variables that you can use to configure Terraform logs.

https://www.terraform.io/internals/debugging

https://www.terraform.io/cli/config/environment-variables#tf_log

Backends are configured with a nested backend block within the top-level terraform block. There are some important limitations on backend configuration:

 * A configuration can only provide one backend block.

 * A backend block cannot refer to named values (like input variables, locals, or data source attributes).

WRONG ANSWERS:

None of the wrong answers are correct, since the state is ONLY configured inside of the terraform block.

https://www.terraform.io/language/settings/backends/configuration#using-a-backend-block