Terraform

When copying root modules without updating backend configuration (key/prefix), Terraform can reference the wrong state file, resulting in destructive plans that delete infrastructure belonging to another environment or project.

Terraform stores real secret values (API tokens, database passwords) in plaintext state files and plan output despite showing (sensitive value) in the CLI. When plan files are uploaded as CI/CD artifacts, they become security liabilities if accessible to unauthorized parties.

When multiple team members and CI/CD pipelines run Terraform in parallel, concurrent writes to shared state can cause conflicting updates and painful recovery work. The terraform.tfstate file serves as the source of truth, and unreliable storage or simultaneous modifications lead to state corruption.

Renaming or reorganizing resources in Terraform code causes them to be destroyed and recreated rather than updated, risking catastrophic downtime and data loss for stateful resources like databases. There is no native refactoring capability.

State files stored locally (default) instead of on remote backends (S3, GCS) prevent team collaboration, create single points of failure, and make disaster recovery impossible. Developers must manually manage state file access.

Terraform plans with hundreds or thousands of changes are difficult for humans to review reliably. Destructive actions (resource deletion/recreation) hide in the noise of benign changes, making it easy to miss critical issues during code review.

Unlike other IaC tools, Terraform lacks a stack concept for managing collections of related resources. It only operates at the root module level, making it difficult to manage large, complex environments with multiple resource groupings without custom orchestration.

Even with version constraints in code, if the .terraform.lock.hcl file is not committed and consistently used across environments, teams experience "works on my machine" drift where different environments use different provider versions despite identical configuration.

Terraform relies on explicit references to infer resource dependencies, but real-world dependencies are often implicit (side effects, plain string IDs). When Terraform cannot see these relationships, it fails to determine correct resource ordering, causing apply failures or resource conflicts.

Managing many resources in a single Terraform state increases blast radius (a single error affects many resources), slows plan/apply execution, and prevents new changes if any resource drifts. Resource drift in one resource blocks the entire apply.

Moving resources between state files or across state boundaries is not supported by terraform mv or other built-in tools. Teams must manually edit JSON state files or write custom tooling to reorganize infrastructure across projects or environments.

Terraform lacks a robust, built-in testing framework for HCL. Unit testing is difficult and integration testing (spinning up real infrastructure) is slow and expensive. Teams resort to embedding validation scripts or hacks, leading to accidental infrastructure drifts reaching production.

Large Terraform applies trigger API throttling (429 errors) when hitting per-account or per-region cloud provider limits. Additionally, eventually-consistent cloud services may not reflect changes immediately, causing subsequent API calls to fail or return stale data.

Teams circumvent Terraform workflows by making changes directly in cloud provider consoles, causing state files to become out of sync with actual infrastructure. This drift prevents accurate planning and can lead to unexpected behavior during subsequent Terraform operations.

Terraform users struggle to bring existing infrastructure stacks under management because Terraform cannot automatically incorporate them into its state without manual intervention.

Automation pipelines and scripting struggle to handle stateful resource management and state logistics across multiple code paths, despite being critical for continuous integration.

A HashiCorp survey revealed that more than half of Terraform users encounter state-related problems, indicating widespread technical complexity and inadequate state management solutions.

Azure Functions have poor documentation focusing on GUI-based VSCode approaches. Infrastructure-as-code provisioning requires understanding undocumented file structure requirements scattered across 300+ screenshots. Troubleshooting is difficult due to the .NET runtime abstraction.

Terraform Azure provider has significant gaps relative to the underlying Azure API. Operations work via Azure Portal or PowerShell but fail through Terraform, with documentation lacking explanations for why operations are required or API limitations.

Product teams want higher-level abstractions and self-service capabilities for infrastructure provisioning. Many teams are adopting CDKTF or building internal platforms to bridge the gap, indicating Terraform's abstraction layer is insufficient for modern development velocity.

Using Terraform workspaces to manage multiple environments (dev, staging, prod) requires heavy use of count parameters and conditional expressions, making code difficult to read and understand. Scaling across environments becomes increasingly complex as interconnections multiply.

By 2025, basic IaC, CI/CD, and Kubernetes are assumed baseline. The real challenge is maintaining reliability, compliance, and cost efficiency while keeping systems fast. Regulators tighten controls, CFOs scrutinize cloud spend, and engineers expect zero impact from operational constraints.

Complex Terraform deployments with modules, multiple environments, split state, and orchestration tools like Terragrunt create challenging issues that require structured planning and disciplined workflows.

CloudFormation is AWS-specific and not portable to other cloud providers, creating vendor lock-in. Developers prefer third-party tools like Terraform and Ansible for portability.

Terraform community edition lacks built-in mechanisms for cross-team resource sharing, forcing organizations without Terraform Enterprise to build custom state management solutions or invest in expensive enterprise licensing.

Working with domain-specific languages like Terraform requires excessive prompt engineering with Gemini CLI. The model struggles with DSL semantics, necessitating detailed and repetitive prompt tweaking to achieve correct results.

Terraform's flexibility allows each team to develop unique patterns: custom modules with different naming conventions, varying CI workflows (from simple apply to 8-step pipelines), conflicting use of Terragrunt, and different apply strategies. This fragmentation creates tribal knowledge and complicates onboarding.

Terraform core development moves slowly with minimal innovation, and many important long-standing PRs fixing critical bugs or adding key features languish for months without maintainer attention. In contrast, the AWS provider releases weekly but has poor core team responsiveness.

Integrating Nginx into CI/CD pipelines requires manual scripting or specialized tools like Jenkins and GitLab CI/CD. The project lacks built-in automation for service reloading and configuration updates, necessitating third-party tools like Ansible or Terraform.

Heavy reliance on Terraform modules and resources specific to particular cloud providers can create inadvertent vendor lock-in, making migration between providers difficult and expensive.

Terraform can build secure, repeatable infrastructure landing zones, but cannot automate all required components like identity, pipelines, and secrets management, leaving gaps in the automation model.

The source and version attributes in Terraform's module block reject variable interpolation, preventing dynamic module sourcing. This limitation breaks flexible, parameterized module management patterns and forces hardcoded or copy-paste module references.

Terraform and IaC configurations are written once and abandoned in repositories without version control, linting, testing, or maintenance. This creates technical debt and makes debugging pipeline regressions impossible.

Terraform's August 2023 BSL 1.1 license change creates legal uncertainty for organizations redistributing Terraform, embedding it in products, or offering IaC as a hosted service. The ambiguous definition of 'competitive' products triggers legal review and delays infrastructure platform roadmaps.

Initial Terraform tasks (provisioning a bucket) appear simple, but complexity emerges across backends, providers, variables, modules, environments, workspaces, and dependency management. Understanding what code actually does in production requires deep system knowledge.

Cramming numerous resources, data sources, and variables into single .tf files becomes increasingly difficult to navigate, troubleshoot, and collaborate on as infrastructure expands, slowing down team productivity.

Terraform's merge() function only performs shallow merging, not deep merging of nested maps and objects. This prevents clean composition of default configurations with user-supplied overrides and makes merging multi-level data structures awkward.

DevOps engineers waste significant time on repetitive, non-complex tasks: writing Terraform templates, composing cloud CLI commands, parsing JSON, and analyzing logs manually. These tedious activities steal attention from solving real problems and driving strategic improvements.

Unlike application code, infrastructure can only have one version deployed at a time. Keeping multiple long-lived branches in a Terraform repository is not common practice, limiting collaboration models and creating merge complexity.

Terraform error messages are often baffling, especially with complex modules or provider bugs. Documentation quality varies widely and lacks sufficient detail. Error context is insufficient for troubleshooting, making debugging slow and frustrating.

The Terraform configuration language (HCL) is unintuitive compared to standard programming languages. Concepts like conditional logic, looping with for_each, and mapping collections are unnecessarily cumbersome. Few developers have deep Terraform experience, slowing team onboarding.

DevOps engineers constantly switch between different IaC formats and tools: Terraform, Helm charts, Kubernetes YAML. IDE and editor support is inconsistent—autocompletion and validation work for some tools but not others, forcing context switching and manual work.

Terraform requires manual, repetitive copy-paste of provider configuration across multiple modules and environments. This duplication increases maintenance burden and introduces errors when updating provider settings.