Configuration drift is one of those infrastructure problems that is easy to describe and genuinely hard to eliminate. You deploy a network device with a specific IP assignment, VLAN membership, and interface configuration. Six months later, a change is made manually during an incident. The documentation is not updated. The Terraform state no longer reflects reality. The inventory file the team uses for Ansible has a different version of the device’s role.
None of this happens because engineers are careless. It happens because configuration intent is scattered across multiple systems, and when those systems fall out of sync, there is no single place to go and find out what the environment is actually supposed to look like. The problem is architectural, and it requires an architectural answer.
The scattered intent problem
Most infrastructure environments have configuration intent in at least four places: the provisioning code, the state files, the inventory, and the documentation. In the best case, they all agree. In practice, they drift from the moment the first manual change is made under pressure.
The provisioning code reflects what someone intended when they last ran it. The state file reflects what was actually provisioned at that point. The inventory might be manually maintained and weeks out of date. The documentation is aspirational, a description of an environment that existed at some previous point and may or may not resemble the current one.
When you need to make a change, add a new host, modify a VLAN, update a routing configuration, you have to reconcile four sources of partial truth before you can be confident about what you’re changing. That reconciliation takes time, introduces opportunities for error, and produces exactly one result: an updated version of the same fragmented system.
A source-of-truth model is a different approach. One system holds the authoritative state of intent. Everything else derives from it.
NetBox as the authority
NetBox is a network infrastructure management tool designed to model IP address space, device inventory, virtual machines, network topology, VLANs, services, and their relationships. It is a documentation platform with an API, which makes it useful as a data source for automation rather than just a wiki that people stop maintaining.
The shift in thinking is treating NetBox not as a record of what has been provisioned, but as the authority for what should be provisioned. When a new host needs an IP address, the IP is allocated in NetBox first. When a device is added to a VLAN, the membership is defined in NetBox before any configuration is applied. When a service endpoint changes, NetBox is updated before the automation runs.
# Query NetBox for all hosts in the platform role, lab environment
curl -s "https://netbox.internal/api/dcim/devices/?role=platform&tag=lab" \
-H "Authorization: Token $NETBOX_TOKEN" | jq '.results[] | {name, primary_ip}'
# Output feeds directly into inventory generation for Ansible
inventory-sync --source netbox --env labWhen NetBox is the authoritative source, the provisioning code is not the source of truth, it is an implementation of the truth. Terraform and Ansible consume NetBox data to produce infrastructure that matches the declared intent. If the state file drifts from NetBox, that drift is detectable and correctable. If two systems disagree about a device’s IP address, the question “which is correct?” has a clear answer: NetBox. The authority is not ambiguous.
What this changes operationally
The most immediate change is in the operational questions you can answer with confidence.
“What IP is assigned to this host?” has one answer: NetBox. Not the Terraform state, not the DNS entry, not the inventory file that someone maintains by hand. NetBox.
“What services does this device provide?” One answer.
“Which hosts are in the lab environment?” One query, one result, consistent across provisioning tools.
This sounds obvious when written out, but many environments still lack clean answers to those questions. The IP address was in the Terraform state, a different address was in the inventory, and the monitoring had picked up a third one from a DHCP lease. All three were different. Nobody could confidently say which one was correct without doing archaeology.
When a single system is authoritative, that kind of drift is detectable rather than invisible. You can compare the provisioned state against the NetBox record and surface discrepancies. Drift becomes a defined problem with a defined remediation path rather than a fog of uncertainty that operators work around.
The discipline required
A source-of-truth model only works if the discipline to maintain it holds. NetBox is only authoritative if engineers consistently update it before making infrastructure changes, not after, not sometimes, but as the first step.
This is harder than it sounds. Under time pressure, updating NetBox feels like overhead. The change needs to happen now; the documentation can wait. And once “it can wait” becomes the norm, the source of truth stops being true. It becomes another partially accurate record that people consult but don’t fully trust.
The operational model needs to make NetBox updates part of the change process, not a separate documentation task. In practice this means automation that reads from NetBox before it runs, so stale or incomplete records produce an obvious error rather than quietly propagating wrong data. The friction is deliberate. It is what keeps the source of truth credible under the conditions where that credibility is most likely to erode.
In a well-structured platform, NetBox becomes a first-class data source in exactly this way: the automation layer queries it for authoritative state before execution, and preflight checks fail if the expected record is missing or inconsistent. That friction is a feature.
Where this fits in a broader automation model
NetBox-driven automation is most valuable in environments where infrastructure changes frequently enough that manual documentation cannot keep up, but carefully enough that every change should be intentional and traceable.
Hybrid environments with on-prem networking, cloud landing zones, and edge capacity are a good fit. The IP space spans multiple environments. The device inventory is heterogeneous, physical servers, VMs, network appliances, cloud resources. The service topology changes as modules are deployed and retired. Keeping all of that coherent without a single authoritative source is possible, it just requires an amount of manual effort that grows with the environment and degrades with team turnover.
The automation model that derives from NetBox does not eliminate the effort of maintaining accurate records. It moves that effort upstream, to the point where intent is declared, and makes everything downstream more reliable as a result. The change control discipline that used to be distributed across multiple partially-accurate systems gets concentrated in one place, where it can be enforced rather than merely encouraged.
Infrastructure becomes predictable when intent is centralised. That is the argument for source-of-truth automation, and it holds regardless of which tool you use to implement it.