Free Terraform 004 practice questions

Infrastructure as Code (IaC) is the practice of managing infrastructure through machine-readable definition files that a tool executes, instead of manual processes or interactive consoles.

The defining property of IaC is that the infrastructure lives in files a tool can execute: Terraform reads HCL configuration and creates, updates or destroys real resources to match it. Because the files are plain text they also gain everything source code has: history, review and repeatable runs. The tempting distractors also mention version control, but a versioned runbook is still a manual process and versioned diagrams are not executable, so neither is code that provisions anything.

1. Ask whether a tool executes the definition to build the infrastructure; that is the core of IaC.
2. Notice that version control alone is not enough: runbooks and diagrams can be versioned too.
3. Separate infrastructure from application code: deploying apps is CI/CD, not IaC.

Exam tip: IaC = infrastructure defined in files a tool executes, not instructions or pictures for humans.

Provider requirements (local name, source address, version constraint) are declared in the required_providers block inside the terraform settings block.

required_providers is where a configuration states which provider plugins it needs and where they come from: source = "hashicorp/aws" is the aws provider in the hashicorp namespace of the public registry, and version = "~> 5.0" allows any 5.x release. The tempting near-twin puts the same arguments in a provider block, but that block only supplies settings such as region; its version argument is deprecated. required_version looks similar but constrains the Terraform CLI itself, and a module block sources modules, not plugins.

1. Find the terraform settings block and its required_providers map.
2. Give the provider a local name (aws) with source = "hashicorp/aws" and a version constraint.
3. Configure connection settings separately in provider "aws" {}, then run terraform init to install the plugin.

Exam tip: required_providers declares which plugin and version; the provider block only says how to connect.

terraform init is the mandatory first step in any new or freshly cloned Terraform working directory. It initializes the backend, installs the required provider plugins into the .terraform directory, downloads modules, and creates or verifies the dependency lock file.

Both symptoms in the error - an uninitialized backend and missing provider plugins - are exactly what terraform init fixes. validate and refresh depend on an initialized working directory, and terraform get fetches modules only, so none of them can substitute for init. Once init completes, terraform plan can load providers, read state through the backend and produce an execution plan.

1. Clone the repository and change into the configuration directory.
2. Run terraform init to configure the backend, install providers, and download modules.
3. Re-run terraform plan, which can now load provider schemas and read state.

Exam tip: Any freshly cloned Terraform directory needs terraform init before plan, apply, or validate will work.

Resources declare infrastructure objects Terraform owns through their whole lifecycle. Data sources fetch information about objects that already exist so the configuration can use it without managing those objects.

A resource block makes Terraform create the object on the first apply and update or destroy it on later runs. A data block performs a read-only query and never changes real infrastructure. The other statements describe tempting but wrong mechanics: data sources are read during plan or apply as needed, their results are stored in state, and both block types are available from providers of any kind.

1. Ask whether Terraform should own the object's lifecycle: if yes, it is a resource.
2. If the object already exists and only its attributes are needed, it is a data source.
3. Remember that both appear in state, and both are offered by providers of every kind.

Exam tip: resource = create and manage; data = read-only lookup of something Terraform does not manage.

Terraform decides how to obtain a module from the shape of the source string. Only strings that begin with ./ or ../ are treated as relative local paths; anything else is parsed as a remote address such as a registry module.

Without the ./ prefix, modules/network does not match the local-path form, so Terraform tries to parse it as a remote address and fails. Adding ./ is the whole fix. A leading slash turns it into an absolute path to a different location, the .terraform/modules directory is a cache rather than a source location, and terraform get performs the same installation step and hits the same error.

1. Read the source string and check whether it starts with ./ or ../.
2. Recognise that an unprefixed path is parsed as a remote address, not a folder.
3. Add the ./ prefix so the path resolves relative to the calling module.
4. Re-run terraform init, which now loads the directory in place.

Exam tip: Local module sources must start with ./ or ../; without the prefix Terraform treats the string as a remote address.