r/Terraform

I have successfully cleared the 004 certification

I had experience with Terraform 6-9 months

Followed zeal vora's Udemy course

Did his practice tests

The exam was not so hard, but a little tricky

If you prepare correctly, it is easy to crack.

I built a small tool to catch infra risks before production releases
I’ve been working on a project called Beacon.
The idea came from a very practical problem I’ve seen in distributed systems: before a release, teams usually have dashboards, logs, Terraform files, Kafka configs, Kubernetes manifests, runtime snapshots, etc. But still, the actual question is usually very simple:
“Is this system safe enough to release to production?”
Beacon tries to answer that.
It scans infrastructure/config/runtime inputs and gives a production-readiness decision with ranked risks, possible root causes, and suggested next actions. Right now it has examples around Kafka, Kubernetes, Terraform, Helm, runtime snapshots, OpenTelemetry, Prometheus, Schema Registry, CI/CD, and flow degradation.
This is not meant to replace observability tools. The way I think about it is:
Observability tells you what is happening.
Beacon tries to tell you what is risky, why it matters, and what should be fixed first.
You can try the demo without setting up Python locally.
Run the UI with Docker:

docker pull ghcr.io/mishraricha1806/beacon:latest

docker run --rm -p 8765:8765 ghcr.io/mishraricha1806/beacon:latest ui --host 0.0.0.0 --port 8765

Then open:

http://127.0.0.1:8765/

For the simplest demo, use the sample bad infrastructure example from the repo:

examples/bad-infra/

In the UI, choose the static/readiness input, upload the files from that folder, run the scan, and check the readiness score, top reasons, grouped risks, and next actions.
You can also run the same demo from CLI:

docker run --rm \
  -v "$PWD:/workspace/project:ro" \
  ghcr.io/mishraricha1806/beacon:latest readiness static \
  /workspace/project/examples/bad-infra \
  --environment prod \
  --no-html \
  --no-open-report

Expected result is the tool should flag the setup as NOT READY, with risks like replication, storage/message-size, and missing governance context.
There is also a Black Friday style demo for payment/event pipeline readiness:

docker run --rm \
  -v "$PWD:/workspace/project:ro" \
  ghcr.io/mishraricha1806/beacon:latest readiness all \
  --static-path /workspace/project/examples/demo-black-friday \
  --snapshot /workspace/project/examples/demo-black-friday/runtime-snapshot.yaml \
  --environment prod \
  --no-html \
  --no-open-report

Repo: https://github.com/mishraricha1806/beacon
I’d be interested in feedback from people who work with Kafka, Kubernetes, Terraform, platform engineering, SRE, or release governance.
Mainly looking for thoughts on:

• Does this kind of readiness gate feel useful before production releases?
• What signals would you expect such a tool to check?
• Would you prefer this as a CLI, CI/CD gate, or lightweight UI?

GitHub

GitHub - mishraricha1806/beacon: Detect infrastructure risks before production.

This is mainly for people running Terraform at scale with Spacelift or similar tools. Many of the Spacelift alternatives content I have found is just tool lists: env0, Terraform Cloud or HCP, Scalr, Atlantis, Terrateam, Terramate and so on. That is fine for awareness, but it does not answer the real question for us: if your pain points are drift detection and cloud asset visibility, what should you switch to?

By better drift detection and cloud asset visibility, I mean continuous detection of changes that never went through Terraform, a clear view of what percentage of your estate is codified and visibility into unmanaged resources sitting outside Terraform. I know that last part pushes past what a TACO things like Spacelift is built to do on its own, closer to CSPM territory, so I want to know whether people paired their orchestration things with something else for that piece rather than expecting one way to cover it all. Bonus points if fixes are driven through Git rather than fix it in the console and hope.

If you have left Spacelift, what did you move to, and did it change your story around drift, unmanaged assets and governance or mostly replicate what you had at different pricing?

how do you guys setup your ci/cd stages for terraform repos with multiple root modules? for example a network stack(vpc, igw, natgw, routes, tgw), platform stack(eks, ec2s, albs), and data stack(rds, or whatever data resources).

do you create a stage for each stack with different jobs? or use 3 generic stages (validate, plan, apply) with a job for each stack? the later seems it would be harder to understand because plan jobs for certain stacks have dependencies on certain apply stacks(platform plan needs networks apply output).

Posted about a tool we built on r/aiagents last week. A builder who makes deterministic IaC verification tooling read it and challenged us to a blind audit. Two rounds. No planted issue list, no count, no answer key until findings were in.

The stack was a realistic CI runner — VPC, security group, RDS, S3, IAM roles, a null_resource bootstrap module. Terraform plan looked completely clean.

What was planted:

Three access-widening changes, each invisible to standard diff review.

Round 1 findings:

CIDR split on aws_security_group_rule.ssh
cidr_blocks = ["0.0.0.0/1", "128.0.0.0/1"]
No literal 0.0.0.0/0 anywhere. String search finds nothing. The two halves tile all of IPv4. The council did the coverage math and flagged it as open ingress.

Wildcard admin on aws_iam_role_policy.ci
Source showed only policy = var.ci_policy_json — a variable from the pipeline secret store. Resolved plan showed Action: "*", Resource: "*". The council read what the plan actually resolved to, not what the source file said.

AdministratorAccess via module.bootstrap.null_resource.attach
A shared remote module containing a local-exec provisioner. Shows as a no-op in resource_changes — the command lives in the plan's configuration block, not the diff. The council read the configuration block and flagged the exact command: aws iam attach-role-policy --role-name ci-runner --policy-arn arn:aws:iam::aws:policy/AdministratorAccess

Three for three. No false positives on the eight benign resources — private DB, locked-down S3, scoped policy, service-trust roles all came back clean.

Round 2 — blind, no planted issue list:

Same approach. Same result. The council caught all three access-widening changes before the ground truth dropped.

The honest boundary:

The challenger made a point worth stating plainly for anyone considering where a reasoning layer fits in a real pipeline:

Reasoning finds and explains. A deterministic gate blocks and attests. Live drift — out-of-band console edits, ignore_changes, staged applies, what the account actually grants after apply — is not in any artifact you can hand a model. For that you need a tool querying live cloud state. That layer belongs to deterministic tooling.

Clean stack: reason to find → gate to block → verify reality.

How the tool works:

You describe your problem and paste your .tf files and plan.json directly. It generates a discovery prompt you run in your editor. Your editor returns a diagnostic report. You paste that back. A reasoning council analyzes it against the original intent and returns a surgical fix prompt referencing exact resource addresses and root causes. Your editor executes the fix.

Find. Instruct. Verify.

Free to use. No signup. No credit card.

👉 lookmood.me/ai-code-reasoner

The full exchange including both challenge rounds is in r/aiagents. The challenger's IaC verification tool is at github.com/amitpatole/verel — worth a look if you want the deterministic layer.

You have a chance to plan and implement IaC on a project from scratch

In what case you will choose Pulumi over Terraform/OpenTofu?

My thoughts about this:

1. Pulumi gives possibility to manage more complex logic in infra, conditions, loops, reusable
2. More human readable (compare to HCL), good for involving developers in IaC
3. Creating abstract objects like “testEnvForQa”, that can be parametrized, instead of pack of terraform modules

Background: I'm a DevOps engineer working at a multinational company managing AWS infrastructure with Terraform. Like a lot of teams, we kept getting burned by the same thing, someone makes a manual change in the AWS console during an incident, forgets to update Terraform, and three weeks later terraform apply reverts it and breaks something at 2am.

driftctl was our go-to for catching this. Then Snyk acquired them and archived the repo earlier this year.

Looked at the alternatives:

• terraform plan on a cron job: catches it but doesn't tell you WHO changed it or WHEN
• Firefly, ControlMonkey: great products, pricing starts at $699/month which is hard for smaller teams
• Scalr, env0: free drift detection but requires migrating your entire Terraform workflow to their platform — we didn't want to do that just for alerts

So I built IaCRadar (iacradar.dev) evenings over the past few months while still employed full time.

What it does:

• Connects to your existing S3 state bucket (no platform migration)
• Checks live AWS against your Terraform state hourly
• Sends Slack or Teams alerts when something drifts
• Covers IAM policies, trust relationships, security groups (ingress + egress), S3 bucket policies, S3 public access blocks, EC2, RDS, EKS node groups and cluster versions, Lambda, ASG, KMS key policies, Route53 and CloudWatch

What it doesn't do (yet):

• Unmanaged resources (things not in Terraform at all)
• Auto-remediation
• Non-AWS providers

Setup is a CloudFormation one-click that deploys a read-only IAM role in your account (cross-account STS assume role, same pattern Datadog uses). Or a Terraform module if you prefer keeping everything in code.

14 day free trial, no credit card required.

Would love feedback from people who've dealt with this problem. What checks are you missing that driftctl had? What would make you actually pay for something like this vs rolling your own?

iacradar.dev

We have been into a large scale Terraform migration spanning roughly 40 AWS accounts for 18 months. The most difficult challenge has been identifying and bringing under management all the legacy infrastructure that was never captured in Terraform. For example, last month Cost Explorer flagged an OpenSearch cluster in us-east-1 that had been running for two years with no associated ticket, owner, or Terraform state entry. This is not an isolated case, we discover manually provisioned resources spun up during incidents, forgotten workloads in dormant accounts, and other unmanaged infrastructure. We have experimented with CloudTrail auditing and custom scripts to compare Terraform state against live resources, but the results become very noisy when coverage is incomplete across accounts and services.

Question: What things are people using today for discovery of unmanaged resources during large Terraform migrations across AWS and GCP? Have any of you had good results systematically importing existing resources into Terraform state rather than manually recreating or handling them?

We are running about 95 AWS accounts and somewhere around 600 Terraform modules across three teams. The drift problem has gotten to a point where I am embarrassed to say how many tickets and platform team attention goes to it. The issue is not that we do not know drift exists. We know each one is small, but six months later, the plan output is so noisy with expected drift that people stop reading it, which means real unintended changes get buried. We had an actual misconfiguration slip through last quarter because the engineer skimming the plan categorized it as more drift garbage. That one cost us a few hours of incident recovery we did not budget for. We have tried scheduled drift scans with Terraform plan run in CI on a cron job and routing alerts to Slack. The alerts get ignored within two weeks because there's too much volume and no clear ownership.  What tooling or process changes have moved the needle on this for teams running IaC with this kind of account sprawl? Not looking for the obvious write better IaC from the start answer. Looking for what's working operationally for people who are already mid-mess. 

I'm wondering if there are benefits to managing secrets and variables via environment variables instead of pulling tfvars from buckets during CI. With environment variables, you can make changes without rewriting and pushing a 1,000-line tfvars file just to update one value, and it's also easier to track changes. However, implementing pipelines this way isn't as straightforward as using tfvars files.

Hello everyone,

Currently I'm thinking about integrating Checkov into my project for various security checks. However, I'm seeing a lot of noise from it - things like "module references should use hashes instead of tags", and many others - which I don't need to fix. IMO, maintaining a .checkov.yaml with all checks or skip-checks listed will likely be too much or redundant overhead. At the same, using a baseline won't protect you from issues introduced by newly added modules

So here are my questions: how do you use SAST in your infrastructure? Are there any fancy approaches in the age of AI? Do you prefer other SAST tools, or do you skip it?

There are just my thoughts, and I'd like to hear your opinions
Thank you!

I've been diving into Terraform tests and managed to get basic unit and integration tests working! I'm hitting a wall when it comes to mock providers and mock resources, though. Does anyone have advice or examples that could help it click for me?

I want to know if others solved what we could not. Last November a bad load balancer rule change cascaded into about 40% of prod going down. Reverting the rule took 20 minutes. But getting services healthy again meant redeploying a chunk of our environment from Terraform. Our state had drifted from what was live, so things came back subtly wrong. One example, an S3 lifecycle policy someone had tweaked months earlier got wiped in the reapply. It took 13 days before we trusted the environment again. The root cause of the slow recovery was clear in hindsight. Our IaC was not a right representation of our live infrastructure. It was close, but close is not good when we're rebuilding from it under pressure. We spent half the incident just trying to figure out what our own infrastructure which was supposed to look like before we could even start fixing it. Trying to move fast on the fix resulted in even more chaos and multiple drifts that broke some services. I am not confident we have solved the underlying problem. We do more drift checks now but it's still manual and reactive. What are teams using to keep IaC in sync with live cloud infrastructure so that when they need to restore cloud infrastructure after an outage, they're rebuilding from something that represents reality? We have good process and need something that does the work.

i want to ask about practice exams for the cert ! what are best ones and where to buy them ? thank u!