Terraform 004 sample questions — 25 answered and explained

Terraform is service-agnostic: a provider is a bridge to any API, so SaaS platforms are managed with the same workflow as clouds.

Providers for GitHub, Datadog and Cloudflare expose resource types (for example a repository or a monitor) that Terraform tracks in state and diffs in plan, exactly like aws_instance. Provisioners and the external data source are tempting because they can reach any CLI or script, but neither creates managed resources: provisioners run side-effect commands and data sources only read.

1. Note the requirement: objects tracked in state and shown in plan.
2. Recall that only resources (from a provider) are managed through state and plan.
3. Reject workarounds that run commands or read data without managing resources.

Exam tip: If a service has an API, a provider can make it a Terraform resource with the normal lifecycle.

Self-service is an IaC advantage: platform teams package approved patterns as reusable modules, and other teams provision from them on demand.

The scenario's change is that product teams no longer file tickets: they call a module with a few variables. That is self-service within guardrails, because the module decides what can be built. State locking, drift detection and immutable releases are real Terraform concepts, but none of them removes the dependency on another team.

1. Identify what changed: teams no longer wait on the platform team.
2. Match it to the advantage about who can provision, not how state or releases behave.
3. Reject real features that solve a different problem.

Exam tip: Reusable modules + no ticket queue = self-service within guardrails.

Once a provider version is recorded in the lock file, init keeps reinstalling it until you explicitly ask for an upgrade with terraform init -upgrade.

Both 5.31.0 and 5.45.0 satisfy "~> 5.0", so a plain init keeps the locked 5.31.0; that stability is the point of the lock file. init -upgrade disregards the existing selections, chooses the newest version allowed by the constraint and rewrites the lock file, which you then commit. -reconfigure is the tempting init flag, but it concerns the backend, and get -update is the module equivalent of an upgrade.

1. Check the constraint: 5.45.0 is allowed, so no constraint edit is needed.
2. Recall that init honours locked selections over newer matching releases.
3. Run terraform init -upgrade and commit the updated lock file.

Exam tip: New matching provider releases are ignored until terraform init -upgrade re-selects them.

Terraform core has no platform knowledge; provider plugins define resource types and translate planned changes into API calls.

Terraform core parses configuration, builds the dependency graph and manages state, then hands each resource operation to the provider that owns its type (aws_instance belongs to aws). The provider talks to the platform API. Modules package resources, backends store state, and HCP Terraform is the hosted run service; none of those is the provider.

1. Separate the roles: core (graph, state), provider (API calls), backend (state storage), module (reusable configuration).
2. Map the resource type prefix to its provider.
3. Pick the component that performs the API calls: the provider plugin.

Exam tip: Providers are plugins that define resource types and make the API calls; core never talks to the platform directly.

Multiple configurations of the same provider are created with alias, and resources select a non-default configuration with the provider meta-argument.

Keep the default provider "aws" block for us-east-1 and add a second block with alias = "europe" (any name) and region = "eu-west-1". Resources that belong in Europe set provider = aws.europe; the rest use the default. The near-twin gets the alias right but tries to choose it by a region argument on the resource, which is not how selection works, and required_providers declares the plugin only once.

1. Recognise the trigger: same provider, different settings.
2. Add an aliased provider block with the second Region.
3. Set provider = aws.<alias> on the resources (or module calls) that belong there.

Exam tip: Same provider, two Regions: add an alias and select it with provider = aws.<alias>.

Changing the backend configuration requires re-running terraform init, and init offers two distinct paths: -migrate-state copies existing state to the new backend, while -reconfigure abandons the old backend configuration without moving anything.

The team's requirement is continuity: the state that currently describes their infrastructure must end up in S3. terraform init -migrate-state performs exactly that guided migration, prompting for confirmation before copying. Choosing -reconfigure here would be a classic mistake - the S3 backend would start empty, and the next plan would propose creating everything again because Terraform no longer knows about the existing resources.

1. Add or edit the backend block in the configuration.
2. Run terraform init -migrate-state and confirm the prompt to copy state to the new backend.
3. Verify with terraform plan that no unexpected changes are proposed.

Exam tip: -migrate-state moves existing state to a new backend; -reconfigure switches backends without moving state.

Terraform supports partial backend configuration: you may omit some backend arguments from the configuration file and provide them when running terraform init, using -backend-config="key=value" flags or -backend-config=path pointing at a configuration file.

Backend blocks are processed during init, before input variables exist, so they cannot refer to variables, locals or data sources. Partial configuration is the supported way to keep secrets and environment-specific values out of committed code: the committed block names the backend type, and each environment passes its own bucket, key and credentials to terraform init with -backend-config (a file or key=value pairs). TF_VAR_ variables and provider settings never reach the backend, and plan does not take -backend-config at all.

1. Declare the backend block with only the non-sensitive, common settings.
2. Run terraform init -backend-config=backend.hcl (or repeated key=value flags) to supply the rest.
3. Keep per-environment backend config files out of version control if they contain secrets.

Exam tip: Backend blocks cannot use variables - supply dynamic backend settings with init -backend-config.

Although terraform validate is an offline check, it is not dependency-free: it validates resource arguments against provider schemas, and those schemas come from the provider plugins that terraform init installs into the working directory.

A CI runner starts from a clean checkout with no .terraform directory, so validate has no provider schemas to check against and fails. The fix is to run terraform init before validate in the pipeline (init -backend=false is a common variant when the job only validates and does not need state access). Credentials and state are red herrings - validate touches neither.

1. Add terraform init as the first Terraform step in the CI job.
2. Run terraform validate after init succeeds.
3. Fail the pipeline on a nonzero validate exit code to block broken configurations.

Exam tip: validate is offline but still requires an initialized directory for provider schemas.

terraform plan -detailed-exitcode changes plan's exit-status contract into a three-way signal: 0 means success with an empty diff, 1 means an error occurred, and 2 means success with changes present.

Only -detailed-exitcode changes what the exit status means: 0 for no changes, 2 for pending changes, 1 for errors. Every other plan variant exits 0 on success whether or not changes exist - saving the plan with -out, emitting JSON, or disabling interactive input - so a script would have to parse output to tell the cases apart. plan remains read-only, so nothing is changed.

1. Run terraform plan -detailed-exitcode in the scheduled job.
2. Branch on the exit status: 0 = in sync, 2 = changes pending, 1 = error.
3. Alert or trigger a review workflow when the exit status is 2.

Exam tip: plan -detailed-exitcode returns 0/1/2 for no-changes/error/changes-present - ideal for automation.

Refresh-only mode (terraform plan -refresh-only, and its counterpart apply -refresh-only) isolates the refresh step of the workflow: it compares the state file with real infrastructure and reports what state updates would be needed, without mixing in configuration changes.

A normal plan conflates two comparisons - real infrastructure vs state, and state vs configuration - into one set of proposed actions. When investigating manual out-of-band changes, you want only the first comparison. plan -refresh-only presents exactly that drift, and if you then want the state file updated to accept the external changes, apply -refresh-only will do it without touching infrastructure.

1. Run terraform plan -refresh-only to see detected drift between state and reality.
2. Review which attributes changed outside Terraform.
3. Either run terraform apply -refresh-only to accept the drift into state, or run a normal plan/apply to revert the infrastructure to match configuration.

Exam tip: plan -refresh-only reports drift between state and real infrastructure without proposing config-driven changes.

Outputs are the interface a child module exposes to its caller. The calling module reads them with the address form module.NAME.OUTPUT, where NAME is the label given in the module block.

Since the module block is labeled network and the child declares output "vpc_id", the caller reads module.network.vpc_id. The distractors misuse other prefixes: output. is not a reference prefix at all, var. is for the module's own inputs, and data. is for data sources.

1. Declare output "vpc_id" with a value inside the child module.
2. Instantiate the child with module "network" { source = ... } in the caller.
3. Reference the value as module.network.vpc_id anywhere in the calling module.

Exam tip: Child module outputs are read as module.NAME.OUTPUT; outputs are the only values a module exposes upward.

Structural types describe a fixed shape: object for named attributes of different types, tuple for positions of different types. Wrapping them in map() or list() makes a collection of that shape.

One value with named attributes of mixed types is precisely an object type. The near-twins add an outer collection (map or list), which changes the variable into many such values, and the tuple keeps the types but loses the attribute names.

1. Ask whether the requirement is one value or a collection: here it is one.
2. Ask whether elements are identified by name or by position: by name.
3. Named attributes with mixed types means object({ ... }).

Exam tip: Named mixed attributes = object; positional mixed types = tuple; list()/map() around them makes a collection.

Terraform's collection types differ in ordering and access: list is ordered and indexed, map is keyed, set is unordered and unique.

A set(string) stores each distinct string once and keeps no order, so it cannot be indexed. That makes sets the natural input for for_each over strings but unsuitable when positions matter; tolist() converts a set when an index is needed. The near-twin that keeps uniqueness but adds ordering is the common misconception.

1. Recall the three collection types: list, map, set.
2. Sets drop duplicates and have no defined order.
3. No order means no index: element access needs tolist() or a for expression.

Exam tip: set = unique and unordered, no index; list = ordered and indexed; map = keyed.

A tuple type fixes both the length of a sequence and the type of each position; a list has one element type for every element.

The value is positional (brackets) and mixes types, so the matching constraint is tuple([string, number, bool]). list(string) looks like it accepts the value, but only because Terraform converts the number and bool to strings: a list has one element type, so the per-position types are lost. The object option keys by name, and the list-of-tuples option adds an extra level of nesting.

1. The value is written with brackets, so it is a sequence, not an object.
2. Each position has a different type, so a single-element-type list cannot express it.
3. Fixed length with per-position types means tuple([...]).

Exam tip: Positional mixed types = tuple; a list converts its elements to one shared type.

Map values are read by key: var.MAP["key"]. Lists are read by numeric index.

A map(string) holds string values under string keys, so the value under environment is var.tags["environment"]. The unquoted form makes Terraform treat environment as a reference, numeric indexing is for lists and tuples, and element() works on lists only. (For keys that are valid identifiers, var.tags.environment also works, but it is not offered here.)

1. Identify the collection type: map(string), so access is by key.
2. Keys are strings, so put the key in quotes inside brackets.
3. Rule out list-style access: numeric indexes and element().

Exam tip: Read a map with var.name["key"]; numeric indexes are for lists and tuples.

Git module sources support two special pieces of syntax: a // delimiter that marks a subdirectory within the repository, and a ?ref= query parameter that selects a tag, branch or commit. The subdirectory belongs to the path and the ref to the query string.

The correct string composes them in the required order: repository URL, then //subdirectory, then ?ref=tag. Putting the subdirectory after the query corrupts the ref value, a single slash loses the subdirectory delimiter, and the version argument is rejected for Git sources.

1. Start with the git:: prefix and the repository HTTPS URL ending in .git.
2. Append // followed by the path of the module inside the repository.
3. Append ?ref=v2.1.0 to check out the tagged release.
4. Run terraform init to clone that ref and load only the subdirectory as the module.

Exam tip: Git sources: //subdir selects a folder inside the repo and ?ref= pins the revision, in that order.

Variables are scoped to the module that declares them. A child module receives values only through input variables it declares, set as arguments on the calling module block.

var.region inside the child refers to the child's own variables, and it has none, so validation fails. Declaring variable "region" in the child and passing region = var.region from the root is the only supported link. File names have no effect on scope, remote state reads another configuration's outputs, and there is no var.root syntax.

1. See that the reference is in the child, which declares no variables.
2. Recall that child modules never inherit the caller's variables.
3. Declare variable "region" inside the child module.
4. Pass region = var.region as an argument on the module block in the root.

Exam tip: A child module sees only the variables it declares; the caller passes values in explicitly.

A child module's resources are private to it. The only way to give the caller a value is an output block in the child, read as module.NAME.OUTPUT.

Declaring output "web_id" with value = aws_instance.web.id inside the child exposes the ID, and the root reads module.app.web_id. Direct resource addresses across the module boundary are not allowed, an output declared in the root is on the wrong side of the boundary, and remote state is for reading a different configuration.

1. Note the child has the resource but no outputs.
2. Recall that callers see only declared outputs of a child module.
3. Add an output block in the child whose value is aws_instance.web.id.
4. Reference module.app.web_id in the root.

Exam tip: To use a value from a child module, declare an output in the child and read module.NAME.OUTPUT.

-lock=false tells one command not to acquire the state lock. It does not remove or alter anyone else's lock.

If the lock is held, some operation probably is writing state. Proceeding without locking means two writers, exactly the corruption scenario locking exists to stop. The flag neither skips refresh, nor releases the other run's lock, nor changes behaviour for later runs.

1. Ask why the lock is held: another operation may be in progress.
2. Note that -lock=false skips acquiring the lock but leaves the other lock in place.
3. Conclude that both runs can now write state concurrently.

Exam tip: -lock=false reintroduces the concurrent-write risk locking prevents; it is almost never the right fix.

terraform_remote_state reads another configuration's state and exposes that configuration's root module outputs only.

The producing configuration controls what it publishes by declaring root outputs. A child-module output is internal until the root module re-exports it with its own output block (for example value = module.vpc.subnet_id). Sensitivity and module paths do not change this.

1. Locate where subnet_id is declared: a child module.
2. Recall that terraform_remote_state exposes only root module outputs.
3. Conclude that the reference fails until the root module re-exports the value.

Exam tip: terraform_remote_state sees only the source's root outputs; re-export child outputs at the root.

terraform_remote_state is a data source, so it takes the data. prefix, and its root module outputs are exposed under the outputs attribute.

The full path is data.<type>.<name>.outputs.<output_name>. Each distractor breaks one rule: missing outputs, missing data. or the singular output.

1. Recall that data sources are referenced with the data. prefix.
2. Recall that remote outputs sit under the outputs attribute.
3. Append the output name.

Exam tip: Remote outputs: data.terraform_remote_state.<name>.outputs.<output>.

terraform state pull reads the current state through whichever backend is configured and prints it to stdout in the raw state-file format (upgraded to the newest state-file version the installed Terraform supports, if needed).

pull outputs the raw state file, which is why it is the standard way to back up or inspect remote state; if the stored file uses an older state-file version, the local copy is upgraded to the format the installed Terraform understands before it is printed. terraform show -json is the tempting near-twin: it is JSON too, but it is the machine-readable representation format for tools, not the state file itself. output -json covers only outputs, and push uploads rather than downloads.

1. Note the need: the current state in raw state-file form, on stdout.
2. Recall that terraform state pull fetches and prints the raw state.
3. Separate it from terraform show -json, which emits a different JSON representation for tooling.

Exam tip: terraform state pull = the raw stored state on stdout; terraform show -json = a JSON view for tools.

A saved plan file is binary; terraform show reads it, and the -json flag turns the output into the documented machine-readable format.

terraform show -json plan.tfplan is the standard way to hand a saved plan to policy checks. Two near-twins fail one requirement each: terraform show plan.tfplan reads the right artifact but only as human-readable text, and terraform plan -json is machine-readable but creates a new plan instead of reading the saved one. state pull covers current state, not proposed changes.

1. Identify the input: a saved plan file, not current state.
2. Identify the output: machine-readable JSON.
3. Combine both: terraform show (reads the file) with -json (format).

Exam tip: Read a saved plan for tooling with terraform show -json PLANFILE.

Workspace variables come in two categories: Terraform variables (input variable values, like a .tfvars file) and environment variables (set in the run's shell). Either can be marked sensitive.

Provider credentials such as AWS_ACCESS_KEY_ID are read from the environment, so they belong in the environment variable category. Two tempting fixes miss this: removing the sensitive flag changes nothing because sensitive values are still passed to runs, and a variable set preserves the variables' category. Wiring the values through input variables works in principle but changes the configuration.

1. Identify how the provider looks for credentials: environment variables.
2. Check the variable category, not just its name.
3. Recall that sensitive values are hidden from people, not from runs.
4. Reject any fix that edits the configuration.

Exam tip: Provider credentials go in environment variables on the workspace (or a variable set), marked sensitive.

Sensitive workspace variables protect secrets from being read back by people while still letting runs use them.

Marking a variable sensitive makes it write-only: it cannot be viewed in the UI or read through the Variables API by anyone, including owners. Runs still receive the value. It is not a log scrubber: a configuration that outputs the value or passes it to a resource argument can still expose it in logs or state.

1. Separate who can read the value from whether runs can use it.
2. Sensitive = write-only for all users.
3. Runs still receive the value.

Exam tip: Sensitive = write-only for people, still available to runs.