Terraform Cloud (all versions) and Terraform Enterprise offer the use of a private module registry. Among all the features you get with Terraform OSS, all other versions get these features, at a minimum:

 - State management

 - Remote operations

 - Private module registry

 - Community support

WRONG ANSWER:

You do not have the ability to use a private module registry with Terraform OSS.

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

Ok, so this was sort of a trick question because locking down your state file really has nothing to do with storing sensitive values inside of your Terraform configuration. Remember that most, if not all, of your configuration, will likely be committed to a code repository. Anybody, or any machine, with access to that code repo would now be able to read the sensitive values that were hardcoded in your Terraform configuration.

Best practice here is to provide your sensitive values OUTSIDE of Terraform, like storing and retrieving them from a secrets management platform like Vault, or using environment variables.

https://learn.hashicorp.com/tutorials/terraform/sensitive-variables?in=terraform/configuration-language

When working with resources, there may be times where a particular resource didn't deploy correctly, although Terraform thinks it did. An example of this might be a script that runs on a virtual machine in the background. The virtual came up fine, so Terraform believes it was successful, but the script didn't perform the tasks you needed it to, so you need Terraform to destroy and recreate the one resource. In this case, you can use terraform apply -replace="<resource_id>" to have Terraform replace this one resource on the next terraform apply.

IMPORTANT - PLEASE READ

This command was formally terraform taint, and you may or may not see terraform taint still on the exam. The taint command was deprecated in Terraform 0.15.2 and replaced with the terraform apply -replace command. Note that the resource is NOT immediately replaced when you run a terraform taint. It will only happen on the next terraform plan/apply. While HashiCorp does a great job updating their exams, sometimes commands can be a little slow to be removed or replaced from the test questions.

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

When using modules, it's common practice to declare variables outside of the module and pass the value(s) to the child module when it is called by the parent/root module. However, it's perfectly acceptable to declare a variable inside of a module if you needed. Any variables declared inside of a module are only directly referencable within that module. You can't directly reference that variable outside of the module. You can, however, create an output in the module to export any values that might be needed outside of the module.

WRONG ANSWERS:

Output block? While an output block would allow you to get information from within the module, creating an output block still wouldn't allow you to reference the variable directly using the var.<name> nomenclature.

Referencing a Variable You can't reference a variable declared inside of a module, therefore the name shown in this incorrect answer wouldn't work. Ideally, you would create an output inside the module and reference the output rather than the variable inside of the module itself.

Using Interpolation in Terraform This incorrect answer is just plain wrong. In fact, you would reference an accessible variable using the var prefix. Interpolation is the ability to reference data or values within your Terraform code using specific formats. For variables, that format is var.<name>.

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

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

When workspaces are linked to a VCS repository, Terraform Cloud can automatically initiate Terraform runs when changes are committed to the specified branch.

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

Unlike many other objects in the Terraform language, a provider block may be omitted if its contents would otherwise be empty. Terraform assumes an empty default configuration for any provider that is not explicitly configured. In other words, if you don't have any specific configurations for your provider, you may indeed leave it out of your configuration.

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

This is true. If a module or provider is marked as official, it is owned and maintained by HashiCorp themselves. In fact, I copied the sentence in the question straight off the official Terraform registry page :)

There are other modules/providers available in the registry that are maintained by third-party partners, or even individuals. This also means that not all of the modules published to the Terraform registry are validated or verified by HashiCorp. Many folks will use the public module registry as a starting place to create their own custom modules needed to meet requirements.

https://registry.terraform.io/

https://registry.terraform.io/browse/modules

https://www.terraform.io/internals/module-registry-protocol

Using Infrastructure as Code (IaC) like Terraform, CloudFormation, etc. enables organizations to completely change the way they deploy applications and the underlying infrastructure to support them. Rather than click around in a console, IaC enables API-driven workflows for deploying resources in public clouds, private infrastructure, and other SaaS and PaaS services.

When developing IaC, organizations can now use a Version Control System, such as GitHub, GitLab, Bitbucket, etc. to store and version its code. When changes are needed, the existing code can be cloned, modified, and merged back into the main repository by way of a pull or merge request. These requests can follow a traditional workflow where approvals are needed before they are deployed to a production environment.

By moving your configurations to code and publishing them to a shared repository, or registry, different operators in the organization can now easily consume this code without even knowing how to write Terraform. They can simply provide the required values by way of variables and entire environments can be provisioned to support their application(s).

WRONG ANSWER:

While Terraform can indeed help with the security of your applications, it won't guarantee it. You can combine Terraform with other tools, such as LaunchDarkly, SonarQube, DeepScan, and more using a CI/CD pipeline, but again, it doesn't guarantee the security of your application. Security is the responsibility of everybody involved in the deployment of an application, starting with the developer(s) themselves all the way to the people responsible for the day-to-day operations of the application.

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

https://www.terraform.io/intro

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

When you're learning the basics of Terraform, one of the critical requirements of executing any Terraform code is running terraform init to download all of the required plugins needed for the resources that will be deployed/managed. If you don't run a terraform init when running code in a new directory, a terraform apply/plan will immediately fail since it needs to download the plugins required to run.

WRONG ANSWERS:

While the traditional Terraform workflow is init --> plan --> apply, running a terraform plan is not required to execute a terraform plan. It's recommended to make changes to real environments, but when I'm testing or building labs for my other courses, I rarely run a terraform plan and go straight to terraform apply.

As for running Terraform cloned from another repo, you can absolutely do this. Many people use existing code as a starting point for their own environment. They will clone the repo, customize it however they need and then run it. This is a perfectly acceptable practice and it prevents you from constantly reinventing the wheel.

Regarding authentication, you only need to use the terraform login command when you are working with Terraform Cloud. You don't need authentication credentials outside of that use case unless you are deploying resources to some platform, like AWS, Azure, VMware, etc. There are plenty of use cases for Terraform where you don't need authentication credentials at all, like using the TLS or random provider.

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

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

https://www.terraform.io/cli/init#initialization

The terraform validate command validates the configuration files in a directory, referring only to the configuration and not accessing any remote services such as remote state, provider APIs, etc.

Validate runs checks that verify whether a configuration is syntactically valid and internally consistent, regardless of any provided variables or existing state. It is thus primarily useful for general verification of reusable modules, including the correctness of attribute names and value types.

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