TF-004 Use Terraform outside the core workflow Practice Question
A team has a monolithic Terraform configuration managing multiple AWS accounts. They want to decompose it into smaller configurations that can be managed independently. What is the recommended strategy?
⚠ Common exam trap
A common misconception in the Terraform exam is that Terraform workspaces (or Terraform Cloud workspaces) are a valid decomposition strategy, but they only separate state files for the same configuration, not the configuration itself, which fails the requirement for independent management.
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
✓
Split the configuration into separate directories per account and resource type, and use remote state sharing.
Splitting a monolithic Terraform configuration into separate directories per account and resource type, combined with remote state sharing, enables independent management of each configuration while allowing them to consume outputs from one another via `terraform_remote_state` data sources. This approach aligns with the recommended practice of using separate root modules for distinct environments or accounts, avoiding tight coupling and state lock contention.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Split the configuration into separate directories per account and resource type, and use remote state sharing.
Why this is correct
Splitting a monolithic configuration into separate directories, perhaps by account or resource type, creates smaller, more manageable units of infrastructure. Each directory then manages its own independent state file, typically stored remotely (e.g., S3, Azure Blob Storage, Terraform Cloud). This approach allows different teams or individuals to work on distinct parts of the infrastructure concurrently without interfering with others, facilitating independent deployment, testing, and lifecycle management for specific components or environments. It directly addresses the challenges of a monolithic setup by promoting modularity and reducing blast radius.
- ✗
Use Terraform workspaces to separate environments within the same configuration.
Why it's wrong here
Terraform workspaces are designed to manage multiple distinct state files for a *single* Terraform configuration, primarily for separating environments like `dev`, `staging`, and `prod` within the same codebase. While they provide state isolation, they do not decompose the underlying monolithic configuration code itself. All resources across all workspaces are still defined within the same set of `.tf` files, meaning changes to the configuration still affect the entire codebase, making independent management and true code decomposition impossible.
- ✗
Create a single super-module that contains all resources.
Why it's wrong here
Creating a single 'super-module' that encapsulates all resources from the monolithic configuration would consolidate all infrastructure definitions into one large, complex module. This approach fundamentally contradicts the goal of decomposition, as it merely shifts the monolithic structure from a root configuration to an even larger, more tightly coupled module. Such a design would significantly increase complexity, reduce readability, and make independent management or targeted changes exceedingly difficult, exacerbating the issues a monolithic configuration presents rather than solving them.
- ✗
Move everything to Terraform Cloud and use different workspaces.
Why it's wrong here
While moving to Terraform Cloud provides benefits like remote state management, collaboration features, and run environments, using different workspaces within a single Terraform Cloud *configuration* does not address the core problem of a monolithic codebase. Similar to local workspaces, Terraform Cloud workspaces manage separate state files for the *same* underlying configuration. The entire monolithic code would still be processed for every run, hindering independent development, increasing plan times, and maintaining a large blast radius for changes, thus failing to achieve true code decomposition.
Go deeper
Related to this question
About these practice questions
Courseiva writes every TF-004 question from scratch — 428 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
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.