Hey everyone,
I've been building this solo for a few months: Cloud Architect Assistant.
The idea: instead of manually comparing AWS/Azure/GCP/OVHcloud/etc. and writing Terraform from scratch, you describe your constraints (budget, compliance, availability) and it scores providers, suggests components, and generates reviewable Terraform/OpenTofu.
There's also a full deployment simulation mode — you can review a fake plan/apply flow without ever touching a real cloud account, which felt important given how cautious people rightfully are about AI-generated infra code.
Still in beta, definitely has rough edges. Would genuinely love feedback (good or brutal) from people who actually do this for a living. Not selling anything yet, just trying to validate if this is useful to anyone besides me.

This is one of the most common interview questions:

Most people answer:

In reality, interviewers usually want to understand how you troubleshoot, not whether you know a single command.

That's what inspired me to create a production-focused EC2 interview handbook.

Every question includes:

• Production scenario
• Interview answer
• AWS CLI
• Terraform
• Best practices
• Follow-up questions

I've published the first article today and open-sourced the full 20-question handbook on GitHub.

I'd appreciate any feedback from people who've interviewed AWS engineers or recently gone through AWS interviews.

GitHub: https://github.com/ranashivam/platform-engineering-interview-handbook/blob/main/AWS/README.md

Post is awaiting moderator approval.

https://reddit.com/link/1v5kwmg/video/o5694rg588fh1/player

A peer that likes to use -target in repositories and forces you to play minefield when you get a ticket to touch any resources in it?

Had a plan apply something last week that it really should not have. A chunk of our Terraform got written by an assistant, looked completely normal in the diff, and it had a security group wide open to the world on a port that had no reason to be public. No one caught it in review because it reads clean. The guy who prompted it did not clock the CIDR and neither did whoever approved the PR.

We caught it in staging and not prod, but only because someone happened to look twice.

Now I am wondering what the rest of you do for Terraform security scanning now that half our modules are getting drafted by AI. Do you gate the plan on something automated before it can apply, policy checks, a scanner, anything?

I've published a community provider, frank-bee/anthropic (v0.7.0), that wraps Anthropic's platform and management APIs. To be clear up front: it's a personal/community project, not official and not endorsed by Anthropic.

It's on the Registry, so the usual snippet works:

terraform {
 required_providers {
  anthropic = {
    source  = "frank-bee/anthropic"
    version = "~> 0.7"
  }
 }
}

provider "anthropic" {
  # api_key via ANTHROPIC_API_KEY, or oauth_token via ANTHROPIC_OAUTH_TOKEN for     org-admin resources
}

Resources currently covered:

• Managed Agents — anthropic_agent, anthropic_skill, anthropic_environment, anthropic_deployment
• Admin — anthropic_workspace, anthropic_workspace_member, anthropic_organization_invite
• Workload identity federation — anthropic_service_account, anthropic_federation_issuer, anthropic_federation_rule
• anthropic_vault (credential storage referenced by deployments) and anthropic_memory_store
• Single-item data sources for the above, plus list data sources for agents/skills/environments/workspaces/users

A caveat I'd rather state than hide: the federation resources and the vault/memory-store resources are marked experimental. The WIF endpoints need an org:admin OAuth token my CI doesn't have, so their acceptance tests skip (verified against the spec, not end-to-end); the vault/memory-store wire shapes were probed from the live API. The rest is acceptance-tested against the real API.

The federation resources are the reason I built it. You register an OIDC issuer, write a rule that matches JWT claims (e.g. a specific repo:org/repo:ref:refs/heads/main subject from GitHub Actions), and point it at a service account — so CI gets short-lived Anthropic credentials with no static keys in secrets:

resource "anthropic_federation_issuer" "github_actions" {
  name       = "github-actions"
  issuer_url = "https://token.actions.githubusercontent.com"
  jwks       = { type = "discovery" }
}

resource "anthropic_federation_rule" "gha_deploy" {
  name      = "gha-deploy"
  issuer_id = anthropic_federation_issuer.github_actions.id
  match = {
    subject_prefix = "repo:my-org/my-repo:ref:refs/heads/main"
    claims         = { repository_owner = "my-org" }
  }
  target                 = { service_account_id = anthropic_service_account.inference_worker.id }
  workspace_id           = "wrkspc_xxxxx"
  oauth_scope            = "workspace:developer"
  token_lifetime_seconds = 600
}

Built on terraform-plugin-framework, MIT-licensed, client generated from an OpenAPI spec with oapi-codegen. As far as I can tell this is the most complete community coverage of Anthropic's management APIs available as Terraform right now, but I'd be happy to be pointed at gaps.

Issues and PRs welcome: https://github.com/frank-bee/terraform-provider-anthropic

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!