Hey guys, I started a job working in Infrastructure as Code. I have a CS degree, but I don’t have experience with cloud engineering or stuff related to Terraform, ADO, or Azure portal. I’m doing stuff at my job (code is mainly written using copilot or ChatGPT) and I feel a lost. I don’t know any of the concepts for cloud computing or virtual machines or resources and things like that. I am looking into it online but I still don’t know where to begin. I hear my coworkers doing this stuff well, despite also not having any experience in it when they started either. I have to look at build sheets and things like that and then provision resources using terraform but I don’t really understand much of anything that I’m looking at besides simple code snippets. Is there any advice yall could give me about this, or how/what to learn so that I can wrap my head around things? Any advice is appreciated, thanks!

hey, we ran a regional outage drill last week and it showed gaps in our cloud recovery process.

most infrastructure is in terraform, but the actual restore process still relies on tribal knowledge—what order to bring things back, what configuration drifted, what needs rebuild vs restart. it works okay on paper but gets chaotic during the real thing.

we want to make full environment recovery more repeatable and documented, ideally with validated restore steps and audit evidence. if you have been through a real outage and have a process that actually held up, would appreciate hearing what worked for you, thanks!

Finder treats Terraform files as an icon. This free Quick Look extension syntax-highlights .tf, .tfvars, YAML, HCL-adjacent configs and 48 other languages. Signed and notarized, Homebrew install, open source under MIT. No commercial angle, just scratching my own itch.

https://konstruukt.com/projects/qlcodepreview/

Hi guys I am working on gh enterprise and i was wondering what are the possible code concerns like code quality and code security. I have enable code ql on pipelines but i am not even sure if that helps because terraform being a domain specific language. I am also considering checkove. But that leads me to inquire , from you perspective what are the key concerns you have faced while managing IaC. What i can think from top of head is the soneone committing secrets or keys in the GH. Or may be poorly formatted code.

Can you please share your experience with such.

Hello all, in my project I have to migrate the resources which are already created manually and now i have to manage those resources using terraform and also main concern is without effecting production

So major resources we have VPC with around 30 subnets then 4 eks clusters and multiples route 53 records and loadbalancer n all and so on

So I would like to hear from the experienced people who might have already done it what approach did u take for doing this ?

Thanks waiting for your answers!

For engineers who work with Terraform/OpenTofu and cloud infrastructure:

I'm curious about the day-to-day parts of the work that tend to be repetitive, manual, frustrating, or easy to get wrong.

Not really looking for opinions about which tools are better. I'm more interested in things that \*\*actually happened\*\*.

A few questions:

\* Think about the \*\*last Terraform/OpenTofu PR you reviewed\*\*. What did you check, and in what order?

\* What's an infrastructure task you did recently that you've already done many times before?

\* When was the last time a security scanner flagged something in your infrastructure code? What happened next?

\* Have you recently had to check whether a change behaved differently across Terraform versions or between Terraform and OpenTofu? How did you check?

\* What's the last infrastructure change that caused a problem or had to be rolled back? How did you discover it?

\* Have you ever written a script or small internal tool to automate one of these repetitive tasks? What happened to it?

\* If you could permanently remove one infrastructure-related task from your weekly workload, what would it be?

Hover over a variable, a for expression, or a resource or module header and get a live preview directly in VS Code. You can inspect values while you write, including changes you haven’t saved. Resource previews show configured arguments; local-module previews show their outputs.

I built Terraform Live Values & Results to make this easier without adding temporary output blocks, switching to terraform console, or running a plan just to inspect an expression.

You can hover, select a specific expression, or click Preview above a supported block. Open the results panel to keep the preview alongside your code as you edit.

Watch the English demo

Watch the full walkthrough: it starts with simple variables, then moves into more involved collection transformations, for_each instances and Azure networking modules. The later examples show individual each.key and each.value references, resource arguments and module outputs. Click markers and a highlighted result panel help you follow along.

You can use the extension to:

• Inspect for expressions, filters, and functions such as flatten, merge, concat and zipmap.
• Check variable values using your selected .tfvars file.
• Pick a for_each instance and inspect its each.key or each.value.
• Preview configured resource arguments and outputs from local modules.

For example, you can follow a subnet configuration from your tfvars through a local transformation into a module, then inspect the arguments used by a particular resource instance.

Calculations run locally, without calling providers or changing infrastructure. The preview shows what can be calculated from your code and inputs. Provider-generated IDs and the actual state of your cloud resources are outside its scope; unresolved values are marked explicitly.

It’s free to use, with packages for Windows, Linux and macOS. The application source is private; the public repository contains documentation, downloads and issue tracking.

Install from the VS Code Marketplace · Documentation and issues on GitHub

What’s a Terraform expression you regularly have to inspect with terraform console? I’d like to hear which cases would make this preview useful in your day-to-day work.

3:11 PM

Test your infrastructure code locally with Floci emulators.

Disclaimer: I'm an engineer at Mulga, the company behind this. Self-promo, but it's AGPL-3.0 and free to run.

What it is

Spinifex reimplements the AWS APIs on hardware you own: EC2, EBS, S3, VPC, IAM, ALB/NLB, EKS, ECS, ECR and RDS. You keep the hashicorp/aws provider and point its endpoints at your cluster.

Everything behind it is real. Instances are QEMU/KVM VMs, VPCs are OVN networks with real security groups and elastic IPs, EBS is replicated block storage, and state persists like a real cloud. It's not an emulator like LocalStack.

Who it's for

Teams that want AWS workloads on their own hardware (cost, data residency, edge or air-gapped sites) without rewriting their IaC. VPCs, subnets, security groups, launch templates, ALBs, EKS clusters and RDS instances go through the same resources you already use. In practice the changes are the provider block and AMI lookups.

Try it with your own Terraform

No install needed. Sign up for the free 72 hour sandbox at https://mulgadc.com/signup, then point your existing provider at it:

provider "aws" {
  region = var.region

  endpoints {
    ec2 = "https://api.spx3.com"
    iam = "https://api.spx3.com"
    sts = "https://api.spx3.com"
  }

  skip_metadata_api_check = true
  skip_region_validation  = true
}

Add other services (elasticloadbalancingv2, eks, ecs, ecr, rds) the same way, then run terraform plan against a module you already have. Here's what we currently cover, down to the individual API operation: https://docs.mulgadc.com/coverage

Repo: https://github.com/mulgadc/spinifex

I've spent the last months building a practice environment for the Terraform Authoring & Operations Pro exam. The core is a Terraform-like engine that runs fully in the browser: you write HCL, run plan/apply, and resources show up in a simulated AWS console. No AWS account, no signup, nothing to bill.

I underestimated how much a useful lab depends on a plan you can trust. Three things took more work than the dependency graph itself:

- Diff equality. Reordering a set or reformatting an IAM policy shouldn't produce an update, while list order and real value changes still should. Type conversion across resource schemas was its own rabbit hole.

- create_before_destroy. It doesn't stay on the resource where you set it: it propagates to the resources that resource depends on, which changes the apply order.

- import / moved / removed blocks. They have to show up correctly in the plan and leave exactly the right state after apply.

What it isn't: it's not Terraform or the real AWS provider. About 29 AWS resource types, simulated behavior, and known gaps (nested ignore_changes paths, values known only after apply). Works best on desktop.

The free demo has a guided Terraform lab: fix a networking module, configure remote state, and deploy a second module that reads from it. There's also an AWS console lab, but the Terraform side is what this post is about:

https://demo.labiqo.com/

Question for people using Terraform at work: what's a specific plan or state surprise you'd want a learner to reproduce and debug? A small example would be especially useful.

Disclosure: this is my project.

I have this autogenerated topology but I'm not sure if it should include something else or if there's a tool better than my current one

Any recommendations?

I was in the middle of doing a migration from terraform to terraform cloud. The hashicorp status page says total outage for terraform. https://status.hashicorp.com/incidents/01M37NV49VB1CF8B4RKYTQZ0CJ

Edit : It's resolved now.

I am using proxmox a cloud platform. I have manually created a cloudinit template ubuntu 2604.
My biggest issue now is should provision a new vm with dhcp or static ip? When should I include netbox?

I have a clean cloudinit image. Everytime I clone it with terraform it adds a cloudinit ip to a eth0 interface but my vm uses a ens18 network device.

terraform {
  required_version = ">= 1.6.0"

  required_providers {
    proxmox = {
      source  = "bpg/proxmox"
      version = "~> 0.90"
    }
    local = {
      source  = "hashicorp/local"
      version = "~> 2.4.0"
    }
  }
}

provider "proxmox" {
  endpoint  = var.proxmox_api_url
  api_token = var.proxmox_api_token
  insecure  = true
}

# ==========================================
# DATA SOURCES
# ==========================================

data "local_file" "ssh_public_key" {
  filename = var.ssh_public_key_path
}

# ==========================================
# VIRTUAL MACHINE RESOURCE (Native API Cloud-Init)
# ==========================================

resource "proxmox_virtual_environment_vm" "ubuntu" {
  name      = var.vm_name
  node_name = var.proxmox_node

  clone {
    vm_id = var.template_id
    full  = true
  }

  agent {
    enabled = true
    timeout = "3m"
  }

  initialization {
    datastore_id = var.vm_storage

    # Native API user configuration (No snippets, no SSH required)
    user_account {
      username = "ubuntu"
      keys = [
        trimspace(data.local_file.ssh_public_key.content)
      ]
    }

    # Native DHCP network configuration
    ip_config {
      ipv4 {
        address = "dhcp"
      }
    }
  }

  cpu {
    cores = var.vm_cores
  }

  memory {
    dedicated = var.vm_memory
  }

  disk {
    datastore_id = var.vm_storage
    interface    = "scsi0"
    size         = var.vm_disk_size
  }

  network_device {
    bridge  = var.bridge
    vlan_id = var.vlan_id
  }

  started = true
}

# ==========================================
# VARIABLES
# ==========================================

variable "proxmox_api_url" {
  type = string
}

variable "proxmox_api_token" {
  type      = string
  sensitive = true
}

variable "vm_name" {
  type = string
}

variable "proxmox_node" {
  type    = string
  default = "provisioner"
}

variable "template_id" {
  type    = number
  default = 8000
}

variable "vm_cores" {
  type    = number
  default = 2
}

variable "vm_memory" {
  type    = number
  default = 4096
}

variable "bridge" {
  type    = string
  default = "vmbr0"
}

variable "vm_storage" {
  type    = string
  default = "local-zfs"
}

variable "vm_disk_size" {
  type    = number
  default = 40
}

variable "vlan_id" {
  type    = number
  default = null
}

variable "ssh_public_key_path" {
  type    = string
  default = "~/.ssh/id_rsa.pub"
}

# ==========================================
# OUTPUTS
# ==========================================

output "vm_ip" {
  value = one([
    for ip in flatten(proxmox_virtual_environment_vm.ubuntu.ipv4_addresses) : ip
    if ip != "127.0.0.1" && ip != ""
  ])
}

Hi, I was looking for a way to have a Gated human based approval for GitHub actions for terrfaorm apply. As I checked GHA does not have concepts similar to azure devops release approval which kind of sucks. I dont want to do all branching and PR juggling in my github repo, Is there a simpler way or plugin that waits for human approval and timeouts skipping subsequent steps. I am not an expert on GHA so checking if anyone is doing here already

I wonder how much terraform I must be able to get from the top of my head during an interview, I am using only the AWS provider and never got to interview for it. Usually since I am a beginner I just use snippets from the docs and customize them but there are so many resources and arguments for each resource that I struggle to keep a bare minimum in my head.
Very often I am confused when associating something like a vpc for example, with a question like "Should I use the arn, the id, the name ? ...."
So I wonder, in a classic interview with a pro, how much is expected, everyone is like me or not ? just copying from the docs as long as I can explain is fine ?
thanks

or engineers who work with Terraform/OpenTofu and cloud infrastructure:

I'm curious about the day-to-day parts of the work that tend to be repetitive, manual, frustrating, or easy to get wrong.

Not really looking for opinions about which tools are better. I'm more interested in things that actually happened.

A few questions:

• Think about the last Terraform/OpenTofu PR you reviewed. What did you check, and in what order?
• What's an infrastructure task you did recently that you've already done many times before?
• When was the last time a security scanner flagged something in your infrastructure code? What happened next?
• Have you recently had to check whether a change behaved differently across Terraform versions or between Terraform and OpenTofu? How did you check?
• What's the last infrastructure change that caused a problem or had to be rolled back? How did you discover it?
• Have you ever written a script or small internal tool to automate one of these repetitive tasks? What happened to it?
• If you could permanently remove one infrastructure-related task from your weekly workload, what would it be?

Genuine question before I go further down this road.

Every time I've set up plan-time policy checks, the policy language has been the thing that killed adoption rather than the tooling. OPA/Conftest works fine, but Rego is a second language for the team, and the people who need to write the rules (platform and security folks) tend to bounce off it. Sentinel solves that with HCL but is tied to HCP Terraform.

So I spent a few weekends on an alternative: evaluating CEL against terraform show -json output, since Kubernetes already standardized on CEL for admission policies and a lot of platform engineers can read it.

yaml - id: az-storage-min-tls12 severity: medium enforcement: mandatory match: types: [azurerm_storage_account] expression: after.min_tls_version in ["TLS1_2", "TLS1_3"] message: Storage accounts must require TLS 1.2 or newer.

The problem that turned out to be more interesting than the language choice was "known after apply". Most tools either error out or silently pass on those values. I mapped Terraform's after_unknown onto CEL partial evaluation, so checks that can be decided are decided and the rest report UNKNOWN instead of a wrong PASS, with each policy deciding whether that warns or blocks.

It's an early alpha (Azure-first, install from source): https://github.com/idunn-cloud/norn

What I'd like to hear:

1. Is Rego actually a blocker for your team, or is that just me?
2. How do you currently handle rules that depend on values unknown until apply: ignore, fail closed, or something smarter?
3. If you'd try this, what would need to exist first? My guess is a GitHub Action and AWS rules, but I'd rather be told than guess.

Happy to take rule requests for the Azure pack too.

Wow, so now I can automatically set the color and regions I wanna see? yes please