Infrastructure Drift Management
You run infrastructure drift management by comparing your Git code against live cloud resources. When the live setup does not match your code, you update one to match. Most teams set up scheduled jobs in their code pipelines to check for changes. Still, broad cloud roles let engineers log in and change live settings by hand. Those manual edits bypass the code pipeline and break the saved state file. How native infrastructure drift management works Teams start by writing their cloud setup as c
Cloud Infrastructure Entitlement Management (CIEM): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You run infrastructure drift management by comparing your Git code against live cloud resources. When the live setup does not match your code, you update one to match. Most teams set up scheduled jobs in their code pipelines to check for changes. Still, broad cloud roles let engineers log in and change live settings by hand. Those manual edits bypass the code pipeline and break the saved state file.
How native infrastructure drift management works
Teams start by writing their cloud setup as code in a shared Git repo. When the pipeline runs, the tool creates cloud resources and saves a state file. That state file acts as a map between your code and the real cloud. A scheduled job then runs a read-only check every few hours or every night.
During this check, the tool reads the current cloud setup through the provider API. It compares the live values against the saved state file and the Git code. If every setting matches, the job finishes and logs a clean result for the team. If a setting differs, the tool flags the resource as drifted and sends an alert.
At that point, the team must choose how to fix the mismatch. If the manual change was a mistake, the team runs the pipeline to overwrite it. The tool pushes the Git settings back to the cloud and restores the intended state. If the manual change was needed during an outage, the team updates the Git code. Once the code matches the live setup, the next check passes with zero differences.
Why manual changes happen during incidents
Code pipelines take time to review, approve, and run from start to finish. When a database or network fails at night, on-call engineers need a fast fix. Waiting ten minutes for a code review and pipeline run hurts users right away. So the engineer logs in to the cloud console or runs a direct command. They change a firewall rule, resize a server, or edit a database parameter in seconds.
The outage ends, and the app works again, so the engineer goes back to sleep. Nobody writes a pull request the next morning to copy that change into Git. Days later, another engineer merges a routine code change in the same repo. The pipeline runs and wipes out the manual fix because it was never in Git. The outage comes right back, and the team wastes hours finding the lost setting.
Cloud Infrastructure Entitlement Management (CIEM): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What native state checks solve and what they miss
Native state checks do a good job of finding changes after they happen. They help teams spot forgotten console edits before the next pipeline run overwrites them. They also show when a cloud provider updates a default field behind the scenes. Having a daily report keeps the state file from getting too far out of date.
Still, state checks only look at the aftermath of a change. They do not govern what engineers do when they log in to live systems. Cloud roles decide who can log in, not what individual commands do in flight. If an engineer has write permissions for emergencies, they can run any command at any time. Native drift tools cannot ask for peer approval before a risky live command runs. They also cannot mask sensitive fields like emails or card numbers in command outputs. You find out about the change hours later, without knowing why the engineer ran it.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
What causes cloud state to drift from Git code?
Drift happens when someone edits live cloud resources outside the main code pipeline. Common causes include emergency console fixes, ad-hoc scripts, and automatic cloud provider updates.
How often should teams run drift detection checks?
Most teams run automated read-only checks once a day or before every deployment. Running checks on a schedule catches manual edits before the next deploy overwrites them.
Should teams fix drift by updating code or overwriting the cloud?
If the live change was an unapproved mistake, overwrite the cloud from your Git code. If the change was a valid emergency fix, copy the new settings into Git first.