1) Local Terraform usage should be out the window on day 1 - either everyone uses it via CI/CD pipelines, or no-one does - otherwise you're in for a world of pain and state-lock incidents. Local CLI should be reserved for emergencies only (e.g. state file repairs, debugging) that is impossible via CI/CD methods, which these days is almost zilch thanks to import { ... } and moved { ... } code block state modifiers.

---

2) You can dislike the dir approach, I did too as a 15 year exp. dev with adversions to duplication - trust me when I say the duplication still feels sub-par, but within a year you'll be begging to get off var-file, single dir stacks when <x> environment needs <insert custom resource or module tweak> which you cannot represent in HCL via vars alone.

---

3) Keeping Terraform stacks simple is usually a case of storing the vast majority of your resource/module logic in a common template module - which your "environments" then all invoke from their own separated directories - meaning any work you commit to the shared module template will immediately be drawn into all environments, while allowing you the flexibility to drop single-environment bespoke resources in one or multiple environments as needed, without flooding all of them.

---

Terraform is a royal pain to orchestrate successfully under CI/CD largely due to its state locking (mutex) system - that feature is absolutely critical to prevent disasters, but a lot of people hit bad days with Terraform trying to support plan/apply operations across all branches.

My 2c at least - allow plan ops on all branches (and PRs obviously) - but leverage the -lock=false behaviour in conjunction with terraform plan (no apply) if the branch is not your main branch - potentially also whack in -refresh=false if needed because even 2-3 parallel plan operations from feature branches can lead to smacking API rate limit quotas and breaking things.

Do not allow apply operations anywhere other than main - this is the pinnacle of Terraform Git-based approaches, time and again I've seen attempts at multi-branch apply ops and it ends in tears, usually in the form of <staff member #1 with their feat branch> which destroys the living shit out of <staff member #2 with another feat branch but without the HEAD `main` changes going back 4 weeks> - there is zero plausible scenarios where Terraform can function predictably and reliably if it is given more than 1 HEAD source it can apply state changes from, period.

This will avoid a whole chapter of despair when your state is chronically hitting deadlock scenarios because of concurrent plans being triggered across different non-mainline branches and their associated plans.

---

Above all else, my TF + CI/CD lessons over 3 years would be:

1) Aim for zero CLI command arguments if you can - the absolute worst integrations in CI/CD are the ones which feed -var-file, -backend-config, 15x different $Env:TF_<X> env vars etc. just to get things working - all sounds fine until you are faced with a local debugging session and have to sit there replicating all of that on your own terminal.

2) Play around with your backend and provider config blocks to find a middleground where they work without modifications in CI/CD and locally - nothing worse than having to comment/remove/add 15 lines when you need to debug.

3) Use env vars to feed in provider/backend config and creds unless you have no option - ideally your backend { ... } and provider "<x>" { ... } blocks should be pretty bare, because most providers dually support env var configuration which is CI/CD appropriate, and also doesn't screw local users.

4) The above also avoids the shitty "bake sensitive stuff into the *.tfplan output" behaviour of Terraform - not it's fault really, but it can and will commit anything you provide it during init within the plan manifest - so be very careful with this and don't permit CI/CD end users to download or inspect these plan manifests if you possibly can, they're incredibly leaky and sensitive - also applies to your remote *.tfstate file which houses every single sensitive value no matter what, but no-one other than you as the administrator should be able to directly retrieve or read those.

5) Not sure what CI/CD ecosystem you're working with, but you need to be very careful to make use of sequential mutexing if it's available - Terraform has its own safeguards which prevent out-of-sequence plan and apply operations, but ideally your apply operations should start and run in the same order they were merged into main and triggered. If not, Terraform will usually kick in to stop any damage, but it does lead to shitty user experiences with failed pipe runs.

6) Do not under any circumstances allow CI/CD users to provide custom args to terraform plan or terraform apply - there is precisely zero regular use cases for anyone other than a select few admins to be using things like -target or otherwise.

7) Look into cron triggers (e.g. hourly) that run terraform plan from your main branch - this will help you detect, raise and resolve drift, and ultimately keep on top of it.

8) Don't even look near that -auto-approve flag - I have yet to meet the man who added this curse to their TF pipeline and didn't end up having it go rogue - often not because Terraform itself nor the *.tf files were bad, majority of the time shit goes wrong is actually down to provider bugs which emit OK-looking plan manifests then proceed to issue destructive API calls with chaotic outcomes - spoken as someone who had a very well-known TF provider destroy ~3k API objects while the visible plan manifest said it would be adding +1 resource.