During a disaster recovery drill before an acquisition, a team discovered 47 resources existed only in production, not in their Terraform repository. The infrastructure knowledge lived in one engineer's head, and the backup was sketchy. The deal closed, but with a 90-day requirement to achieve full IaC coverage and successful rebuild tests.
IaC isn't merely a technical preference. It determines whether infrastructure knowledge survives personnel changes and whether systems can be rebuilt without heroic efforts.
What investors evaluate
- Infrastructure coverage matching production reality (not aspirational documentation)
- Version control as single source of truth with audit trails
- Proper state management with remote locking mechanisms
- Environment parity across dev, staging, and production
- Secrets management separate from code
- GitOps patterns for Kubernetes deployments
- Demonstrated rollback capabilities
Red flags during due diligence
- IaC existing but misaligned with actual production
- Unmanaged drift between declared and actual infrastructure
- Credentials embedded in code or CI logs
- Console-based changes treated as routine
- Knowledge concentrated in individual contributors
- Inability to rebuild environments from code alone
Recommended practices
- Weekly drift detection with issue tracking
- Pull request reviews for all infrastructure changes
- Quarterly environment rebuild exercises
- Explicit documentation of intentional exceptions
- Resource tagging for ownership tracking
Your turn
What drift surprise hit you hardest? A security group that only existed in memory? An environment-specific configuration that broke in production? Share the incident.
Originally published on the Tech Due Diligence Playbook newsletter on LinkedIn.