HashiCorp Status

HI :),

I recently built a small VS Code extension called Terraform Companion.

It works alongside the official HashiCorp Terraform extension; it doesn't touch formatting, completion, or validation—instead, it fills gaps left by terraform-ls.

Here's what it adds to your workflow:

• Hover Context: Hover over var.* or local.* to see what each value actually resolves to, along with its provenance (for example, exactly which .tfvars file or module call site it comes from).
• Version CodeLens: Displays a CodeLens on provider and module version constraints, showing how far behind your dependencies really are instead of only the minimum version you've specified.
• Safe count to for_each Refactoring: Provides a quick fix to rewrite count to for_each. It first checks for index-based references, so it won't even offer the refactoring if it would break your code.
• Extra Linting: Detects unused locals, redundant depends_on blocks, and overly loose version constraints (ex. registry modules with no version)
• .terraform Cache Cleanup: On startup, it scans for .terraform directories that haven't been modified in over 30 days and prompts before deleting them. If you have dozens of project (like me), this alone can free up gigabytes of disk space. It never touches Terraform state, never follows symlinks, and only deletes directories named exactly .terraform.

Privacy: Everything runs locally except the version lens (registry lookups, cached for 6h default value)

Marketplace Link: Terraform Companion

Feel free to share feedback here or open a GitHub issue if something's confusing or if there's a feature you'd like to see

Hi all,

I’m currently working on a helpdesk at an MSP and trying to move into a cloud role. I’ve passed my AZ‑104 and built a few Azure projects to show my understanding. I’ve been applying for cloud jobs every day, but I’m not getting any responses yet.

I’m considering starting the Terraform Associate 004 revision, but I don’t want to become a “cert hero” with no real experience. For those who’ve made the jump into their first cloud job, would getting the Terraform cert help, or should I focus on something else to improve my chances?

Any advice would be really appreciated.

Hi All,

I am new to Terraform so any support will be appreciated.

Only the last couple days I have been working on building my config files (main, outputs, variables) and deploying and deleting a range of resources in Azure.

I now want to know how to import existing resources into my state file.

From what I am reading, you create an import block and reference your resources.

next shout was this but not sure how well it works - Azure/aztfexport: A tool to bring existing Azure resources under Terraform's management

also i would like to work towards the Terraform Associate exam, if anyone has any feedback or training material you would recommend before taking the exam, that would be great.

I've been using HCP dev tutorials for my prep, anyone found any other training material to be more suitable or is this the best o learn from?

Security scanners check config against rules. Diff-Linter checks a change against what was actually authorized. Looking for some one to test it out and tell me what it got right and what it got wrong.

You give it four things: what the change should do, what it must NOT touch, before config, after config. It audits the diff against that contract flags anything undeclared, checks every stated prohibition explicitly, and labels every finding by evidence level (what the diff proves vs. what would need terraform plan to confirm).

Built-in example: a staging-only capacity bump implemented by editing a shared module default so production silently inherits it too. Not a rule violation. A scope violation.

Full-featured IaC reviewers exist and do real plan/state analysis. This is the zero-setup, no repo access, no config file, just a sentence of intent and a diff, right now version.

There's also a /loop that re-audits your fix including whether the fix itself introduced something new. In testing, it caught a repair that fixed the scope issue while quietly stripping type validation from the shared module.

Free demo, no signup. Paste a real diff (sanitized), tell it the intent, see what it flags.

https://claude.ai/public/artifacts/182e4450-70d7-4ceb-8aab-f72484305211

Doing an audit before a big refactor and what stopped me was how much is running that no module owns. Not drift exactly, more resources that got clickopsed during an incident years ago and quietly became load bearing, plus things left behind when a stack got partially destroyed and a few resources survived on dependencies.

Rough count is a few hundred. Some are obviously dead. plenty are ambiguous, an EBS volume thats detached but somebody might have been keeping it deliberately, that sort of thing, and the person who would know left 2-3 yrs ago.

Importing it all into state sounds sensible until you weigh the effort against just deleting things and finding out what breaks, which is not something I can propose to my manager with a straight face.

How are you handling the archaeology part of this. Mostly I want to know how you decided what was safe to remove, the tooling side I can work out myself.

The follow-up to my Beginner episode I posted here is finally out.

Part 2 of this planned Azure Terraform series shifts away from simply deploying resources and focuses more on programmatically approaching Terraform.

Topics covered include:

• Functions
• Conditionals
• Operators
• Loops
• Dynamic Blocks
• For Expressions & Splat
• Validations (including Check Blocks and Pre/Post Conditions)
• Nested Types (including complex variable types)
• Provider Aliases (deploy across multiple Azure subscriptions)
• KISS vs DRY
• And much more...

Rather than jumping between unrelated examples, everything is built around a single Azure project so each concept is introduced naturally as the deployment grows in complexity.

We definitely over-engineer this project just to teach these programming concepts, but understanding them will help you write much more flexible & dynamic Infrastructure as Code.

With that, our roadmap continues!

• Beginner Episode : Understand Terraform (learn the foundations and core concepts that make Terraform work)
• Intermediate Episode : Program Terraform (use loops, functions, conditionals, dynamic blocks, etc)
• Advanced Episode : Structure Terraform (introduce modules, remote state in azure storage, workspaces, imports, etc)
• Professional Episode : Operationalize Terraform (use GitHub, CI/CD, pull requests, state management, and deployment workflows to work in a team environment)
• Solution Episode(s): Build Azure Projects (We'll pretend to take assignments from Cloud Architects and design, deploy, and manage complete Azure solutions using Terraform)

Link to Episode: https://www.youtube.com/watch?v=QwXqLAvmKac

Hi everyone,

I'm a Terraform beginner and I'm curious about how Terraform is managed in enterprise environments.

How do you typically structure your Terraform code for multiple environments (dev, qa, stage, prod)? Also, how do teams collaborate on Terraform infrastructure? For example, how do multiple engineers work on the same codebase, review changes, and avoid conflicts?

I'd love to hear about your folder structure, workflow, and any best practices you've learned from working in production.

Thanks!

I took the HashiCorp Certified: Terraform Associate (004) exam recently and I'm happy to share that I passed! 🎉

Here are the resources and tips that helped me:

• I completed Bryan Krausen's Terraform Associate course, which does an excellent job explaining the core Terraform concepts.
• I created my own preparation notes while studying. I've made them open source on GitHub: https://github.com/Raghul-M/Terraform-Associate-Certification

The repository covers:

• Terraform workflow (init, plan, apply, destroy)
• Providers & Resources
• Variables and terraform.tfvars
• Modules (Root Module, Child Module, Inputs & Outputs)
• State Management (terraform.tfstate, remote state, state locking)
• Backends
• HCP Terraform
• Security & Secret Management
• Common exam concepts questions and interview notes

Important topics to focus on:

• Terraform workflow
• State & Remote Backends
• Providers vs Backends
• Variables (variables.tf, terraform.tfvars, environment variables)
• Modules (especially Inputs vs Outputs)
• HCP Terraform
• State commands (terraform state list, show, rm)
• Security (sensitive = true, handling secrets)
• .terraform.lock.hcl and Terraform-generated files
• Terraform CLI commands and common flags

My preparation tips:

• Don't just memorize commands understand why Terraform maintains a state file and how it uses it during plan and apply.
• Practice creating small reusable modules and understand how values flow between parent and child modules.
• Be very clear on Providers vs Backends and Variables vs Outputs—these are common areas where questions can be tricky.
• Know which files should and should not be committed to Git (terraform.tfstate, .terraform/, .terraform.lock.hcl, etc.).
• If you're already familiar with Kubernetes or cloud platforms, relate Terraform concepts to real infrastructure instead of treating them as isolated exam topics.

If anyone is preparing for the Terraform Associate exam and has questions, feel free to ask. Happy to help, and I hope the notes save someone a few hours of preparation.

Good luck with your exam! 🚀

What it does:

• Pulls live from the HashiCorp Status API, shows all 62 components (HCP Terraform, Vault, Consul, the registry itself, regional endpoints) with green/yellow/red dots
• Active incidents + recent resolved ones with timestamps
• Key official provider versions pulled live from the registry (aws, azurerm, google, kubernetes, vault, consul, helm, etc.)
• Searchable provider browser, filter by official/partner/community, search by name
• Quick links to every HashiCorp doc, registry page, cert path, and community resource I kept re-Googling
• Live Web Alerts when services are down
• Email notifications / alerts per your preferences
• Fully automated Provider Release summery by TCv7 (platform AI)

Auto-refreshes status every 60 seconds. Auto updates via Hashicorp APIs

No login required. Free to use.

→ https://www.terraformacademy.app/max/hashicorp-hub.html

i used to think good monitoring meant collecting everything Prometheus could scrape and building big Grafana walls. After a few ugly incidents as the on call, i care a lot less about pretty charts and a lot more about fast signal.

Our monitoring only got useful when we tied it to service level objectives and error budgets, not "all metrics forever." We moved to a handful of user journey synthetics, a small set of service health metrics, and logs that were structured enough to query under stress. The infra views came after that. One surprise was how often monitoring itself drifted: alerts disabled temporarily, thresholds changed without review, dashboards referencing resources that no longer existed. We ended up treating alerting rules and dashboards as code too, which is the only reason drift aware tooling catches monitoring rot instead of just cloud resource drift and it has been key to keeping monitoring aligned with reality.

If you have been on the hook for fixing things at 3 am, how did you decide what to monitor and keep it from rotting as fast as the systems it covers?

Hi everyone,

I have one voucher for the HashiCorp Terraform: Authoring and Operations Professional exam, valid until September 30, 2026.

Originally, I planned to take the Professional exam, but I realized I don't have much hands-on experience with Terraform yet, and I'm worried I haven't had enough practical experience to be ready for the Professional level.

Because of that, I'd prefer to take the Terraform Associate exam instead.

I'm looking to trade my Professional voucher for an Associate voucher, but I'm also open to selling it for a reasonable price.

If you're interested, or know someone who might be, feel free to comment or send me a DM. Thanks!

Thought I'd share my approach to providing self-service infra and Terraform modules in GitLab! Anyone else doing something similar?

ive passed the HashiCorp Terraform assosiate 004 finally.
it took me about 3 weeks and 3 days in practice exams .
i used Bryan Krausen's course on kodekloud + its practice exams on udemy .
the exam was as good as u take it seriously dont panic !
wish all good luck ! am here if u need help to prepare or advices Thank u!

As a freelancer working across several client orgs, I kept hitting the same wall: one laptop, multiple Terraform Cloud accounts. The CLI credentials model is one token per hostname, so terraform login for client A clobbers client B — and everything lands in a plain-text `credentials.tfrc.json` anyway.

So I built tfvault (https://github.com/tedilabs/tfvault):

- Pluggable secret backends — OS keyring, pass/gopass, env vars behind one binary (Vault, 1Password, AWS SM planned)

- Profiles — each .terraformrc (via TF_CLI_CONFIG_FILE) points at its own isolated credential set, so the same hostname resolves to different tokens per client

- Tokens never touch argv, logs, or plain files; tfvault status diagnoses the whole plugin → terraformrc → profile → backend chain

There are great tools in this space already (terracreds, terraform-credentials-keychain) — tfvault's angle is the multi-account isolation plus letting each engineer pick their preferred backend under one standard helper.

Apache-2.0, macOS/Linux. brew install tedilabs/tap/tfvault

Still early — feedback and backend requests very welcome!

As I'm sure many of us do, I work for companies using Terraform/Opentofu in the enterprise where security compliance is a big thing and security professionals don't particularly take the time to triage and authorise tool requests themselves so often come down on the side of declining the requests.

One thing I keep hitting is trying to use community-based Terraform providers from a compliance point of view - a terraform provider with very little, I'll call it, github activity, stars, commits etc.

I get it, unverified/unvetted provider code which are merely go executables with their own supply chain risks - running them in production environments with what is usually quite privileged creds.

Firstly, how do people overcome this with their security teams and what mitigations do they put in place?

e.g. Does anyone actually go to the lengths of forking repositories, reviewing code and then building yourself?

Hey all, co-founder here. We released Cynative, an open-source CLI agent that does deep security research across your infrastructure.

The problem we were trying to solve: security research (attack paths, blast radius, triage, threat hunting, etc.) requires reasoning across code, cloud and runtime at once - and no existing agent could do that with credential-level guarantees it won't modify anything. So we built it read-only by construction, not by policy.

How that works:

• Action gate: every operation is resolved to its required IAM actions and authorized against the native providers' read-only definition before any credential is attached. Fails closed on anything classified as a write.
• Network pinning: every request host is pinned to its mapped service and region.
• Sandboxed code execution: for bulk work ("check every public S3 bucket") it writes and runs JS in an internal sandbox that can only call the tools we expose and has no access to your host.
• Audit log: every tool call recorded to a fail-closed JSONL log.

Other bits:

• Connectors for AWS, GCP, Azure, Kubernetes, GitHub and GitLab using the creds already in your shell
• Runs entirely in your environment - nothing leaves your infra except your LLM calls
• Adversarial verification: an independent verifier agent challenges each finding, cross-checking it against your live environment
• BYOM via the embedded Bifrost SDK, including Ollama and vLLM for fully local
• Enterprise-friendly - Apache-2.0, single static Go binary

Repo: https://github.com/cynative/cynative

Happy to answer anything about the architecture - and if you can break the read-only enforcement, please tell us.

I'm troubleshooting the infamous error message:

The "for_each" map includes keys derived from resource attributes that cannot be determined until apply. When working with unknown values in for_each, it's better to define the map keys statically in your configuration and place apply-time results only in the map values.

Terraform binary and Google provider are latest version. At a high level, I'm doing pretty simple stuff:

1. Create a VPC network by calling a 'vpc' module, with the project ID & network name managed via variables
2. Create a Network Firewall Policy and associate it to above VPC network by calling a 'network-firewall-policy' module. The VPC network is passed by sending the VPC network self link from the vpc module's output.

Since the child module supports associating multiple networks to a single firewall policy, it does a loop when doing the association, and that's when terraform complains. This doesn't make sense, because the 'name' is known at plan time - it's just the name of each VPC network. As a dumb work-around, I can do this:

#networks       = [module.vpc.self_link]
networks        = ["projects/${local.project}/networks/${local.network_name}"]

But that doesn't address the root issue. So I'm looking for similar open-source code that may provide clues on how to avoid or mitigate this, and found this example:

https://github.com/terraform-google-modules/terraform-google-network/blob/main/modules/network-firewall-policy/main.tf

Specifically this line:

resource "google_compute_network_firewall_policy_association" "vpc_associations" {

for_each = local.global && length(var.target_vpcs) > 0 ? { for x in var.target_vpcs : base64encode(x) => x } : {}

I have definitely never seen this before. What would be the reason for generating a base64 encoded value to use as key? The VPC network self link is already unique, and is a valid key.

Good afternoon, I’ve recently been looking for discounts or vouchers to take the exam; are there any available? P.S.: In case it helps, I’m a high school student from brazil(i've heard students can get discounts).

Feel free to create a pull request if you see any bugs or issues, or want to suggest an improvement.

For example, I originally had a single module called all-vms-conf that managed more than 1,700 resources. As the infrastructure grew, every CI/CD job started taking a long time because Terraform had to process the entire state, even for small changes.

To solve this, I split the configuration into multiple modules based on service and environment.

Instead of having a single module:

all-vms-conf/
└── main.tf

I reorganized it like this:

mongo-vms/
├── dev/
│   └── main.tf
├── stage/
│   └── main.tf
└── prod/
    └── main.tf

postgres-vms/
├── dev/
│   └── main.tf
├── stage/
│   └── main.tf
└── prod/
    └── main.tf

redis-vms/
├── dev/
│   └── main.tf
├── stage/
│   └── main.tf
└── prod/
    └── main.tf

With this structure, a change only affects the specific service and environment being modified, rather than forcing Terraform to evaluate the entire infrastructure.

After splitting the state and configuration this way, our CI/CD execution time was reduced by approximately 3–4×.

tf-triage is a lightweight open-source tool written in Go that instantly turns messy infrastructure logs into clean, AI-generated summaries right inside your GitHub or GitLab PR comments.

🔒 100% Local: Run it via Ollama so your cloud blueprints never leave your machine.
☁️ Cloud Option: Connect it to cost-efficient models like DeepSeek and Gemini.

Check out the repo here: https://github.com/balmha/tf-triage

#Terraform #OpenSource #IaC

Most IaC repos don't fail all at once — they decay over time. One clean Terraform file becomes a second environment, then someone copies the prod folder, forgets to update a value, and on and on.

We wrote a field guide on the repo structure we actually use ourselves: a hierarchy that mirrors account → region → service, config inheritance so you define shared settings once, tags that flow through the directory tree, isolated state files to limit blast radius, and Terragrunt Stacks that describe a full service in one file.

Includes working open-source examples and an incremental adoption path — no big-bang migration required.

Read the guide →

Hi all!

We are using Terraform incorrectly, and the same can be said for almost all DevOps CLI tools. These tools should only call APIs and implement the lifecycle of a resource. The problems started when we decided to give them more responsibilities, such as managing dependency graphs, execution order, and parallelism. Now we are stuck because they no longer compose well. Our workarounds have become brittle scripts used to glue together Terraform, Kubectl, and Ansible.

The solution is to keep the dependency graph in code:

• One graph for any tool: Standardize the workflow across your entire stack.
• Multiple graphs for actions beyond just create and delete: Easily handle workflows like backups, validation, and cost analysis.
• Aspect-Oriented Programming (AOP): Change behavior without changing the core infrastructure code. For example, a Terraform Backend is just a slight behavioral shift, a dry-run is just an "around" advice, and multi-cloud provisioning is just a "before" advice.

I have written my own implementation in Python, TypeScript, and Clojure, but you can easily ask an AI agent to build your own library in five minutes and finally take your infrastructure to the next level.

Just for reference, please build your own library in your favorite language.

https://github.com/amiorin/red (TypeScript)

https://github.com/amiorin/green (Clojure)

https://github.com/amiorin/blue (Python)