TechOps Examples

Hey — It's Govardhana MK 👋

Welcome to another technical edition.

Every Tuesday – You’ll receive a free edition with a byte-size use case, remote job opportunities, top news, tools, and articles.

Every Thursday and Saturday – You’ll receive a special edition with a deep dive use case, remote job opportunities, and articles.

The AI tool you tried last quarter waited for a prompt, hallucinated a number, then asked if you'd like a summary.

Viktor opened a PR at 2am, rebased it against main, ran your test suite, and posted a note in #eng: "Two flaky tests in payments service, both pre-existing. Recommended merging after fixing them." Then drafted the customer reply for the support ticket the bug created.

That's 619K autonomous actions per day across 20,000+ teams. Not chat replies. Real work shipped to GitHub, Stripe, Linear, Notion, and 3,000+ other tools, from inside Slack and Microsoft Teams.

You don't supervise him any more than you supervise a senior engineer.

SOC 2 certified. Your data never trains models.

"It's what you probably originally thought AI was going to be when you first heard of it in sci-fi movies." Tyler, CEO.

Get Started for Free

Powered by: Jobsurface.com

Browse 590 Worldwide Jobs Here →

Looking to promote your company, product, service, or event to 49,000+ Cloud Native Professionals? Let's work together. Advertise With Us

I have watched DevOps engineers run terraform apply for years without ever asking what happens between pressing enter and seeing "Apply complete." Most treat it as a black box: write some HCL, run a command, get infrastructure.

That mental model works fine until something goes wrong, a state file gets corrupted, a resource drifts from what the config says, or a plan shows changes nobody expected. At that point you need to know what is actually happening under the command, not just what the command produces.

Let’s walks through the real execution path of Terraform, from the files on disk to the API calls that hit AWS, Azure, GCP, or Kubernetes, and then into the problem every team eventually runs into: infrastructure that no longer matches its own configuration.

A Terraform project is a directory of .tf files that Terraform Core parses and merges into a single configuration regardless of how they are split up. The naming is a convention, but it is one worth following because every engineer who opens the repo will expect it.

When you run terraform init, Core reads providers.tf, resolves the required provider versions against the registry, and downloads the matching plugin binaries into .terraform/providers.

These plugins are separate executables. AWS, Azure, GCP, and Kubernetes each ship their own provider binary, and Core talks to each one over gRPC using a plugin protocol, not by linking code directly. This is why adding a new provider never requires updating Terraform itself.

init also configures the backend, which is where terraform.tfstate will actually live once you start applying changes.

From there, terraform plan and terraform apply both hand your resource blocks to Core, which builds a dependency graph, resolves provisioners where they are used, and calls out to the provider plugins for every resource that needs to be read, created, updated, or destroyed. The provider plugin is what actually knows how to speak to the AWS or Azure API. Terraform Core does not know anything about EC2 or Azure VMs directly, it only knows how to walk a graph and call the interface every provider implements.

terraform.tfstate is not a log. It is the only record Terraform has that connects a resource block in your config to a real object that exists somewhere else. Without it, Terraform has no way to know that aws_instance.web in your .tf file corresponds to i-0abc1234 in your AWS account. This is what makes the plan and apply cycle repeatable rather than destructive on every run.

A user defines infrastructure in code, and the IaC tool creates or updates the real infrastructure to match. That infrastructure then sits in use, serving traffic, running workloads, being touched by other people. This is where the assumption breaks down for a lot of teams: someone makes a manual change directly against the infrastructure, through the console or the CLI, bypassing Terraform entirely.

The next time anyone runs a plan, Terraform reads the current state of the real infrastructure, compares it against the desired state written in the config, and surfaces the mismatch as drift. Reconciling means bringing the two back into agreement, either by updating the code to accept the manual change or by having Terraform overwrite it. The important detail is that Terraform does not continuously watch your infrastructure. Detection only happens when you run a command that triggers a refresh. Nothing alerts you the moment someone changes something in the console. You find out at the next plan, and only if you actually run one.

🔴 Get my DevOps & Kubernetes ebooks! (free for Premium Club and Personal Tier newsletter subscribers)