Or said another way -- deletion is dangerous. I've observed that mixing the convenience of automation with the risk of hard deletion is fraught with peril. If you really need automation around deletion, it's best to set up roadblocks and use tombstoning approaches, where archive/backup data is sent to S3 Glacier or something of that ilk. Storage is cheap enough these days that there's no reason not to.

Although the scope is smaller and therefore should be safer, it is still necessary to purge old logs and old backups, etc. in some places.

When I need to do this, I make sure there's a specific /logs or /backups folder where only certain filetypes of a certain modified dates are deleted.

The point of the tooling is that you describe what you want your deploy to look like, and it updates the deploy to match the description. If you delete something from the description and it stays running, that would be very confusing.

I haven’t used their particular tool (ArgoCD) but the ones I have used include an option to keep specific pieces of infrastructure around even when it’s deleted from the description. That’s absolutely what you should be doing for anything that stores data.

ArgoCD will also not delete resources by default when the file is removed from the git repo. The author explicitly enabled auto-pruning.

It's not too bad. There are two approaches to this one in AWS: 1. You can mark specific resources like db and volumes to be retained on stack deletion. 2. You can't delete some resources easily without deleting the content. Wanna delete a bucket? Explicitly delete all the objects first.

It works ok in practice.

What you're describing as "confusing" is exactly how every CI tooling I've worked with functions.

You describe what you want your deploy to look like, and that's what gets deployed. It doesn't start removing/deleting things to match.

It might take resources offline or leave them orphaned, but never delete them.

Running is different from existing.