Provision infrastructure as code

I need the new staging cluster provisioned from our Terraform templates and ready for app deploy by Wednesday. Apply the infrastructure-as-code repo on the build server user ci-runner, target the eu-west-2 project, use the vm.small profile, and include the database subnet and load-balancer modules. Before you hand it to me, verify SSH access for deploy@staging, that the instance tags match billing:staging, and that the outputs file contains the app_endpoint and db_connection_string.

Before I push this IaC change to the team's pipeline, make it easy for reviewers to approve. Surface the net-cost estimate and the change to the number of instances at the top, make the security group diffs findable, and flag any drift from the production naming convention that would make procurement or ops hesitate.

The plan just reported that three production-like VMs will be replaced when I only changed an optional tag. I'm the engineer on call, the project owner is Sam in Platform, and we go to a deploy freeze at 17:00. I fear a rollback will break current sessions and that approval will be refused if I stall. I can't tell whether the replacement is from a subtle change in the module or an external drift. What is the most likely cause and the safest immediate action?

Across the last six months we keep losing time reverting small Terraform edits because VMs get recreated unexpectedly. I own the repo and the on-call rota; the team includes two junior devs and Sam in Platform. I think our habit of editing live variables and not pinning module versions is to blame, but I'm not sure what discipline will stick. What single habit change should I enforce this quarter to stop the churn, and how do I get the team to follow it?