Terraform Associate (004) practice questions and exam guide

Which capability most distinguishes Terraform from AWS CloudFormation?

1. Terraform is declarative, whereas CloudFormation follows an imperative execution model.
2. Terraform needs no cloud credentials, while CloudFormation always requires authentication.
3. Terraform keeps state in S3 by default, while CloudFormation keeps no state whatsoever.
4. Terraform manages resources across many providers from a single configuration language.

Answer: D — Terraform manages resources across many providers from a single configuration language.

D is right: the provider plugin model lets one HCL configuration span AWS, Azure, Google Cloud, Kubernetes, SaaS platforms and on-premises systems, and reference values across them. A is wrong because both tools are declarative. B is wrong — Terraform authenticates to every provider it touches. C is doubly wrong: Terraform's default backend is local, not S3, and CloudFormation does track stack state, just on the service side rather than in a file you own.

Which of the following is NOT a benefit of Infrastructure as Code?

1. Infrastructure definitions can be version controlled and reviewed like application code
2. Environments can be reproduced consistently across development, staging and production
3. Running infrastructure is guaranteed never to drift from the committed configuration
4. Proposed infrastructure changes can be reviewed in a plan before they are deployed

Answer: C — Running infrastructure is guaranteed never to drift from the committed configuration

C is right as the non-benefit: drift still happens because people and other automation change resources out of band. IaC narrows the window and gives you the tools to detect it — a refresh-only plan surfaces the difference, and managing drift is an examinable objective — but nothing about writing code prevents someone editing a resource in the console. A, B and D are genuine, routinely cited advantages.

Which statement BEST captures the difference between a declarative tool such as Terraform and an imperative provisioning script?

1. The configuration states the desired end state and Terraform derives the actions needed to reach it
2. The declarative configuration lists the API calls in order and the tool executes them exactly as written
3. The declarative configuration can only add resources, while an imperative script can also remove them
4. The declarative configuration must be re-authored for each run, while a script can be executed repeatedly

Answer: A — The configuration states the desired end state and Terraform derives the actions needed to reach it

A) Correct — you describe the end state; Terraform compares it with reality and computes the actions. B) is a direction reversal: it describes the imperative model, which is exactly what Terraform is not. C) is false; declarative tools handle deletions by removing the block and applying. D) inverts the durability argument — the declarative file is the reusable artifact.

In the expression provider = aws.west, what is 'aws.west'?

1. A resource of type 'aws' whose local name inside this configuration is west
2. A module named west that exports an aws provider for its callers to consume
3. A reference to the aws provider configuration carrying the alias 'west'
4. A workspace named west that scopes the run to the us-west state partition

Answer: C — A reference to the aws provider configuration carrying the alias 'west'

C is right: the meta-argument selects which provider configuration a resource or module uses, and the part after the dot is the alias declared on a second provider block. A reads it as a resource address, which uses the same dotted shape and is the natural misread. B invents a module output of a provider. D confuses provider selection with workspaces. Omit the argument and the resource takes the default, unaliased configuration for its type.

A reviewer sees a `required_providers` block in a colleague's configuration and asks where it legally belongs. The correct answer is that it must appear:

1. At the top level of the file, as a sibling of the resource, variable and provider blocks
2. Inside each `provider` block, so the version travels with its configuration
3. Inside a `backend` block, alongside the other initialisation-time settings
4. Nested inside the `terraform` block, which is where provider requirements are declared

Answer: D — Nested inside the `terraform` block, which is where provider requirements are declared

D) Correct — `required_providers` is a nested block of the `terraform` settings block. A) is the most common authoring error; a top-level `required_providers` is not valid. B) confuses requirements with configuration: the `provider` block holds settings such as region and credentials, not source and version. C) is wrong on both counts — `backend` configures state storage and is itself nested in the `terraform` block.

What is a Terraform 'provider'?

1. A reusable bundle of configuration called from the root module with a source argument
2. An editor integration that validates HCL and offers completion while you write resources
3. The storage location, local or remote, where Terraform persists the state of the resources
4. A plugin that talks to a specific API, turning configuration into calls on that service
5. A named alias for an alternate state file used to run one configuration several times

Answer: D — A plugin that talks to a specific API, turning configuration into calls on that service

D is right: providers are plugins that implement resource and data source types and translate configuration into API calls; they are declared in required_providers and installed by init. A is a module, B is tooling, C is a backend and E is a workspace - all distinct from the plugin layer that actually reaches the platform.

Which command formats Terraform configuration files to canonical style?

1. terraform style
2. terraform lint
3. terraform format
4. terraform fmt

Answer: D — terraform fmt

Trick: the command is 'fmt' (like gofmt), not 'format' or 'style'. -check returns nonzero if files would be changed (useful in CI).

During an outage an engineer uses `-target` to apply a single resource, and afterwards proposes making it the team's standard practice to keep applies fast. The BEST response is:

1. Adopt it, since limiting the graph is the documented way to reduce plan time on very large configurations
2. Adopt it only for destroy operations, where narrowing the blast radius of a run is most obviously valuable
3. Replace it with `-refresh=false`, which achieves the same narrowing of scope with considerably fewer side effects
4. Reject it: targeting is documented for exceptional recovery, and routine use leaves state inconsistent with the configuration

Answer: D — Reject it: targeting is documented for exceptional recovery, and routine use leaves state inconsistent with the configuration

D) Correct — HashiCorp positions `-target` as an escape hatch for recovering from errors, warning that habitual use produces state that no longer reflects the whole configuration. A) is the misconception the warning exists to counter; splitting configurations is the supported answer to slow plans. B) narrows the bad advice without fixing it — targeted destroys carry the same inconsistency risk. C) confuses two unrelated flags: skipping refresh changes how state is reconciled, not which objects are in scope.

A team runs 'terraform plan' but skips saving the plan file with -out. What is the risk on apply?

1. apply recomputes the plan, which may differ from the one that was reviewed.
2. No risk — apply reuses the identical plan that the previous command computed.
3. apply refuses to run unless it is handed a previously saved plan file.
4. apply silently reads the cached plan from .terraform/plan.json instead.

Answer: A — apply recomputes the plan, which may differ from the one that was reviewed.

A is right: without -out there is no artifact to hand to apply, so apply re-plans from current state and real infrastructure, and the result can differ from what a reviewer approved. B assumes a plan cache that does not exist. C is wrong because apply runs happily with no plan file, just with a confirmation prompt. D names a file Terraform never writes. For change control, always run plan -out=FILE and apply that exact file.

Which CLI argument file format does Terraform automatically load if present in the working directory?

1. terraform.tfvars, terraform.tfvars.json, and any file ending in .auto.tfvars
2. vars.tf, because variable declarations double as default value assignments
3. config.yaml placed beside main.tf and merged during the initialization phase run
4. terraform.env, read as key=value pairs before the plan is generated for you

Answer: A — terraform.tfvars, terraform.tfvars.json, and any file ending in .auto.tfvars

A is right: those are the only names Terraform loads without being told to, and any other .tfvars file must be passed with -var-file. B confuses declaration with assignment — a .tf file declares variables and may carry defaults, but it is not an argument file. C is not a format Terraform reads at all. D invents a dotenv convention. Values from auto-loaded files are overridden by -var and -var-file on the command line.

Which practice is LEAST appropriate for handling secrets in a Terraform configuration?

1. Injecting the token as a workspace variable marked sensitive
2. Committing a terraform.tfvars file containing the API token
3. Supplying the token through a TF_VAR_ environment variable
4. Reading the token from a secrets manager through a data source

Answer: B — Committing a terraform.tfvars file containing the API token

A) Sensitive workspace variables are a standard, audited injection path. B) Correct — committing plaintext credentials to version control exposes them to everyone with repository access and is the practice to avoid. C) Environment variables keep the value out of files, a common and accepted approach. D) Fetching from a secrets manager keeps the value out of the repository.

Which is true about 'depends_on' on a module block?

1. depends_on is supported on module blocks and applies to the module as a unit
2. depends_on is rejected on module blocks and works only on resource blocks
3. module-level depends_on requires an accompanying wait_for attribute in order to work
4. module-level depends_on constrains provider setup only, not child resources

Answer: A — depends_on is supported on module blocks and applies to the module as a unit

A is right: a module block accepts depends_on, and every resource inside the module inherits that dependency, which is useful when a whole module must wait on something Terraform cannot infer. B is the misconception that the meta-argument is resource-only. C invents a companion attribute. D wrongly narrows the effect to providers. Use it sparingly, since implicit dependencies through input variables and outputs are usually clearer.

Which module source string would Terraform interpret as a local path (no download)?

1. git::https://example.com/mod.git
2. ./modules/vpc
3. terraform-aws-modules/vpc/aws
4. s3::https://s3.amazonaws.com/bucket/mod.zip

Answer: B — ./modules/vpc

Trick: local paths must start with './' or '../'. A bare 'modules/vpc' is treated as a registry shorthand and would fail to resolve.

A module is called with `source = "./modules/network"`. Which statement about this call is correct?

1. Terraform copies the directory into `.terraform` on each init so the original may then be deleted
2. The module is read from the local filesystem, so no download occurs and no `version` argument applies
3. The leading `./` is optional, since Terraform treats any unrecognised source string as a local path
4. Local sources are resolved at apply time rather than at init, so that init need not be re-run after any edits

Answer: B — The module is read from the local filesystem, so no download occurs and no `version` argument applies

B) Correct — a source beginning with `./` or `../` is a local path; the module is used in place, and version constraints are meaningless because there is no versioned artifact. A) is wrong: local modules are referenced where they sit, not vendored into `.terraform`. C) inverts the rule — the leading `./` is exactly what marks a path as local, and without it Terraform interprets the string as a registry address. D) is false in both halves: module sources are resolved during init, though edits to a local module need no re-download.

Which source can a module be referenced from?

1. Local filesystem paths only, so every module must be vendored into the repository first
2. The public HashiCorp registry only, using the namespace, name and provider address format
3. Local paths, public or private registries, Git, generic HTTP, S3, GCS and Bitbucket URLs
4. S3 buckets only, with the module archive uploaded as a versioned zip before it can be used
5. Git repositories only, referenced with the git:: prefix and an optional ref for versioning

Answer: C — Local paths, public or private registries, Git, generic HTTP, S3, GCS and Bitbucket URLs

C is right: the source argument accepts local paths, registry addresses, Git and Mercurial URLs, HTTP archives and object storage in S3 or GCS. A, B, D and E each name one real source type and then wrongly exclude the rest; version constraints apply to registry sources, while Git sources pin with ref.

What is the Terraform state file?

1. A plain-text log of the commands run in the directory, kept only for troubleshooting
2. An optional cache that can be deleted safely because Terraform rebuilds it on demand
3. A scratch file of unstructured notes that Terraform writes between plan and apply
4. An HTML report of the managed infrastructure, regenerated at the end of every apply
5. A JSON record mapping configuration to real infrastructure; keep it in a remote backend

Answer: E — A JSON record mapping configuration to real infrastructure; keep it in a remote backend

E is right: terraform.tfstate is JSON that binds each configuration address to a real object, and teams should hold it in a locking, encrypted backend such as S3, Azure Storage, GCS or HCP Terraform. B is the dangerous one: state cannot simply be rebuilt, and losing it orphans resources. A, C and D misdescribe both the format and the purpose.

An engineer wants to inspect drift without altering the persisted state file. The BEST command is:

1. terraform apply -refresh-only with auto-approve
2. terraform plan -refresh-only
3. terraform state pull followed by state push
4. terraform refresh

Answer: B — terraform plan -refresh-only

A) The refresh-only apply is what commits the updated state. B) Correct — a refresh-only plan reports the differences between state and real infrastructure and, being a plan, writes nothing. C) Pulling and pushing state moves data around and risks overwriting it. D) refresh also updates the persisted state rather than merely reporting.

Which sequence is correct for moving a project from local to a remote S3 backend?

1. Delete the local state file first, then run terraform init against the bucket.
2. Run terraform apply -refresh-only before declaring any backend configuration.
3. Copy terraform.tfstate into the S3 bucket by hand and edit the serial number.
4. Add the backend block, run terraform init, and accept the migration prompt.

Answer: D — Add the backend block, run terraform init, and accept the migration prompt.

D is right: init detects that the configured backend differs from the recorded one and offers to copy existing state into the new location. A throws away the only record of your infrastructure before the migration can read it. B refreshes state but does nothing about where it lives. C is the hand-editing trap — serial and lineage fields are Terraform's business. Configure encryption and locking on the bucket as part of the same change.

A `moved` block with from = aws_instance.old and to = aws_instance.new has what effect?

1. Destroys aws_instance.old and creates aws_instance.new during the next apply.
2. Refreshes the state entry so the new address picks up the current attributes.
3. Imports a second, separate resource into state under the new address name.
4. Renames the state address to aws_instance.new, leaving the real resource alone.

Answer: D — Renames the state address to aws_instance.new, leaving the real resource alone.

D is right: the moved block records a refactor, so Terraform updates the address in state and the plan shows a move rather than a replacement. A is exactly what happens if you rename the resource without the block, which is why it tempts. B confuses the operation with a refresh. C would create a duplicate entry. Because it lives in configuration, a moved block is reviewable and runs for everyone, unlike a one-off CLI invocation.

Which command lists every resource address currently tracked in state?

1. terraform list
2. terraform show -addresses
3. terraform state list
4. terraform refresh -list

Answer: C — terraform state list

Trick: 'state list' is the subcommand. There is no top-level 'terraform list'. Useful for scripting targeted operations.

What does 'terraform import' do?

1. Downloads a child module from its source address into the .terraform/modules directory
2. Downloads and installs the provider plugins named in the required_providers block
3. Loads variable values from a .tfvars file so they can be referenced later as var.NAME
4. Brings an existing resource created outside Terraform under management, recorded in state
5. Converts a JSON document into HCL resource blocks that can be added to the configuration

Answer: D — Brings an existing resource created outside Terraform under management, recorded in state

D is right: import associates an existing object with a configuration address so Terraform starts managing it; you still write the matching resource block. The config-driven import block is the modern form, since it shows up in plan and can generate configuration. A and B are init behaviours, C is variable loading and E is not what import does.

The same set of cloud credentials variables must apply to twenty workspaces without being retyped. The BEST feature is:

1. A shared private registry module carrying the values
2. A Sentinel policy set that injects the values
3. A variable set scoped to the relevant workspaces or project
4. A run trigger configured on each workspace

Answer: C — A variable set scoped to the relevant workspaces or project

A) Registry modules distribute configuration code, not workspace variable values. B) Sentinel evaluates policy against plans; it does not supply variables. C) Correct — variable sets define variables once and apply them to chosen workspaces or an entire project. D) Run triggers queue runs based on another workspace's apply; they carry no variables.

A networking workspace's apply must automatically queue a run in a dependent application workspace. The correct feature is:

1. A terraform_remote_state data source in the application
2. A run trigger on that workspace
3. A project containing both workspaces
4. A variable set shared between the two workspaces

Answer: B — A run trigger on that workspace

A) The data source reads outputs but does not initiate a run. B) Correct — a run trigger configured on the downstream workspace queues a run there whenever the upstream workspace completes an apply. C) Projects group workspaces for organisation and permissions, without any execution linkage. D) Variable sets share values, not run scheduling.

Which statement about state in HCP Terraform is MOST accurate?

1. State locking must be configured separately per workspace
2. State is versioned, and prior versions can be inspected or rolled back
3. State is discarded once the run that produced it completes
4. State must still be committed to version control as a backup

Answer: B — State is versioned, and prior versions can be inspected or rolled back

A) Locking is automatic for workspace state and needs no separate configuration. B) Correct — HCP Terraform retains a version history of workspace state, which supports auditing and recovery. C) State is durable; it would be useless if discarded after each run. D) Committing state to version control leaks secrets and duplicates the authoritative copy.

Multi-user collaboration?

Remote state + locking. CI/CD pipeline. HCP Terraform features.

What range of versions does the constraint ~> 1.4.2 permit, and how does that differ from ~> 1.4?

~> 1.4.2 allows 1.4.2 up to but not including 1.5.0 — only the patch component may increment. ~> 1.4 allows 1.4 up to but not including 2.0 — the minor component may increment. The pessimistic operator always lets only the rightmost component you actually wrote move upward.

TF_LOG environment variable?

Sets verbosity. TRACE, DEBUG, INFO, WARN, ERROR. TRACE most verbose.

terraform init -upgrade?

Force upgrade providers/modules to latest acceptable versions.

What is infrastructure as code (IaC), and what are its three headline advantages?

IaC is the practice of defining and provisioning infrastructure through machine-readable configuration files that are versioned and applied automatically rather than built by hand. Headline advantages: repeatability and consistency across environments, version control with peer review and an audit trail, and automation that removes slow, error-prone manual console work.

terraform plan?

Preview changes. Shows what will be added, changed, destroyed.