Changes, whether intentional or unintentional, maybe even well-planned changes in highly complex systems, can cause drifts. All involved parties in the integrated environment must be informed during the planning stage to avoid configuration drifts. (During the planning stage, all involved parties must be reported to prevent configuration drifts.)
At times, code changes cannot wait for a planned release and need to be made immediately. Failure to document these changes can lead to unplanned downtime in the production environment later. This situation is a perfect breeding ground for configuration drifts.
CI/CD pipelines usually have built-in checks for errors. However, you will have many more errors to deal with without automation. Automation with the help of Configuration Drift Management Tool can detect and even stop configuration drifts before they become a problem.
Sometimes, developers are granted elevated permissions to troubleshoot problems. We all have been in situations where "something needs to be quickly" and permissions were granted temporarily. But then those permissions were never revoked. There's how IAM Drift or Privilege Identities born building the foundation for a future mishap.
Any inconsistency or gap between the Product Development Life cycle and deployment to the Cloud can be called a cloud drift.
It is very convenient to imagine that all drift is bad drift. Most drifts are bad, but there is some desirable and good drift. Knowing the difference and recognizing good from bad is essential. This can save a lot of sleepless nights and frustration for your team.
Whether big or small, cloud infrastructure, drift detection, and correction should be practiced. Practicing these early will save you a lot of time and frustration in the future.