Infrastructure as Code (IaC) is essential for managing cloud environments efficiently and at scale. However, not all tools offer the same level of reliability and predictability. Some are strong in certain areas but lack critical features elsewhere. More importantly, almost every IaC tool today is incomplete. They exist in a perpetual state of “unfinished,” evolving but never fully reaching their potential. A reality that may never change.

This “Bill of Rights” for Infrastructure as Code serves as a reminder of the promise we make to the end user — the practitioners who are using Infrastructure-as-Code to bring sanity to the chaos that is the world of ClickOps.

Whether we are the authors of the control planes (AWS, Azure, or GCP), the developers of Terraform providers (“aws,” “azurerm,” “azapi”), or practitioners in the field trying to make magic happen, we must strive toward the realization of these rights as a standard for building and maintaining reliable infrastructure.

This document defines a set of principles that outline what a high-quality Infrastructure as Code tool should provide. Each principal should manifest as an end user expectation — an unalienable right — to citizens of a more reliable multi-cloud.

These are not optional enhancements; they are necessary capabilities that ensure infrastructure is managed with precision and control. Whether using Terraform, ARM, Bicep, Pulumi, or another tool, engineers should expect these standards to be met.

№1: Error-Free First Deployment

Every infrastructure automation tool must provide a rock-solid guarantee that an initial deployment can be executed without failure. The first application of an IaC tool should be smooth, consistent, and repeatable. A tool that fails unpredictably or requires manual intervention to function properly is failing its most fundamental purpose.

An ideal IaC tool should allow engineers to take a new environment and bring it to life with confidence, ensuring that configurations, dependencies, and required resources are correctly established without unnecessary friction or guesswork.

№2: Idempotence

An Infrastructure as Code tool must uphold the principle of idempotence, ensuring that running the same configuration a second time without any modifications results in no changes. This means that once an environment is provisioned, reapplying the code should not produce unpredictable or unnecessary updates. This fundamental characteristic provides stability, prevents unintended side effects, and guarantees that engineers can trust their IaC tool to accurately reflect the desired state of the environment without introducing churn or ambiguity.

№3: The Right to Predictable Change

Infrastructure should not be a black box, and changes should never be a mystery. A robust IaC tool must allow engineers to modify their configurations with full awareness of the exact impact those changes will have before they are applied.

Predictability is critical in preventing outages, misconfigurations, and downtime. Engineers should be able to run a dry run or preview of changes, ensuring that they understand what modifications will occur before applying them to live environments. This ability is key to maintaining control and preventing unintended disruptions.

№4: The Right to Validated Change

Beyond predicting changes, an Infrastructure as Code tool should proactively validate them. Simple syntax or type validation is not enough; the tool should perform deep, cross-resource validation to detect potential conflicts or failures before changes are applied. This includes checking whether resource limits are exceeded, whether dependencies are met, and whether there are constraints imposed by policies or governance rules.

For instance, adding an additional disk to a virtual machine should trigger a validation check ensuring that the VM SKU allows for the additional storage. Similarly, if an organization enforces Azure Policies restricting certain configurations, the IaC tool should be aware of these constraints and warn users before they attempt an action that will be rejected by the control plane. This level of proactive validation prevents costly and time-consuming failures, improving the overall stability of the environment.

№5: The Right to Drift Detection

The infrastructure defined in code must remain in sync with the actual state of the environment. Drift detection is an essential capability that allows engineers to detect and respond to changes made outside of the IaC tool, whether they were accidental, unauthorized, or necessary manual interventions.

A best-in-class IaC tool should be able to compare the defined state in code with the real-world state and report discrepancies, allowing teams to correct drift and maintain consistency. Without this right, teams risk operating in an environment where the codebase no longer accurately represents reality, leading to unpredictability and operational chaos.

№6: The Right to Operational Reciprocity

Infrastructure as Code should not exist in isolation from the portals, consoles, and dashboards where read-only operations are performed. Engineers and operators must have visibility into the provenance of deployed resources, ensuring they can trace them back to their source. An ideal IaC tool should provide a clear link between deployed infrastructure and its defining code, answering critical questions:

  1. What source code repository contains the configuration?
  2. Which specific file and commit hash defines the resource?
  3. When was the last successful deployment?

This reciprocity between operational interfaces and infrastructure as code is key to enabling both visibility and accountability, ensuring that teams can efficiently troubleshoot, audit, and manage their environments without resorting to manual guesswork.

Conclusion

These six rights define the North Star for what an Infrastructure-as-Code tool should be capable of. While some of these capabilities are well established in existing tools, others remain incomplete or nonexistent.

It is up to us as practitioners to advocate for and demand these capabilities in the tools we use. A truly great Infrastructure as Code tool should seamlessly integrate with the broader cloud operational model, bridging the gap between authoring infrastructure configurations and consuming them through cloud portals and consoles.

Just as we use desktops for content creation and tablets for content consumption, we should expect our infrastructure tooling to provide a seamless and reciprocal experience across different operational interfaces. By striving for these rights, we can create more reliable, predictable, and scalable infrastructure management solutions that empower engineers to build with confidence and efficiency.

Alt