Courseiva
Use Terraform outside the core workflowhardMultiple ChoiceObjective-mapped

TF-004 Use Terraform outside the core workflow Practice Question

A company uses Terraform to manage multi-cloud infrastructure. They have separate Terraform configurations for AWS and Azure, each with its own state file. They want to share a common set of networking variables (e.g., allowed IP ranges) between these configurations without duplicating data. Which approach best achieves this?

⚠ Common exam trap

HashiCorp often tests the misconception that modules or variable files can share actual runtime data between separate configurations, when in fact they only define structure or require manual distribution, whereas remote state data sources provide dynamic, centralized sharing without duplication.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

Use a remote state data source to read the outputs from a dedicated 'globals' workspace.

Using a remote state data source allows you to read outputs from a dedicated 'globals' Terraform workspace that stores shared networking variables. This approach avoids data duplication and ensures that both AWS and Azure configurations can dynamically consume the same canonical set of values without manual copying or file sharing. It leverages Terraform's native remote state mechanism to securely and consistently share data across separate configurations.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

  • Create a module that contains the variable definitions and reference it in both configurations.

    Why it's wrong here

    Creating a module that defines variables centralizes their schema, but it does not centralize their *values*. Each root configuration referencing the module would still need to explicitly define and pass the specific values for these variables, leading to duplication of the actual configuration data across multiple separate root configurations. This approach only standardizes the input interface, not the shared data itself.

  • Define the variables in a 'terraform.tfvars' file and copy it to each configuration directory.

    Why it's wrong here

    Defining variables in a 'terraform.tfvars' file and copying it to each configuration directory creates multiple, unmanaged copies of the same data. This method inevitably leads to significant synchronization challenges and inconsistencies, as any change to a shared variable would require manual updates across all copied files. Such duplication makes maintenance difficult and error-prone, violating the principle of a single source of truth.

  • Store the variables in a JSON file and use the 'jsondecode' function in each configuration.

    Why it's wrong here

    Storing variables in a JSON file and using the 'jsondecode' function in each configuration still requires each independent Terraform root configuration to locally read and process that file. This approach does not provide a centralized, managed source of truth for the values; the JSON file itself would either need to be duplicated or symlinked across directories. Consequently, it suffers from similar synchronization and consistency issues as copying '.tfvars' files, as Terraform's state would not centrally manage these shared values.

  • Use a remote state data source to read the outputs from a dedicated 'globals' workspace.

    Why this is correct

    Using a remote state data source to read outputs from a dedicated 'globals' workspace is the most robust solution for sharing common configuration values. A 'globals' workspace can define and manage these shared parameters as its outputs, which are then securely stored in a remote state backend. Other Terraform configurations can then use the `terraform_remote_state` data source to directly consume these outputs, establishing a single, version-controlled source of truth and eliminating data duplication.

About these practice questions

One of 428 original TF-004 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

JA

Written by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

This TF-004 practice question is part of Courseiva's free HashiCorp certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the TF-004 exam.