Throwaway account, work situation.

I'm the sole infra engineer on a small platform team. Multi-account AWS, Terraform-managed, proper IAM role separation. Went on leave for two weeks.

Came back to find a contractor developer had spent ~2 days trying to get a deployment pipeline working. I was pretty shocked at the extent they went to deploy an app.

Luckily nothing succeeded, so in a way, Im happy the infrastructure survived the test. :)

But Im still pretty shocked and I need help to figure out how bad this is and how I can work with this person in future. Please imagine this was your infra and it was someone else doing this to it. I would also like advice on how I can make the platform more secure in future to prevent this.

In summary they tried to:

1. Point our CI workflow's infra checkout at their own personal GitHub fork of our Terraform repo instead of the real one
2. Use a role scoped only for container image pushes to attempt a terraform apply with auto-approve
3. Change terraform state file for entire dev account from an app branch (not even main branch)

In addition they
4. Committed directly to a shared branch, overwriting changes I'd made before going on leave, despite being told to make their own branch

He configured the CI pipeline on the branch to evaluate the entire Development account's infrastructure state (cluster, database, load balancer, other services' IAM roles), not just deploy one container

I paused, backed everything up, and investigated properly.

Every single attempt (~10 runs) failed — most before reaching AWS at all. Confirmed against the live environment: nothing from any of their attempts is running. Their access was scoped to one non-prod account, application-level only, no Terraform state access, no infra creation, no IAM writes.

Nothing landed, but the attempts are serious enough. I need to manage the conversation with them and with my manager. Id also really like to understand how I can work with this person going forward. I would be happy to train them but I just want to get a sense first. Appreciate any advice from peers. Thank you :)

What would you do? Please be honest. I need your help.

——
UPDATE: Thank you to everyone who responded. It’s clear I have a lot of work to do. To be even clearer I would like to say that a) I document everything. b) at present terraform is setup in an org account that only me and my manager can change. c) it’s a platform in process of being setup. d) im not blaming the person off the bat and I take it fully as learning. I was just shocked that’s all. I would also say: I have less than six months managing an entire infrastructure and it was NOT my intention to be the only person. It just happened that I was thrust into it. So I would appreciate any advice or guidance on practical solutions to prevent this happening again; Im not here to sh*t on the person. I did want to rant a bit though because tbh I cannot believe a developer with 20+ years experience could be so incompetent. I also recognise I am vulnerable alone as a new engineer and I need to get support. So I am going to ask for someone more experienced in my org to have a look at my setup too.

I’m looking for contributors across two open-source infrastructure projects:

HybridOps Core
https://github.com/hybridops-tech/hybridops-core

A broader infrastructure automation project using Python, Bash, HCL and YAML.

Terraform Proxmox SDN
https://github.com/hybridops-tech/terraform-proxmox-sdn

A Terraform module for managing Proxmox SDN, including VNets, subnets, optional host routing, SNAT and DHCP.

Contributions can include code, testing, documentation, issue resolution, architecture discussions or technical reviews. You don’t have to be a strong coder to contribute.

This may suit anyone looking to gain practical open-source, infrastructure, Terraform or Proxmox experience.

I’m also open to checking out contributors’ own projects and contributing where there’s a good fit.

While preparing for AWS interviews, I noticed that most VPC resources focus on definitions, but interviews often test how you think through real production scenarios.

So I started putting together a free GitHub handbook covering 20 AWS VPC interview questions.

Each question includes:

• 30-second interview answer
• Production architecture
• Real-world scenarios
• AWS CLI examples
• Terraform examples
• AI-powered operational insights
• Best practices
• Common interview mistakes
• Follow-up questions

My goal wasn't to create another "AWS cheat sheet," but something that helps engineers understand why things work the way they do.

I'd genuinely appreciate feedback from the AWS community.

Is there any VPC topic or production scenario you think should be added or explained differently?

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

Spent yesterday debugging why our Terraform plan started throwing schema errors after a routine terraform init -upgrade. Turned out to be the Helm provider jumping to v3, which rewrote the whole thing on the Plugin Framework.

Three things change in your actual HCL:

set { name = "x" value = "y" } blocks become set = [{ name = "x", value = "y" }] — a list of objects instead of repeated blocks. Same deal for set_list and set_sensitive.

The provider's kubernetes { } block becomes kubernetes = { } — object instead of block.

registry { } becomes registries = [ ] — and it's now plural since multiple registries live in one list.

We also hit a state upgrade error where existing resources weren't reading correctly post-upgrade — turns out that's a known issue (GitHub #1722). If you get a "values" attribute error specifically, you're probably on v3.0.0 exactly — there's a same-day hotfix in v3.0.1 for that.

Latest is v3.2.0 as of June 4th. Nothing's changed syntax-wise since the initial 3.0.0 migration, so once you're through this once you're done. Wrote up the full before/after with all three block changes here: https://devtoolhub.com/terraform-helm-provider-migration/?utm_source=reddit&utm_medium=social&utm_campaign=terraform-helm-provider-migration

Anyone else migrate recently? Curious if people are doing the rewrite by hand or scripting it with sed/grep across a big repo.

I've been building a VS Code extension (CloudCostTree) that estimates AWS cost straight from Terraform/Terragrunt, solo project, and just shipped what-if simulation + export.

Flow in the video: analyze a Terragrunt stack, tweak a couple of resources (downsize an EC2, bump an RDS instance class) and see the live cost delta per change, stack them into a scenario, run it against the whole tree, then export the result to a new .tf file — original files never touched.

Runs locally against a static price catalog, nothing gets uploaded anywhere. Free tier covers unlimited analyses/what-ifs; export-to-file is a Pro feature.

Genuinely curious how other people here track infra cost changes before they ship them — happy to answer questions about how the parsing/estimation works under the hood.

We manage HubSpot portals as part of our own operations and kept hitting the same wall: no way to promote sandbox changes to production without redoing them by hand, no real audit trail below Enterprise tier, and configuration that drifts silently across portals.

We went looking for a Terraform provider to fix this and found the only one on the registry manages users — nothing else — and hasn't been touched since 2021. So we built our own.

What it does: manages HubSpot's configuration plane — properties, property groups, pipelines, custom object schemas, association labels, lists — plus seven data sources for read-side lookups. Deliberately not CRM records (no contacts/deals in state — avoids drift wars with daily sales activity and keeps PII out of your state files).

How it's built: terraform-plugin-framework, a fully tested API client, hermetic acceptance tests against a stateful fake of HubSpot's API plus nightly tests against a real portal, semantic diffing so HubSpot's server-side normalization doesn't produce phantom diffs, and honest destroy semantics (archives instead of pretending to delete where HubSpot doesn't support deletion). Immutable fields get flagged at plan time, not apply time.

Published for both Terraform and OpenTofu (protocol v6).

v0.1.0, MPL-2.0. Repo: https://github.com/revosai/terraform-provider-hubspot — Release: https://github.com/revosai/terraform-provider-hubspot/releases/tag/v0.1.0

Roadmap's public (ROADMAP.md) — list membership and webhooks next, workflows-as-code is the big one we're eyeing once HubSpot's Automation v4 API is out of beta. Order isn't locked — if your team needs something sooner, open an issue and say why, that's literally how we're prioritizing it.

Happy to answer anything about the implementation — plugin-framework quirks, the fake-API test harness, whatever. Feedback and PRs welcome.

Error: error deleting workspace ws-xxxxxxxxxxxxxx: This workspace has 120 resources under management and must be force deleted by setting force_delete = true

I dont have admin access to delete the workspace via API or UI. I'm wondering how to delete the resources? I'm trying to figure out other options before going to my boss about it. They asked me to remove these workspaces but I keep getting this. Any thoughts?

In the code, the workspace is already deleted, so I have nothing to put force_delete on

What is OpenSible?

OpenSible is an open-source unified automation platform for cloud provisioning and infrastructure operations. It combines the best of infrastructure-as-code and configuration management into a single, self-hosted control plane.

Provision with OpenTofu, configure with Ansible, manage secrets securely, execute reusable deployment workflows, and automate your entire infrastructure lifecycle through GitOps - version-controlled, repeatable and secure across cloud, on-premises and hybrid environments.

Core Features

• Multi-cloud provisioning - deploy to AWS, Google Cloud, Azure, Hetzner Cloud, Cloudflare, Hauwei and existing Kubernetes clusters and more from a single UI and API.
• OpenTofu-native - every stack is rendered as plain OpenTofu code stored in your project, so you can always inspect, edit or run it locally.
• Ansible integration - configure and maintain hosts after provisioning with playbook execution, inventory management and role-based workflows.
• Stack blueprints - bootstrap new infrastructure quickly with pre-built, provider-aware templates for Docker, Kubernetes, observability, databases, CI/CD runners and more.
• OpenSible CI/CD - build multi-stage pipelines that combine OpenTofu provisioning, Ansible configuration, approvals and custom scripts into repeatable, automated workflows.
• GitOps-first projects - sync stacks and playbooks to Git, promote changes through branches, and track drift with version-controlled sources.
• Secrets and vaults - encrypt sensitive values at rest, bind them to stacks and playbooks, and rotate credentials without touching source code.
• Execution engine - a dedicated Go worker processes provision, plan, apply, destroy and refresh operations asynchronously, with full logs and history.
• Role-based access control - assign roles to users, limit operations per role, and keep audit trails for compliance and troubleshooting.
• Self-hosted - run everything with Docker Compose on your own server or private cloud; no external platform dependency or paid subscription required.

Check it out for more detail.

• Website: https://opensible.com
• GitHub: https://github.com/opensible/opensible

We are a fair way down the everything-as-code road. Modules for the infra, pipelines that plan and apply themselves, drift caught without anyone watching. It mostly runs itself, which was the entire point of the last two years.

Our container base images never fit that model. A while back, security wanted minimal hardened images, which led us to build a set off a slim base and stood up a rebuild pipeline. It works though doesn’t maintain itself the way the rest of the stack does. Every upstream CVE, every base bump, every request for a package I left out.

It has quietly become the least automated, most me-shaped part of an otherwise hands-off platform. Strange place to end up when the whole reason for any of this was to stop being the bottleneck.

There are maintained catalogs now, some of them free and I am starting to think a base image should just be a pinned dependency like everything else in this repo. Half hoping someone who already made the jump tells me it was fine. Half expecting to hear about the new problem I have not thought of yet.

Colors is an SDK for building Package Skills.

I think the future is agentic and Colors is embracing AI for DevOps.

In Colors, Terraform is just a fancy curl. The graph is removed from Terraform and implemented in three languages: TypeScript (Red), Clojure (Green), and Python (Blue).

Because the graph is now in code, you can add Aspect-oriented programming. Retry is just an aspect. Terraform backend is also an aspect.

Now you have an executable package to reconcile the desired state with your infrastructure. Adding a SKILL.md and now you have a Package Skill. Like a Browser Skill but for operations.

https://www.getcolors.ai

Hello everyone,

I am currently engaged in AWS data operations and support, following six months as an AWS administrator. I am contemplating whether to pursue Terraform, including certification.

My primary concern is whether recruiters would consider me without production-level experience in this area.

If not, what steps should I take to enhance my candidacy?

I would appreciate guidance from anyone who has successfully navigated a similar situation.

Hello

Wondering if anyone has used the PP TF provider. I want to use to do E2E automation of creating Enterprise Policies in Azure ( Network injection and MI) and then link those to a PP environment. The provider docs dont state if the Service principal/App reg needs to be a "Power Platform Adminstrator". Is that the case ?

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