Configuration Drift
partialContainedconfiguration failure · linear propagation
Blast Radius
0%
0/22 nodes
Time to Detect
Configuration drift without tooling may take days to weeks to detect, often discovered only when a condition-dependent failure occurs. With automated drift detection (Ansible, Puppet, Terraform plan), detectable within minutes of the drift occurring.
Preventive Mitigations
2
Confidence
StrongFailure Cascade
(no topology nodes mapped for this failure mode)
This failure mode is referenced in the scenario knowledge but has no connected topology nodes. Impact scope is scenario-level, all components should be considered potentially affected.
Severity at this step: partial
Detection Signals
Recovery time estimate: Identifying the drift and scope: minutes to hours depending on tooling. Applying configuration correction: minutes (automated) to hours (manual). For immutable infrastructure: deployment time (typically 15–60 minutes).
Mitigation Checklist(2 preventive, 1 reactive)
Package configuration into container images or AMIs. Configuration changes produce a new image version; all instances are replaced with the new version. No in-place mutation means no drift surface. Kubernetes deployments naturally implement this.
Store all configuration in git. A GitOps controller (ArgoCD, Flux for Kubernetes; Ansible Tower for host-level config) continuously compares git state against running state and applies corrections. Manual changes are overwritten at the next sync cycle (typically within minutes).
Run Ansible/Puppet/Chef in check/dry-run mode on a schedule (every 30 minutes). Alert when drift is detected. This does not auto-remediate but provides early detection before condition-dependent failures occur.
Affected Systems
Workloads
Blast radius analysis is derived from structured topology and failure mode knowledge. It models structural propagation patterns, not measured production behavior. Actual incident scope depends on runtime conditions, traffic, and recovery actions in place at the time of failure.