By Ivy Samuel
In modern cloud environments, teams can create infrastructure within minutes, but understanding where that infrastructure came from is becoming a much more difficult problem. Oluwafemi Adeyemi, a systems and infrastructure engineer with experience across enterprise infrastructure, DevOps, automation and cloud technologies, believes organisations need to treat infrastructure with the same discipline they apply to software. “If we care about where our software comes from, we should care about where our infrastructure comes from. Every critical resource should have an owner, a history and a configuration that we can trace.”
The issue, Oluwafemi believes, is that cloud environments can quickly become a mixture of automated deployments and manual changes. While a virtual machine could have been provisioned via Infrastructure as Code, a firewall policy could have been modified manually during the incident. Eventually, teams might end up having working environments but not be able to figure out how they got into their present state.
As a strategy for addressing this, Oluwafemi advocates for stronger infrastructure provenance. He believes important cloud resources should be traceable to their source configuration, deployment process, owner, and change history. “An infrastructure resource shouldn’t simply exist in production. We should be able to understand who created it, what configuration produced it, what changed, and how we can reproduce it.”
His approach is related to Infrastructure as Code and automation. Automation solutions like Terraform and Ansible help organisations build and configure environments in a consistent and reproducible fashion, but Oluwafemi contends that mere automation is insufficient. The environment that has been built in production should always stay linked with the configuration used for building that environment. Otherwise, infrastructure drift can gradually create differences between the intended environment and the one actually running.
Another important concern for Oluwafemi is what happens when engineers make manual changes during incidents. Emergency interventions can restore services quickly, but problems emerge when those changes are never documented or returned to the controlled infrastructure configuration. “A temporary fix can become part of production without anyone realising it. Months later, someone can deploy the original configuration and accidentally remove something that had become essential.”
Oluwafemi’s experience managing enterprise infrastructure has given him practical exposure to this challenge. All his experience working in fields such as system administration, infrastructure automation, security, monitoring, and production environments has emphasised the need to maintain infrastructure that is comprehensible, auditable, and replicable. He sees provenance as an operational discipline rather than simply a documentation exercise.
In this case, Oluwafemi notes that infrastructural provenance is a necessary condition for security. This is because when an unexpected modification occurs within a production firewall rule, access policy, or any other form of configuration, it is important to know who modified it, at what time, and whether this was authorised. Such information will be required to investigate such occurrences.
This is similar to how modern software developers deal with application artefacts. Software can be traced to a repository, version, build process, and deployment. Infrastructure, he argues, should have an equivalent chain of accountability. “We already know how to establish provenance for software. The next step is applying that same thinking to the infrastructure the software depends on.”
Oluwafemi’s framework is not theoretical. It is informed by his experience with enterprise infrastructure, configuration management, DevOps practices, and automated environments. His work with technologies such as Ansible and Docker and infrastructure automation has reinforced his view that effective infrastructure should not only be scalable and operational but also understandable and reproducible.
Essentially, the idea is that organisations must not only have a list of the cloud assets that they have, but they must also know the history of the assets, how the assets have been configured, and how things have changed since they were implemented. This creates stronger operational accountability while making troubleshooting, security investigations and disaster recovery more effective.
For Oluwafemi Adeyemi, infrastructure provenance is ultimately about creating a chain of trust around the systems that organisations depend on. “It isn’t enough to know what resources you have. You need to know how they got there and what has happened to them since.” In his view, treating critical infrastructure like a signed software artefact will become increasingly important as organisations operate in more complex cloud and hybrid environments.



