Free Terraform 004 practice questions

Infrastructure as Code (IaC) is the practice of managing infrastructure through machine-readable definition files rather than manual processes or interactive consoles.

The defining property of IaC is that infrastructure lives in files a tool can execute: Terraform reads HCL configuration and creates, updates, or destroys real resources to match it. Because the definitions are plain text, they gain everything source code has — version control history, code review, reuse, and repeatable automated execution. Manual console work with a runbook, diagrams, or the application code itself all lack that executable, versionable definition of the infrastructure.

1. Ask whether the infrastructure is described in files a tool can execute — that is the core of IaC.
2. Check that those files can be versioned and reviewed like any other code.
3. Eliminate options that describe manual processes (console runbooks) or non-executable artifacts (diagrams, screenshots).

Exam tip: IaC = infrastructure defined in executable, version-controllable definition files, not manual console work.

Provider requirements — local name, source address, and version constraint — are declared in the required_providers block within the terraform settings block.

The required_providers block is where a configuration says which providers it depends on and where they come from: source "hashicorp/aws" means the aws provider in the hashicorp namespace of the public registry, and version "~> 5.0" constrains acceptable releases. The provider "aws" block is a different thing — it supplies configuration such as region — and is not where source or version live. Neither resource nor module blocks declare provider plugins.

1. Open a terraform {} settings block and add required_providers.
2. Give the provider a local name (aws) with source = "hashicorp/aws" and a version constraint.
3. Configure the provider separately in a provider "aws" {} block (region, credentials), then run terraform init to install it.

Exam tip: required_providers declares source and version; the provider block only configures — never confuse the two.

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. Plan, apply, validate, and refresh all depend on an initialized working directory, so none of them can substitute for init. Once init completes successfully, terraform plan will be able to 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 and manages through their full lifecycle. Data sources fetch information about objects that already exist so the configuration can reference them without managing them.

A resource block causes Terraform to create the object on the first apply and to update or destroy it on later runs, while a data block performs a read-only query and never modifies real infrastructure. The distractors describe plausible-sounding but wrong mechanics: data sources are read during plan or apply as needed, their results are stored in state, and both block types exist for every kind of provider.

1. Ask whether Terraform should own the object's lifecycle: if yes, use a resource block.
2. If the object already exists and you only need its attributes, declare a data block instead.
3. Reference the fetched attributes elsewhere in the configuration, remembering that data sources never change real infrastructure.

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

Terraform decides how to fetch a module purely from the shape of the source string. Anything that does not begin with ./ or ../ is treated as a remote source, and a bare two-part path resembles a registry address.

The prefix ./ or ../ is what marks a source as a local filesystem path. Without it, modules/network is sent to the registry resolver, which fails because it is not a valid namespace/name/provider address. There is no path argument (b), no required directory name (c), and no publishing requirement for local code (d).

1. Terraform reads the source string and checks whether it starts with ./ or ../.
2. Since modules/network has no such prefix, Terraform parses it as a remote registry address.
3. The registry lookup fails because the string is not a valid registry module path.
4. Rewriting the source as ./modules/network makes Terraform load the directory from local disk.

Exam tip: Local module sources must start with ./ or ../ or Terraform will treat them as remote addresses.