SaveMyCert
Log in
5 of 5 free questions left today·for 30 a day
Terraform 004 · Domain 4

Terraform configuration practice questions

Terraform configuration is worth 22% of the Terraform 004 exam — the heaviest of the 8 domains. Resources, data sources, variables, outputs, expressions, functions, dependencies, and secrets. Weight approximates the sub-objective share. 6 fully worked examples are further down this page, answers included.

Exam weight
22%
the heaviest of the 8 domains
Questions
40
across 2 topics
Free, no account
5/day
sign up free to remove the cap
Explanations
Every option
right and wrong

Build a practice session

5 free questions left today.

Domains

How many?

Mode

Ready when you are

10 fresh questions drawn across 1 of 8 domains, in Learn mode.

Focused review

Every question you answer incorrectly, and every question you flag while practising, is saved here automatically. Finish a session and you can come back to re-drill just those.

6 sample Terraform configuration questions, fully explained

Questions from the Terraform 004 bank mapped to domain 4, with the answer key and the reasoning behind every option. None of them repeat the examples on the main Terraform 004 practice page.

Question 1Terraform configuration

A configuration contains the block: data "aws_ami" "ubuntu" { ... }. Which expression correctly references the AMI's id attribute from a resource?

Choose one.

  • a
    aws_ami.ubuntu.id

    This is the address form for a managed resource. Data source references must be prefixed with data., so this address would refer to a resource "aws_ami" "ubuntu" block, which does not exist here.

  • b
    var.aws_ami.ubuntu.id

    The var. prefix references input variables declared with variable blocks, not data sources.

  • c
    data.aws_ami.ubuntu.id Correct

    Correct. Data source attributes are referenced as data.TYPE.NAME.ATTRIBUTE, so data.aws_ami.ubuntu.id is the valid reference.

  • d
    local.aws_ami.ubuntu.id

    The local. prefix references named values declared inside a locals block, not data sources.

The concept

Each kind of named value in Terraform has its own address prefix: managed resources have no prefix (TYPE.NAME), data sources use data., input variables use var., and local values use local.

Why that’s the answer

Because the block is a data source, its attributes are addressed as data.aws_ami.ubuntu.id. Dropping the data. prefix (option a) would point at a managed resource with the same type and name, which is a different object entirely. The var. and local. prefixes belong to input variables and locals and never address data sources.

How to reason it out
  1. Identify the block kind: data "aws_ami" "ubuntu" is a data source.
  2. Apply the data source address form: data.TYPE.NAME.
  3. Append the attribute you need: data.aws_ami.ubuntu.id.

Exam tip: Resources have no prefix, data sources use data., variables use var., and locals use local.

Terraform Resources, Data Sources, Variables, and Outputs — the lesson that teaches this.

Question 2Terraform configuration

An aws_subnet resource sets vpc_id = aws_vpc.main.id. What effect does this expression have on Terraform's execution order?

Choose one.

  • a
    Terraform infers an implicit dependency, so the VPC is created before the subnet without any extra configuration. Correct

    Correct. Referencing aws_vpc.main.id creates an implicit dependency in the resource graph, so Terraform orders the VPC before the subnet automatically.

  • b
    None; you must also add depends_on = [aws_vpc.main] to guarantee the VPC is created first.

    depends_on is unnecessary here. The attribute reference already establishes the dependency, and adding depends_on for a dependency that is visible through references is redundant.

  • c
    Terraform creates both resources in parallel and retries the subnet until the VPC exists.

    Terraform does not use a retry loop to resolve ordering. It builds a dependency graph from references and creates dependencies first; only independent resources run in parallel.

  • d
    The expression only copies the value at plan time and has no effect on ordering.

    References to resource attributes are exactly how Terraform learns ordering. They are not mere value copies; they are edges in the dependency graph.

The concept

Terraform builds a dependency graph from expression references. When one resource's argument references another resource's attribute, Terraform infers an implicit dependency and orders operations accordingly.

Why that’s the answer

The reference aws_vpc.main.id is itself the dependency declaration, so Terraform guarantees the VPC exists before creating the subnet with no depends_on needed. Option b reflects the common misconception that depends_on is always required, option c invents a retry mechanism Terraform does not use, and option d ignores that references are how the graph is built.

How to reason it out
  1. Write the natural attribute reference (aws_vpc.main.id) wherever a value from another resource is needed.
  2. Let Terraform derive the dependency graph from those references during plan.
  3. Reserve depends_on for hidden dependencies that no reference expresses.

Exam tip: Attribute references create implicit dependencies; depends_on is only for dependencies references cannot express.

Terraform Resources, Data Sources, Variables, and Outputs — the lesson that teaches this.

Question 3Terraform configuration

Before running terraform plan, an engineer runs export TF_VAR_instance_type=m5.large. The working directory also contains a terraform.tfvars file with instance_type = "t3.small". No other sources set the variable. What value does Terraform use?

Choose one.

  • a
    t3.small, because terraform.tfvars has higher precedence than TF_VAR_ environment variables. Correct

    Correct. Terraform loads TF_VAR_ environment variables first and then terraform.tfvars, and later sources override earlier ones, so the file value wins.

  • b
    m5.large, because environment variables override variable definition files.

    This inverts the precedence order. TF_VAR_ environment variables are the lowest-precedence explicit source; any tfvars file overrides them.

  • c
    Terraform errors because the variable is defined in two places.

    Defining a variable in multiple sources is normal and expected; Terraform resolves the conflict by precedence rather than raising an error.

  • d
    Terraform prompts interactively to choose between the two values.

    Terraform only prompts when a required variable has no value from any source. With two sources present, precedence decides silently.

The concept

Terraform resolves input variables using a fixed precedence order. From lowest to highest: defaults, TF_VAR_ environment variables, terraform.tfvars, terraform.tfvars.json, *.auto.tfvars files in alphabetical order, and finally -var and -var-file command-line options.

Why that’s the answer

terraform.tfvars sits above TF_VAR_ environment variables in the precedence order, so t3.small overrides m5.large. Option b is the classic scrambled-precedence trap, option c wrongly treats multiple definitions as a conflict error, and option d misapplies the interactive prompt, which only appears when no source provides a value.

How to reason it out
  1. List every source that sets the variable: TF_VAR_instance_type env var and terraform.tfvars.
  2. Rank them: environment variables are lower precedence than terraform.tfvars.
  3. Take the highest-ranked source's value: t3.small.

Exam tip: Any tfvars file beats TF_VAR_ environment variables; env vars only beat the default.

Terraform Resources, Data Sources, Variables, and Outputs — the lesson that teaches this.

Question 4Terraform configuration

A directory contains prod.auto.tfvars with region = "us-east-1". An engineer runs terraform plan -var="region=eu-west-1". Which region does the plan use?

Choose one.

  • a
    us-east-1, because auto-loaded files have the highest precedence.

    *.auto.tfvars files rank above terraform.tfvars and environment variables but below -var and -var-file options, so the file does not win here.

  • b
    us-east-1, because files named *.auto.tfvars can only be overridden by editing them.

    Auto-loaded files are ordinary variable sources; any -var or -var-file option supplied on the command line overrides them without editing anything.

  • c
    eu-west-1, because -var on the command line has the highest precedence of all variable sources. Correct

    Correct. -var and -var-file options override every file-based and environment-based source, so the CLI value eu-west-1 wins.

  • d
    Terraform errors because -var cannot override a value set in a file.

    There is no such restriction. Overriding file values from the command line is a supported and common workflow, resolved by precedence.

The concept

-var and -var-file command-line options are the highest-precedence variable sources in Terraform, overriding *.auto.tfvars files, terraform.tfvars.json, terraform.tfvars, TF_VAR_ environment variables, and defaults.

Why that’s the answer

Because the -var option outranks the auto-loaded file, the plan runs against eu-west-1. Options a and b overstate the rank of *.auto.tfvars, which sits just below the command line, and option d invents a conflict error where Terraform simply applies precedence.

How to reason it out
  1. Identify the two competing sources: prod.auto.tfvars and the -var option.
  2. Recall that command-line options sit at the top of the precedence order.
  3. Conclude the CLI value eu-west-1 is used for this run only; the file is unchanged.

Exam tip: -var and -var-file always win; they sit above every tfvars file and environment variable.

Terraform Resources, Data Sources, Variables, and Outputs — the lesson that teaches this.

Question 5Terraform configuration

A variable "size" has default = "t3.micro". The environment sets TF_VAR_size=t3.small, terraform.tfvars sets size = "t3.medium", and override.auto.tfvars sets size = "t3.large". No -var or -var-file options are used. What value does Terraform use?

Choose one.

  • a
    t3.small, because environment variables override files.

    TF_VAR_ environment variables are the lowest-precedence explicit source; both terraform.tfvars and any *.auto.tfvars file override them.

  • b
    t3.medium, because terraform.tfvars is always the final word among files.

    terraform.tfvars is loaded before *.auto.tfvars files, so an auto file overrides it. It is not the highest-precedence file.

  • c
    t3.micro, because a declared default cannot be overridden without -var.

    Defaults are the lowest-precedence source and are overridden by any other source, including environment variables and every kind of tfvars file.

  • d
    t3.large, because *.auto.tfvars files override terraform.tfvars, which overrides environment variables, which override the default. Correct

    Correct. With no command-line options, the *.auto.tfvars file is the highest-precedence source present, so t3.large wins.

The concept

Terraform's variable precedence from lowest to highest is: default value, TF_VAR_ environment variables, terraform.tfvars, terraform.tfvars.json, *.auto.tfvars (alphabetical), then -var and -var-file command-line options.

Why that’s the answer

With four sources present and no CLI options, the *.auto.tfvars file is highest, giving t3.large. Option a inverts env-var and file precedence, option b forgets that auto files load after terraform.tfvars, and option c wrongly treats the default as binding when it is merely the fallback of last resort.

How to reason it out
  1. Enumerate the sources: default, TF_VAR_size, terraform.tfvars, override.auto.tfvars.
  2. Order them low to high: default, env var, terraform.tfvars, *.auto.tfvars.
  3. Select the highest present source: override.auto.tfvars gives t3.large.

Exam tip: Memorize the ladder: default under TF_VAR_ under terraform.tfvars under *.auto.tfvars under -var/-var-file.

Terraform Resources, Data Sources, Variables, and Outputs — the lesson that teaches this.

Question 6Terraform configuration

A working directory contains a.auto.tfvars with region = "us-east-1" and m.auto.tfvars with region = "us-west-2". No other sources set the variable. Which value does Terraform use, and why?

Choose one.

  • a
    us-east-1, because Terraform uses the first auto file it loads and ignores later ones.

    Terraform loads every *.auto.tfvars file; earlier values are overridden by later ones, not the other way around.

  • b
    Terraform errors because the same variable is set in two auto-loaded files.

    Multiple auto files may set the same variable; Terraform resolves it by load order rather than failing.

  • c
    us-west-2, because Terraform prefers the file with the most recent modification time.

    File timestamps play no role in variable precedence; ordering among auto files is purely alphabetical by filename.

  • d
    us-west-2, because *.auto.tfvars files load in alphabetical order and later files override earlier ones. Correct

    Correct. Auto files are processed in lexical filename order, and values from later files override earlier ones, so m.auto.tfvars wins over a.auto.tfvars.

The concept

All *.auto.tfvars and *.auto.tfvars.json files in the working directory are loaded automatically, processed in lexical (alphabetical) order of their filenames, with later files overriding earlier ones.

Why that’s the answer

Since m sorts after a, m.auto.tfvars loads later and its region value overrides the one from a.auto.tfvars, yielding us-west-2. Option a reverses the override direction, option b invents a duplicate-definition error, and option c substitutes modification time for the real rule, which is filename order.

How to reason it out
  1. Sort the auto files alphabetically: a.auto.tfvars, then m.auto.tfvars.
  2. Load them in that order, letting later files override earlier values.
  3. The last-loaded file, m.auto.tfvars, supplies region = us-west-2.

Exam tip: Among *.auto.tfvars files, the alphabetically last file wins for any shared variable.

Terraform Resources, Data Sources, Variables, and Outputs — the lesson that teaches this.

What Terraform 004 domain 4 tests, topic by topic

The official exam guide breaks Terraform configuration into 2 topics. The question bank follows the same split, so a weak topic shows up as a cluster of misses you can go back and read.

Published Terraform 004 practice questions per topic in Terraform configuration
TopicWhat it coversQuestions
Resources, data sources, variables, and outputsOfficial Terraform Associate 004 objective 4 (part 1). Using and differentiating resource and data blocks; referring to resource attributes and creating cross-resource references; using variables and outputs; understanding and using complex types.20
Expressions, functions, dependencies, and sensitive dataOfficial Terraform Associate 004 objective 4 (part 2). Writing dynamic configuration using expressions and functions; defining resource dependencies; validating configuration using custom conditions; best practices for managing sensitive data, including secrets management with Vault.20
Total40

Revise Terraform configuration before you drill it

Other Terraform 004 domains

Terraform configuration: your questions

Terraform configuration is domain 4 of the Terraform 004 exam guide and carries 22% of the scored content — the heaviest of the 8 domains. On a 57-question paper that works out to roughly 13 questions, though HashiCorp does not publish an exact per-domain count and individual exam forms vary.

Source

The domain weight and topic list on this page come from the official Terraform 004 exam guide.