TF-004 Implement and maintain state Practice Question
A company manages multiple microservices across AWS accounts. Each service has its own Terraform configuration and state file stored in a shared S3 bucket. The team uses `terraform_remote_state` data sources to read outputs from other services' state files. A service team recently changed the output structure in their state, breaking the `terraform_remote_state` calls from other services. The affected services now show errors during plan. What is the best practice to avoid such cross-service dependency issues?
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
✓
Publish service outputs to a dedicated data store (e.g., AWS SSM Parameter Store or Consul) and have other services consume those values instead of reading state directly
The best practice is to decouple services by using a dedicated data store (e.g., AWS SSM Parameter Store or Consul) as a service registry or contract. This avoids tight coupling to the internal state representation of another service. Option A correctly implements this pattern. Option D (CMDB) is overly generic and not specifically designed for Terraform state outputs. Options B and C are reactive measures, not proactive best practices.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Publish service outputs to a dedicated data store (e.g., AWS SSM Parameter Store or Consul) and have other services consume those values instead of reading state directly
Why this is correct
Publishing service outputs to a dedicated data store like AWS SSM Parameter Store or HashiCorp Consul provides a robust mechanism for inter-service communication. This approach effectively decouples Terraform configurations, preventing direct dependencies on another service's remote state file, which can be fragile and prone to breaking changes. By consuming values from a stable, versioned API, services can reliably access necessary parameters without needing direct read access to potentially sensitive or rapidly evolving state files. This promotes a more resilient and scalable microservices architecture.
- ✗
Use versioning on the S3 bucket and revert to a previous state version
Why it's wrong here
Using S3 bucket versioning to revert to a previous Terraform state version is an anti-pattern for managing infrastructure changes. While versioning protects against accidental deletions, directly reverting state can lead to significant infrastructure drift, where the state file no longer accurately reflects the deployed resources. This approach is not scalable for complex environments and risks causing outages or inconsistencies, as it doesn't automatically revert the actual cloud resources to a previous configuration. It's a recovery mechanism for state file corruption, not a change management strategy.
- ✗
Lock the state files and require approval for any changes
Why it's wrong here
Locking state files prevents concurrent Terraform operations from corrupting the state, ensuring only one `terraform apply` or `plan` modifies the file at a time. However, state locking does not inherently prevent breaking changes or logical errors within the configuration itself. While requiring approval adds a human gate, the lock mechanism itself only addresses race conditions, not the semantic correctness or compatibility of the infrastructure changes being proposed. It's a concurrency control, not a dependency management or breaking change prevention tool.
- ✗
Store outputs in a configuration management database and read from there
Why it's wrong here
Storing Terraform outputs in a generic Configuration Management Database (CMDB) and reading from there introduces unnecessary complexity and overhead. While CMDBs are valuable for asset tracking and inventory, they typically lack the direct integration and automation capabilities that dedicated secrets or parameter stores offer for Terraform outputs. This approach adds another manual or custom integration layer, making it less efficient and less "standard Terraform practice" compared to leveraging purpose-built tools designed for dynamic parameter sharing. It complicates the CI/CD pipeline without providing significant benefits over native cloud or HashiCorp solutions.
Quick reference
AWS S3 Storage Class Comparison
| Storage Class | Min Duration | Retrieval | Use Case |
|---|---|---|---|
| S3 Standard | None | Immediate | Frequently accessed data |
| S3 Standard-IA | 30 days | Immediate | Infrequent access, rapid retrieval |
| S3 One Zone-IA | 30 days | Immediate | Non-critical infrequent data |
| S3 Intelligent-Tiering | None | Immediate–hours | Unknown or changing access patterns |
| S3 Glacier Instant | 90 days | Milliseconds | Archive with instant retrieval |
| S3 Glacier Flexible | 90 days | Minutes–hours | Archive, flexible retrieval |
| S3 Glacier Deep Archive | 180 days | Hours | Long-term compliance archive |
Go deeper
Related to this question
About these practice questions
This TF-004 question is part of Courseiva's 428-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam 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.