Terraform Associate · Domain 4 of 8

Terraform Associate Domain 4: Terraform configuration

This domain covers writing Terraform configuration in HCL: resource and data blocks, resource references, variables and outputs, complex types, expressions and functions, dependencies, custom conditions, and managing sensitive data.

Exam weight estimate
Not published
Official objectives
8
Estimated questions estimate
~12
Suggested study time estimate
5–10 hrs

About 12 min read Reviewed October 2026

Overview

Terraform configuration covers writing the configuration language itself, and it has the most objectives alongside the workflow domain. It has eight objectives. Using resource and data blocks covers creating managed resources and reading existing data. Resource references cover referring to attributes and linking resources. Variables and outputs cover parameterizing configuration and exposing values. Complex types cover lists, maps, sets and objects. Expressions and functions cover dynamic configuration. Dependencies cover implicit and explicit resource ordering. Custom conditions cover validating configuration. Managing sensitive data covers marking values sensitive and secrets management with Vault.

This domain is the heart of authoring Terraform. The exam rewards knowing the difference between resource and data blocks, how references create dependencies, how to use variables, outputs and complex types, and how to handle sensitive data safely. These authoring skills are applied throughout modules, state and the workflow.

How it's tested

Terraform Associate questions in this domain test the configuration language: blocks, references, variables, types, expressions, dependencies and sensitive data. Configuration questions often show a block of HCL, so trace each reference, variable and expression to what Terraform will evaluate before choosing.

  • Resource or data block

    A need to create or read is described, and you choose a resource or data block.

  • References and dependencies

    An ordering or linking need is described, and you choose references or depends_on.

  • Variables, outputs and types

    A parameterization need is described, and you choose variables, outputs or complex types.

Reasoning it through

A configuration must look up an existing, externally managed network and attach new resources to it, without managing that network. Using a resource block would try to create or manage the network. A data block reads the existing network's attributes so new resources can reference it without managing it, which is the data-source pattern the exam expects for reading existing infrastructure.

Objectives 8

Official objectives from the HashiCorp outline, in outline order.

4a Use and differentiate resource and data blocksCreating managed resources versus reading existing data.
What it means
This covers resource blocks, which create and manage infrastructure objects, and data blocks (data sources), which read information about existing resources without managing them, and knowing when to use each.
What to understand
A resource block declares infrastructure Terraform creates, updates and destroys. A data block queries existing resources or external information for use in the configuration, without managing them. Using a data source avoids trying to manage something Terraform should only read.
How it shows up
A create-versus-read need is described, and you must choose a resource or data block.
Common confusion
Confusing resource and data blocks; resources manage objects, while data sources only read existing information.
4b Refer to resource attributes and create cross-resource referencesReferencing attributes to link resources and create dependencies.
What it means
This covers referring to a resource's attributes elsewhere in the configuration, creating cross-resource references that both pass values and establish implicit dependencies between resources.
What to understand
Referencing one resource's attribute in another, such as using a network's ID in a server, passes the value and creates an implicit dependency, so Terraform creates them in the correct order. References are the primary way resources connect and order themselves.
How it shows up
A linking or ordering need is described, and you must use an attribute reference.
Common confusion
Not realizing that an attribute reference automatically creates an implicit dependency.
4c Use variables and outputsParameterizing configuration and exposing values.
What it means
This covers input variables that parameterize configuration for reuse and flexibility, and output values that expose information from the configuration, including for use by other configurations or modules.
What to understand
Variables make configuration reusable by accepting inputs, with types, defaults and validation. Outputs expose values such as resource attributes after apply, useful for reference and for module interfaces. Together they parameterize and expose the configuration cleanly.
How it shows up
A parameterization or value-exposure need is described, and you must use a variable or output.
Common confusion
Confusing input variables with output values; variables take input in, while outputs expose values out.
4d Understand and use complex typesLists, maps, sets and objects.
What it means
This covers complex data types in Terraform: collection types such as lists, maps and sets, and structural types such as objects and tuples, and using them in variables and configuration.
What to understand
Lists are ordered, sets are unordered and unique, maps are key-value pairs, and objects group named attributes. Choosing the right type structures data correctly, for example a map for named settings or a list for ordered items. Complex types enable flexible, structured configuration.
How it shows up
A data-structuring need is described, and you must choose the complex type.
Common confusion
Confusing a list with a set or a map; lists are ordered, sets are unordered and unique, and maps are key-value.
4e Write dynamic configuration using expressions and functionsExpressions, functions and dynamic blocks.
What it means
This covers writing dynamic configuration using expressions, built-in functions, conditionals, for expressions and dynamic blocks to compute and generate configuration rather than hard-coding values.
What to understand
Expressions and functions compute values, conditionals choose between them, for expressions transform collections, and dynamic blocks generate repeated nested blocks. These make configuration flexible and reduce duplication, adapting to inputs and data.
How it shows up
A dynamic or computed configuration need is described, and you must use an expression or function.
Common confusion
Hard-coding values where an expression or function would compute them dynamically.
4f Define resource dependencies in configurationImplicit references and explicit depends_on.
What it means
This covers how Terraform determines the order to create resources: implicit dependencies from attribute references, and explicit dependencies declared with depends_on when a relationship is not expressed through a reference.
What to understand
Terraform builds a dependency graph, ordering resources mostly from implicit references. When a dependency exists but is not captured by a reference, depends_on declares it explicitly. Correct dependencies ensure resources are created and destroyed in the right order.
How it shows up
An ordering need is described, and you must choose an implicit reference or depends_on.
Common confusion
Using depends_on where an attribute reference already creates the dependency, or omitting it where no reference exists.
4g Validate configuration using custom conditionsCustom validation such as variable validation and preconditions.
What it means
This covers custom conditions that validate configuration, such as variable validation rules and resource preconditions and postconditions, to catch invalid inputs or states early with clear errors.
What to understand
Custom conditions enforce rules beyond basic type checking, such as requiring a variable to match a pattern or a resource to meet a condition. They produce clear error messages and fail early, improving reliability. They complement terraform validate's syntax checking.
How it shows up
A validation need is described, and you must use a custom condition.
Common confusion
Confusing custom conditions with terraform validate; conditions enforce custom rules, while validate checks syntax and consistency.
4h Understand best practices for managing sensitive data, including secrets management with VaultMarking values sensitive and secrets management.
What it means
This covers best practices for sensitive data: marking variables and outputs as sensitive so they are not shown in output, avoiding hard-coded secrets, keeping secrets out of state where possible, and using secrets management such as HashiCorp Vault.
What to understand
Sensitive values should be marked sensitive to suppress them in plan and apply output, and never hard-coded in configuration committed to source control. Secrets management tools like Vault supply secrets at runtime. State can contain sensitive data, so it must be secured. These practices protect credentials.
How it shows up
A sensitive-data need is described, and you must choose the sensitive marking or secrets approach.
Common confusion
Hard-coding secrets in configuration instead of marking them sensitive and using a secrets manager.

High-yield concepts

The terms, rules and formulas this domain turns into questions most often.

  • Resource block

    Creates and manages an object.

    Remember
    Terraform owns its lifecycle.
    Tested as
    Configuration questions.
    Trap
    Confusing with a data block.

  • Data block

    Reads existing information.

    Remember
    It does not manage the object.
    Tested as
    Configuration questions.
    Trap
    Confusing with a resource.

  • Attribute reference

    References another resource's attribute.

    Remember
    Creates an implicit dependency.
    Tested as
    Dependency questions.
    Trap
    Not realizing it creates ordering.

  • Input variables

    Parameterize configuration.

    Remember
    Types, defaults and validation.
    Tested as
    Variable questions.
    Trap
    Confusing with outputs.

  • Output values

    Expose values from configuration.

    Remember
    Useful for module interfaces.
    Tested as
    Output questions.
    Trap
    Confusing with variables.

  • Complex types

    Lists, maps, sets, objects.

    Remember
    Choose by ordering and keys.
    Tested as
    Type questions.
    Trap
    Confusing list, set and map.

  • Expressions and functions

    Compute dynamic values.

    Remember
    Reduce duplication.
    Tested as
    Dynamic config questions.
    Trap
    Hard-coding instead.

  • Implicit vs. explicit dependencies

    References versus depends_on.

    Remember
    Use depends_on only when no reference exists.
    Tested as
    Dependency questions.
    Trap
    Overusing depends_on.

  • Custom conditions

    Variable validation and pre/postconditions.

    Remember
    Fail early with clear errors.
    Tested as
    Validation questions.
    Trap
    Confusing with terraform validate.

  • Sensitive values

    Mark variables and outputs sensitive.

    Remember
    Suppresses them in output.
    Tested as
    Sensitive-data questions.
    Trap
    Hard-coding secrets.

  • Secrets management with Vault

    Supply secrets at runtime.

    Remember
    Keep secrets out of code.
    Tested as
    Sensitive-data questions.
    Trap
    Committing secrets to source.

Side by side

Concepts candidates mix up, compared on the point that decides the answer.

Resource block vs. data block

ConceptMeaningKey differenceCommon trap
Resource block Creates and manages Terraform owns lifecycle Using to read existing data
Data block Reads existing information No management Using to create resources

Input variables vs. output values

ConceptMeaningKey differenceCommon trap
Input variables Take values in Parameterize configuration Confusing with outputs
Output values Expose values out Share after apply Confusing with variables

Implicit vs. explicit dependencies

ConceptMeaningKey differenceCommon trap
Implicit (reference) From attribute references Automatic ordering Adding depends_on unnecessarily
Explicit (depends_on) Declared manually For hidden dependencies Omitting where no reference exists

Exam traps

Each trap is an answer that looks right. Learn the clue that should change your mind.

  1. Resource to read data

    What candidates pick
    Use a resource block to look up an existing, externally managed network.
    Why it looks right
    Resources represent infrastructure.
    Why it's wrong
    A data block reads existing resources without managing them; a resource block would try to create or manage it.

    Clue to watch for The infrastructure already exists and should only be read.

  2. depends_on with a reference

    What candidates pick
    Add depends_on between two resources that already reference each other's attributes.
    Why it looks right
    It makes the dependency explicit.
    Why it's wrong
    An attribute reference already creates an implicit dependency; depends_on is only for relationships not expressed by a reference.

    Clue to watch for The resources already reference each other.

  3. List is a set

    What candidates pick
    Use a list where unordered, unique values are required.
    Why it looks right
    Both hold multiple values.
    Why it's wrong
    A set is unordered and unique; a list is ordered and allows duplicates, so choose by the requirement.

    Clue to watch for Values must be unique and order does not matter.

  4. Hard-coded secret

    What candidates pick
    Put a password directly in the configuration file.
    Why it looks right
    It is simple.
    Why it's wrong
    Secrets should be marked sensitive and supplied by a secrets manager such as Vault, never hard-coded in committed configuration.

    Clue to watch for The configuration needs a credential or secret.

  5. Condition is validate

    What candidates pick
    Rely on terraform validate to enforce that a variable matches a required pattern.
    Why it looks right
    Both validate.
    Why it's wrong
    terraform validate checks syntax and consistency; custom conditions enforce specific rules such as a required pattern.

    Clue to watch for A business rule on a value must be enforced.

Answer framework

For any Domain 4 scenario, use these steps to find the answer the exam expects.

  1. Decide whether to create or read: use a resource block to manage an object and a data block to read existing information.
  2. Link resources with attribute references, which pass values and create implicit dependencies, using depends_on only when no reference captures the dependency.
  3. Parameterize with input variables and expose values with outputs, choosing the right complex type for the data.
  4. Use expressions and functions for dynamic configuration, and custom conditions to validate inputs and states early.
  5. Mark sensitive values as sensitive, keep secrets out of committed configuration, and use a secrets manager such as Vault. Where two expressions seem to fit, prefer the one that lets Terraform infer dependencies from references rather than an explicit depends_on.

Practice question

A Terraform configuration needs to attach new resources to an existing virtual network that is managed outside of this configuration, reading the network's attributes without managing or modifying it. What should the configuration use?

Want more like this? The Terraform Associate practice test has questions for every domain.

Checklist

0 of 10

Tick each one you can do without notes. Your ticks stay in this browser.

Study strategy

This is a large, practical authoring domain, so write a lot of configuration rather than only reading. Start with the resource-versus-data-block distinction, which is fundamental: resources manage, data sources read. Then learn how attribute references link resources and automatically create implicit dependencies, reserving depends_on for hidden dependencies.

Next, practice variables and outputs, and the complex types, keeping lists, sets and maps distinct. Learn expressions, functions and dynamic blocks to write flexible configuration, and custom conditions for validation. Finally, learn sensitive-data best practices: marking values sensitive, keeping secrets out of committed code, and using Vault.

Because this domain is hands-on, building real configurations that use each feature is the best preparation. Write a configuration that uses for_each, a complex-type variable and a validation block, then run terraform console to test expressions and functions interactively before using them. Review missed practice questions by objective, paying attention to snippets you misread. Afterwards, move to Domain 5, Terraform modules.

FAQ

What is the difference between a resource block and a data block?

A resource block creates and manages an infrastructure object through its lifecycle. A data block (data source) reads information about existing resources without managing them.

How do resource references create dependencies?

Referencing one resource's attribute in another passes the value and creates an implicit dependency, so Terraform automatically creates and destroys the resources in the correct order.

What is the difference between variables and outputs?

Input variables take values into the configuration to parameterize it. Output values expose information out of the configuration, such as resource attributes, often as a module's interface.

When do I need depends_on?

Only when a dependency exists that is not already expressed through an attribute reference. If resources reference each other, the implicit dependency is enough and depends_on is unnecessary.

How should I handle secrets in Terraform?

Mark sensitive variables and outputs as sensitive so they are hidden in output, never hard-code secrets in committed configuration, secure the state, and use a secrets manager such as HashiCorp Vault to supply secrets at runtime.

What is the difference between a list, a set and a map?

A list is ordered and allows duplicates, a set is unordered and unique, and a map is a collection of key-value pairs. Choose by whether order, uniqueness or keys matter.

How does Domain 4 connect to the rest of the exam?

The configuration written here is organized into the modules of Domain 5, tracked by the state of Domain 6, and deployed with the workflow of Domain 3.

Other Cloud Computing certifications

Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.

Test your Domain 4 knowledge

You have covered blocks, references, variables, types, expressions, dependencies and sensitive data. Test whether you can author correct configuration under exam conditions.

Take the Terraform Associate practice test Check your Terraform Associate readiness

Keep going