Cloud Computing · IAC

IaC and GitOps: Automating Infrastructure Step by Step

Remote Admin SysOps Team·December 17, 2025·7 min read

IaC and GitOps – Automating Infrastructure Step by Step

IaC and GitOps let you build infrastructure like software: in code, with change review, testing, and fast rollback. In practice, you cut deployments from days to hours, reduce manual errors, and get a full audit trail of who changed what and when.

What is IaC, and what problems does it solve for a company?

IaC (Infrastructure as Code) means defining infrastructure as code (in a repository) instead of clicking through cloud consoles and “console magic.” As a result:

environments are repeatable (dev/stage/prod don’t differ just “because someone set it up that way”),
changes are versioned (a commit means history and accountability),
deployments are automated (a pipeline instead of manual steps),
you can review and apply quality control just like with application code.

From my experience: the biggest time savings don’t come from automation itself, but from eliminating the “guessing game” about what’s actually deployed.

What is GitOps, and how does it differ from classic CI/CD?

GitOps is an approach where Git is the single source of truth about the state of the system, and deployment happens through a mechanism that continuously compares the actual state against what’s declared in the repo.

The difference from “plain CI/CD” is a practical one:

in CI/CD, the pipeline usually “pushes” changes to the environment,
in GitOps, the environment “pulls” changes from the repo and enforces compliance itself (drift detection).

In production projects, GitOps gives me two things manual deployments never do:

continuous state compliance (less drift),
easy rollback (back to a specific commit).

When should you use IaC, and when should you use GitOps?

The simplest way to put it:

IaC: infrastructure provisioning (networks, VMs, accounts, IAM, load balancers, databases, storage, policies).
GitOps: continuous deployment of configuration and applications (especially on Kubernetes) and maintaining state compliance.

In practice, it most often comes down to this model:

IaC lays the foundation (cloud/on-prem),
GitOps maintains what “lives” and changes frequently (workloads, configurations, manifests).

How do you choose IaC and GitOps tools without creating a mess?

Tool choice has less to do with trends and more to do with your environment and your team’s skills.

IaC (provisioning):

Terraform / OpenTofu: good for multi-cloud and the market standard,
CloudFormation / Bicep: great if you’re “all-in” on a single cloud,
Ansible: best for system configuration (configuration, hardening, operations), not for managing the “lifecycle of cloud resources.”

GitOps (continuous compliance):

Argo CD / Flux: the standard for Kubernetes,
the “pull” model (an agent inside the cluster) is usually safer and operationally simpler.

From experience: the biggest problems come not from the tool itself, but from a lack of repo conventions, secrets control, and a change-approval process.

What should your target repository structure look like?

A good repo structure is half the battle. The layout that works best for me is “platform + environments”:

modules/ – modules (VPC/VNet, IAM, Kubernetes, databases, monitoring)
envs/dev/, envs/stage/, envs/prod/ – environment configurations
apps/ – manifests/Helm/Kustomize for applications (GitOps)
policies/ – policy rules (e.g., policy-as-code)
docs/ – runbooks and standards

The key rule: prod can’t be a copy of dev “done by hand.” Prod is a deliberate configuration, but built on the same modules.

How do you secure IaC and GitOps so automation doesn’t become an attack vector?

This is the point that most often “bites back” after the first audit.

In practice, I always implement:

secrets management: no passwords or keys in the repo, not even “temporarily,”
permission separation: the pipeline has minimal permissions, and prod requires dual approval,
remote state (for Terraform/OpenTofu) with locking and encryption,
policy-as-code: banning public buckets, open security groups, and uncontrolled IAM permissions,
artifact signing and verification (where it makes sense),
audit and logging: who deployed a change and in which environment,
drift detection: catching “clicks in the console.”

In real incidents, the most common root cause is “someone fixed it in the console because it was faster.” GitOps/IaC is meant to put a stop to that.

How do you roll out IaC step by step without stopping the business?

Below is the path I most often follow with companies that currently manage infrastructure “by hand.”

Step 1: Take inventory and choose a pilot scope

First, pick one highly repeatable area, for example:

network + VMs,
the dev environment,
monitoring and logging,
staging for applications.

Don’t start with “let’s rewrite the whole world” — that almost always ends in the project being abandoned.

Step 2: Set your working standard (branching, review, approvals)

A minimum standard:

PRs are mandatory,
code review,
automated checks (lint, fmt, validate),
separate approvals for prod.

Step 3: Build your state backend and security rules

For Terraform/OpenTofu:

remote state,
locking,
encryption,
access rotation,
separate state per environment.

Step 4: Build your modules and start with a “landing zone”

Start with the foundation:

network,
IAM,
logging,
baseline policies,
a tagging and naming standard.

Only then move on to “business resources.”

Step 5: Add a plan/apply pipeline

A practical model:

plan runs automatically for every PR,
apply only after merge plus approval (separately for prod),
plan artifacts kept for audit purposes.

Step 6: Turn on drift detection and recurring tests

Minimum requirements:

a regular “plan” with no expected changes (detects drift),
an alert if drift is detected,
a procedure: “click in the console” = a remediation PR.

How do you roll out GitOps step by step on Kubernetes?

If you have K8s (or are planning to), GitOps delivers the biggest return.

Step 1: Separate the “infra” repo from the “apps” repo

This simplifies permissions and ownership:

the platform team owns infra,
product teams own apps.

Step 2: Choose your declaration format

Most commonly:

Helm or Kustomize,
separate overlays per environment.

Step 3: Install a GitOps controller in the cluster and connect the repo

The “pull” model is safer (the cluster has access to the repo, not the other way around).

Step 4: Set deployment policies

namespace restrictions,
resource limits,
ingress and certificate standards,
a ban on “latest” image tags.

Step 5: Build in a safe rollback path

In GitOps, rollback usually means:

reverting to a commit,
or reverting the PR.

The most important thing: rollback has to be a practiced procedure, not “an option in theory.”

What does a real-world scenario look like: an e-commerce company with seasonal demand?

In practice (a common case):

IaC builds repeatable environments and autoscaling,
GitOps ensures deployment control and fast rollback,
FinOps keeps an eye on costs and budgets,
monitoring detects regressions and drift.

The business outcome: during peak season, you’re not “putting out fires by hand” — you’re following procedures.

Which KPIs show that IaC and GitOps are actually working?

If you don’t have metrics after rolling out automation, it’s easy to slide back to “doing it by hand because it’s faster.”

The most practical KPIs:

time to stand up an environment from scratch,
number of changes deployed per week,
share of changes that get rolled back (rollback rate),
MTTR (time to recover after an outage),
number of incidents caused by drift or manual changes.

What mistakes do I see most often with IaC and GitOps?

“We’ll bolt on IaC, but the process stays the same as before”
Secrets in the repo or in pipeline logs
No separation between dev/stage/prod
No policies or least-privilege rules
No rollback or DR testing

Automation without standards is just making mistakes faster.

How do you get started in 30 days so it actually makes sense?

Week 1: inventory, pilot selection, repo standard and review process
Week 2: state backend, first landing-zone modules
Week 3: plan/apply pipeline plus baseline security policies
Week 4: drift detection plus a first environment “rebuild test”

After these 30 days, you should be able to: