Infrastructure as Code Gives Kubernetes Changes a Reviewable Path for AI Agents

AI agents can already make changes to cloud infrastructure, but direct access leaves teams with limited visibility into what an agent will change or why. Infrastructure as code (IaC) offers a more controlled workflow: an agent edits configuration, a preview shows the planned changes, and a person approves them before deployment. That makes IaC relevant beyond initial cloud provisioning, especially for Kubernetes environments that keep changing after their first deployment.

Clusters need maintenance as well as applications. Kubernetes versions eventually leave support, and delaying an upgrade can increase operating costs. IaC represents cluster configuration in code, so an upgrade can be proposed as a change, inspected and reviewed before it reaches the environment. The same approach can cover networking, databases and other resources that might sit outside the cluster.

Two ways to manage infrastructure around Kubernetes

Some infrastructure tools use the Kubernetes Resource Model to describe cloud resources as Kubernetes objects. Crossplane, AWS Controllers for Kubernetes, Config Connector and Azure Service Operator take this approach, using a cluster as the control point for managing infrastructure. That means a cluster has to exist before these tools can do their work.

Pulumi, Terraform and OpenTofu manage resources from outside the cluster. In this model, a Kubernetes cluster is one part of a broader infrastructure program, alongside the services that depend on it. A team can describe both together, and use a preview to see what a proposed change will update or replace. For an upgrade, changing the Kubernetes version can be a small code edit, while the preview exposes the resource changes that need review before deployment.

The choice also affects how platform teams share infrastructure. Rather than asking application teams to work directly with YAML for every resource, a platform team can package infrastructure components in a typed library with defined inputs. Teams can then consume those components through a more familiar programming interface, while the platform team retains control over how the underlying resources are configured.

Drift handling is another difference. A Kubernetes operator can automatically reconcile a resource when its live state diverges from the declared configuration. IaC workflows generally show the difference and wait for someone to approve a change before applying it. Automatic correction can be enabled as a separate setting, giving teams a choice about how much autonomy they want.

External IaC programs can also make it easier to describe infrastructure across regions, deployment stages or cloud providers. The cluster and platform configuration can be adjusted for a new target while Kubernetes objects that don't depend on a specific provider can carry over. That doesn't remove the work of checking provider-specific details, but it gives teams a shared configuration model instead of requiring a full rewrite of the platform.

Managing resources beyond the cluster

Kubernetes workloads often rely on resources that live elsewhere, such as an external database. IaC can describe that database alongside the cluster and connect it to the workloads that need it. This can help make dependencies explicit within the same program.

Helm organizes a chart's manifests by resource kind, but that ordering does not express every dependency between resources. It also can't wait for a resource that isn't a Kubernetes object. When a database or another external service must be ready before an application can use it, managing both through IaC can provide a clearer way to represent that relationship.

The larger benefit is that infrastructure becomes easier to reason about as a connected system. Cluster settings, network resources and external services can be reviewed together, even when they don't share a control plane. Teams still need to account for differences in how each service behaves, but they can track the intended configuration in one version-controlled workflow.

Agents can propose changes without direct cloud access

An agent with direct cloud credentials can create or modify resources, but its actions may be difficult to predict in advance. At scale, teams need to know what is changing in their infrastructure and have a clear way to inspect those changes.

With IaC in the loop, an agent can work on an infrastructure program or its stack configuration and produce a proposed code change. The preview then shows the expected effects before deployment. Reviewers can inspect the diff and approve it through a process the team already uses, while the agent handles much of the configuration work.

This workflow doesn't make an agent's output automatically correct. The preview and human review provide a point to catch unwanted replacements, incorrect settings or changes that don't fit the system's needs. The practical value is a bounded way to use agent assistance without giving the agent unrestricted access to cloud accounts.

Adopt IaC gradually and keep GitOps

Most teams have existing infrastructure, so adopting IaC doesn't require rebuilding everything at once. Resources can be imported into a program over time. A preview with no planned changes can then confirm that the code matches the current environment before the team begins managing it through that workflow. IaC can also support a move from older platforms into Kubernetes.

Once resources are represented as declared state, agents can work from a clearer description of what the system should contain. That can help with migration tasks, though teams still need to validate the proposed configuration and resolve any differences between the imported state and their intended design.

Teams that already use GitOps can keep that operating model. An operator can run IaC programs from within a cluster, using a Kubernetes object that points to a Git branch. Kubernetes resources continue to be managed through the existing workflow, while the operator runs the infrastructure program described by that object.

The useful question for platform teams is where they want the control point to sit: inside Kubernetes, or in an external program that manages Kubernetes alongside other resources. For environments spanning both cluster and non-cluster infrastructure, IaC offers a shared place to plan upgrades, track drift and review agent proposed changes. The next thing to evaluate is how well a team's chosen tool models its real dependencies and fits its existing review process.

Read more about infrastructure as code and DevOps workflows.