Configuration Drift: Why Your Audit Trail is a Lie
The Audit Question Nobody Can Answer You're in a compliance meeting. Your auditor asks: "Who changed this critical setting? When? Why?" Your ops team opens CloudTrail. Finds the API call. Sees the ...

Source: DEV Community
The Audit Question Nobody Can Answer You're in a compliance meeting. Your auditor asks: "Who changed this critical setting? When? Why?" Your ops team opens CloudTrail. Finds the API call. Sees the timestamp. But the auditor's next question kills the meeting: "Who actually made that decision? Was it approved? Did the change cause the drift we found?" Silence. Because your audit log proves an event happened. It doesn't prove why it happened, who authorized it, or what the system state was before. That's configuration drift. It's not a technical problem—it's an audit problem. Why Logs Fail Configuration drift detection tools (Terraform drift, CloudFormation drift, policy monitoring) tell you what drifted. They don't tell you: Who decided to drift — API calls show "service account," not the human decision Whether it was approved — Change requests and logs are separate systems; they diverge Intent vs. accident — A config change could be intentional optimization or sloppy rollback Causal cha