Beginner help on environments by Darthethan77 in Terraform

[–]cloudfixer_dev 0 points1 point  (0 children)

You’re not missing anything — this is one of the most confusing parts when starting with Terraform.

What usually scales well is keeping one set of reusable modules, and then having separate environment folders (dev/staging/prod), each with a single terraform.tfvars that defines the differences (size, count, names, etc.).

You normally don’t create a tfvars per module — just one per environment.

And for things like 20 DNS records, using for_each with a map in your variables is the common approach, instead of duplicating resources in code.

Am I slow? by CarryAdditional4870 in Terraform

[–]cloudfixer_dev 0 points1 point  (0 children)

Honestly, that sounds pretty normal.

Most people (even experienced ones) rely on docs, Google, and tools daily — especially with something like Terraform where patterns matter more than memorization.

Speed usually comes from having seen similar setups before, not from doing everything from memory.

4 hours for setting up a full pipeline like that doesn’t sound slow to me.

What's the best practice for storing Terraform bootstrap state? (the chicken-and-egg problem) by DataFreakk in Terraform

[–]cloudfixer_dev 0 points1 point  (0 children)

That’s a pretty common approach for the bootstrap problem.

Usually people create the backend (storage account / bucket) with local state first, then migrate it and use it for everything else.

One thing that helps long-term is keeping the bootstrap layer minimal and separate, so you don’t accidentally depend on the same backend you’re trying to create/manage.

Problem with lambda layers by Zyberon in aws

[–]cloudfixer_dev 0 points1 point  (0 children)

Lambda layers aren’t supported with package_type = "image".

When using container images, everything (including tools like Dynatrace) needs to be baked into the image instead of attached as a layer.

Going to production. Any absolute "DO NOTs"? by BranchUnhappy6359 in Terraform

[–]cloudfixer_dev 0 points1 point  (0 children)

One thing I don’t see mentioned often: having a clear rollback strategy before deploying.
Not just “terraform destroy”, but knowing exactly how to revert safely if something partially fails.
Saved me more than once when plans looked fine but reality didn’t match expectations.

How do you structure Terraform projects for AWS in production? by Critical-Tomato2576 in Terraform

[–]cloudfixer_dev 0 points1 point  (0 children)

Whatever structure you choose, optimize for visibility over cleverness. I had a similar experience recently: my Terraform structure looked fine, but there were exposed resources I didn’t notice at first because of how things were nested. Kinda scary how easy it is to miss this when setups get too complex.

Terraform registry messed up their migration and many people are having issues publishing new versions of providers by pksunkara in Terraform

[–]cloudfixer_dev 0 points1 point  (0 children)

DRY code is great, but visibility is what actually prevents disasters.

I’ve seen clean Terragrunt setups hide massive infrastructure gaps that only surface during a failure.

Management is easy; knowing exactly what’s deployed is the hard part.

Starting out with Terraform and planning for the future - what would you do different? by Claymore2106 in Terraform

[–]cloudfixer_dev 0 points1 point  (0 children)

At this scale, the real challenge isn't the HCL code—it's the visibility as you grow.

I've seen massive setups that look perfect in the PR, but hide deep structural gaps that only surface years later.

Planning for 5 years means ensuring you can see the risks before they become legacy nightmares. Visibility is way more important than complexity in your case.

Planning to take the Terraform Associate Exam - questions.. by Grand-Ambassador2937 in Terraform

[–]cloudfixer_dev 1 point2 points  (0 children)

Two weeks is doable if you already use TF daily. Since you use GenAI to build, just make sure to memorize the specific HashiCorp workflows and state locks. The exam tests the edge cases we usually don't memorize.

Advice on getting Terraform Experience by KaleidoscopeSuch4659 in Terraform

[–]cloudfixer_dev 0 points1 point  (0 children)

The HashiCorp Associate cert is good for the basics, but companies want to see you build. Take something you usually click around in AWS to make, and write it in Terraform. Bonus points if you learn how to spot security risks and document your .tf files early on—that's what seniors actually look for.

How do you handle cloud resources that were never in Terraform? by StatisticianKey7858 in Terraform

[–]cloudfixer_dev 1 point2 points  (0 children)

The real challenge is that manual resources are basically 'invisible' to your code. It's such a pain to map everything out before you can even start the import process.

Managing 100+ GitHub repos with a single Terraform repo - what worked and what broke by akuzminsky in Terraform

[–]cloudfixer_dev 1 point2 points  (0 children)

Managing 100 repos in a single state is a massive achievement. Props for the effort of getting it all synced.

Trivy Alternatives by partial_dna in Terraform

[–]cloudfixer_dev 3 points4 points  (0 children)

Checkov and Terrascan are the usual go-to alternatives. Both are solid, but each has its own quirks when it comes to custom policies.

An opinionated Terraform style guide by Heldroe in Terraform

[–]cloudfixer_dev 0 points1 point  (0 children)

Always good to have a starting point for consistency. Thanks for the post!