A developer manually changed an AWS security group rule through the AWS Console. How will Terraform handle this on the next terraform apply, and how do you fix it without tearing down the resource?
Quick Answer
Terraform detects the drift during the refresh phase of the next plan because the real-world state no longer matches what's recorded in the state file, and it will propose changing the rule back to match your .tf configuration. To fix it without destroying anything, either update your Terraform code to match the intentional manual change, or run terraform apply to silently revert the console edit back to the declared configuration — both are non-destructive since security group rule updates are in-place.
Detailed Answer
Think of Terraform's state file like a librarian's card catalog. The catalog says exactly which books are on which shelf. If someone walks in and rearranges a shelf without telling the librarian, the catalog is now wrong — not the shelf. The librarian's job on the next inventory check is to notice the mismatch and either update the catalog or put the books back where the catalog says they belong.
Terraform was designed around the idea that the .tf files are the single source of truth, and the state file is a cached snapshot of what Terraform believes exists in the real world. A manual console change never updates that cached snapshot, so the two diverge. This is intentional: Terraform does not constantly poll AWS in real time, because that would be slow and expensive at scale, so it only reconciles differences when you explicitly run a plan or apply.
Internally, terraform plan first performs a refresh: it calls the AWS API for every resource tracked in state (in this case, describe-security-groups) and compares the live attributes against what's stored in state. When it finds the ingress or egress rule block doesn't match, it marks that resource as having a diff. Because security group rules are updated in place via the AWS API (authorize/revoke operations), Terraform generates an update-in-place plan, not a destroy-and-recreate plan — so running apply is safe and reversible, it will not tear down the security group or the resources attached to it.
At production scale, this scenario is exactly why teams enable drift detection dashboards (terraform plan run on a schedule, or tools like driftctl) and lock down console write access via IAM policies or SCPs, so that engineers cannot fat-finger a manual change during an incident and forget to backport it into code. Some teams pipe scheduled drift-detection plan output into Slack so nobody discovers a silent revert three weeks later during an unrelated deploy.
The non-obvious gotcha: if the manual change was actually the correct fix (say, the developer opened port 443 during a live incident to unblock a partner integration), running terraform apply without updating the .tf file first will silently revert that fix and could reopen the incident. Always diff the plan output carefully before applying — a clean 'this brings your infrastructure in line with configuration' plan can mean 'this undoes an emergency fix' just as easily as 'this reverts an accidental change.'