TF-004 Understand Terraform basics Practice Question
A company has a monolithic Terraform configuration that manages all infrastructure. As the infrastructure grows, plan and apply times become very long. They want to break the configuration into smaller, independent units to improve performance and reduce blast radius. Which approach should they take?
⚠ Common exam trap
Candidates often confuse Terraform modules (which are reusable components within a single root module) with root modules (which are independent stateful configurations), leading them to choose Option A instead of B.
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 root modules, each with its own state file, and use data sources to share outputs
Splitting the monolithic configuration into separate root modules, each with its own state file, reduces the scope of `terraform plan` and `terraform apply` operations, improving performance. Using data sources to share outputs between root modules allows independent management while maintaining necessary dependencies, which also reduces the blast radius by isolating failures to a single root module.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Refactor into multiple Terraform modules and use a single root module
Why it's wrong here
Refactoring into multiple Terraform modules within a single root module primarily provides organizational benefits, improving readability and reusability of infrastructure code. However, it does not address the core issues of a monolithic configuration, as all resources defined across these modules are still managed by a single Terraform state file. Consequently, every `terraform plan` and `apply` operation will process the entire infrastructure, leading to long execution times and a large blast radius for any changes.
- ✓
Split the configuration into separate root modules, each with its own state file, and use data sources to share outputs
Why this is correct
Splitting the configuration into separate root modules, each managing a distinct subset of infrastructure with its own state file, is the recommended approach for large-scale deployments. This strategy significantly reduces the blast radius of changes, as an issue in one module's apply operation will not affect others. It also drastically improves `terraform plan` and `apply` performance by allowing operations to target smaller, independent scopes, with outputs shared between modules using data sources like `terraform_remote_state`.
- ✗
Use Terraform workspaces to separate environments
Why it's wrong here
Terraform workspaces are designed to manage multiple, logically separate instances of the *same* configuration, typically for different environments (e.g., dev, staging, prod). While workspaces create distinct state files (e.g., `terraform.tfstate.d/default/terraform.tfstate`), each of these state files still represents the *entire* monolithic configuration. Therefore, workspaces do not reduce the size of the state file, decrease plan execution times, or limit the blast radius of changes for a large, single configuration.
- ✗
Use terraform state mv to reorganize resources into different state files
Why it's wrong here
The `terraform state mv` command is a low-level, manual operation used to move individual resources or entire modules within or between Terraform state files. While it can be used to surgically reorganize state, it does not automatically refactor the underlying HCL configuration or provide a scalable, architectural solution for breaking down a monolithic setup. It's a tool for specific state management tasks, not a design pattern for decoupling infrastructure.
Quick reference
AAA Protocol Comparison
| Protocol | Port(s) | Encryption | Transport | Primary Use |
|---|---|---|---|---|
| RADIUS | 1812 / 1813 | Password only | UDP | Network access control |
| TACACS+ | 49 | Full packet | TCP | Device administration |
| Diameter | 3868 | Full session | TCP / SCTP | Carrier / mobile networks |
| 802.1X | — | EAP-based | Layer 2 | Port-based access control |
TACACS+ encrypts the entire packet; RADIUS only encrypts the password field — a key exam distinction.
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.