Sentinel is an embedded policy-as-code framework integrated with the HashiCorp Enterprise products. It enables fine-grained, logic-based policy decisions, and can be extended to use information from external sources.

When using Sentinel policies to define and enforce policies, it (Sentinel) runs after a terraform plan, but before a terraform apply. Therefore, you can potentially reduce costs on public cloud resources by NOT deploying resources that do NOT conform to policies enforced by Sentinel. For example, without Sentinel, your dev group might deploy instances that are too large, or too many of them, by accident or just because they can. Rather than being REACTIVE and shutting them down after they have been deployed, which it would cost you $, you can use Sentinel to prevent those large resources from being deployed in the first place.

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

To specify the version of Terraform provider that is required, you need to use the required_providers block parameter under the terraform block. HashiCorp recommends that you explicitly set the version of both Terraform and the required providers/plugins to avoid issues when upgrading to the latest versions.

WRONG ANSWERS:

None of these wrong answers are valid configuration blocks for Terraform to set the specific version of Terraform.

https://www.terraform.io/language/settings#specifying-a-required-terraform-version

Single Sign-On is a feature of Terraform Enterprise and Terraform Cloud for Business. It is NOT available in Terraform Cloud (free tier)

https://www.hashicorp.com/products/terraform/pricing

One of the functions that a terraform init does for you is download any referenced modules/plugins so they can be used locally. This is required before you run most other terraform CLI commands.

WRONG ANSWERS:

 - ensures any configuration file that ends with a .tf file extension is syntactically valid and internally consistent - this is the job of terraform validate, not terraform init

 - ensures that all terraform files match the canonical formatting and style - this is done by the CLI command terraform fmt

 - compares the current configuration to the prior state and notes any differences - nope, that's what a terraform plan will do for you, not terraform init

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

The local-exec provisioner invokes a local executable after a resource is created. This invokes a process on the machine running Terraform, not on the resource.

WRONG ANSWERS:

A remote provisioner will execute a process on a remote resource, such as the resource created by Terraform.

The file provisioner is used to copy files or directories from the machine executing Terraform to the newly created resource.

https://www.terraform.io/language/resources/provisioners/local-exec

Terraform can indeed manage dependencies across multiple cloud providers. That is a huge benefit of using Terraform since it's cloud-agnostic, it doesn't care where the resources are deployed. It can still manage implicit or explicit dependencies between resources regardless of where they are deployed.

https://learn.hashicorp.com/tutorials/terraform/dependencies?in=terraform/0-13

Although Infrastructure as Code (IaC) tools allow you to programmatically deploy and manage your applications, it does NOT ensure that your applications have a reduced number of vulnerabilities. This security feature is not the responsibility of IaC, and you would need to pair IaC with another tool to scan your code to identify security vulnerabilities.

WRONG ANSWERS:

All of the wrong answers in this question are actually the primary use cases of Infrastructure as Code tools.

Infrastructure as code (IaC) tools allow you to manage infrastructure with configuration files rather than through a graphical user interface. IaC allows you to build, change, and manage your infrastructure in a safe, consistent, and repeatable way by defining resource configurations that you can version, reuse, and share.

https://learn.hashicorp.com/tutorials/terraform/infrastructure-as-code

Terraform must store state about your managed infrastructure and configuration. This state is used by Terraform to map real-world resources to your configuration, keep track of metadata, and improve performance for large infrastructures.

This state is stored by default in a local file named "terraform.tfstate", but it can also be stored remotely, which works better in a team environment.

WRONG ANSWERS:

environment variables - these can be used to provide values for variables or other Terraform configurations, but this is now how Terraform manages resources

providers - these are Terraform plugins that enable communication to a platform's API to allow Terraform to provision resources, but it's not the feature that it uses to manage the resources that it is managing.

local variables - these provide values to use for the deployment and management of deployed resources in Terraform. It doesn't use these to manage resources

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

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

When a module is located at hashicorp/<name>, Terraform download it from the official Terraform pubic module registry. This is specified by the source argument within the module block. The module installer supports the following source types:

 - Local paths

 - Terraform Registry

 - GitHub

 - Bitbucket

 - Generic Git, Mercurial repositories

 - HTTP URLs

 - S3 buckets

 - GCS buckets

 - Modules in Package Sub-directories

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

This command is just a convenience alias for the 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.

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