You could work in some way without a state but actually the state is a feature which helps you. Imagine you go down the ansible route and you write idempotent

You could work in some way without a state but actually the state is a feature which helps you. Imagine you go down the ansible route and you write idempotent ansible code than you could argue: “See. I don’t need state. My code is idempotent. I just use this playbook to apply” Now think of deleting resources. You could have a delete playbook maybe. Then how would choose whether to create or delete stuff? Maybe a colleague gives you a ticket: “please delete” Now there are various scenarios: You do your thing (on your laptop) and tell everybody else in your team to not run the CreatePlaybook as you have to run the DeletePlaybook first for this one machine. Afterwards you delete the actual machine/resources from your ansible repository and tell the team: “please use the newest main branch”. So: Here is your equivalent to terraform state, the coordination effort on your side since you are the only person who currently “knows” what’s going on with deletion/applying. So your next idea is: “no problem, I make a Pipelines which runs the playbook on your behalf”. And the pipeline will update maybe the Git repo accordingly in some way - after the run (since ansible needs to know in the run, what to delete). Everybody can see the pipeline . The pipeline will ensure you sequentially apply the playbooks to coordinate with your colleagues. Next problem: how does the pipeline know which playbook and resources to run on? You create a selection box for your hosts and for the playbook yaml to trigger the pipeline. => there is your state. Your ticket information are transferred to your manual labor to fill in the correct items in your selection box. To reestablish want went on you now have to look in the ansible code and the pipeline Paramus and pipeline logs. More examples are: you only want to update some stuff with your ansible playbook. Therefore you might introduce tags on the resources and the playbook knows how to handle those tags. The extreme case might be: TTag:state:present, tag:state:absent. Then you can run a single playbook which can call the deletion and installation playbook for you and everybody is happy that you have everything visible in Git. Problem here: your 2 step process to decommission things from git. First a commit which sets state:absent. Then run the pipeline and then another git commit to delete the code. So what I am saying is: You can do all of this with ansible for sure. But you will have state somewhere: In a Ticket, a Pipeline log, in git, in a wiki I am not saying absible should not be used. It makes sense to configure things. (I personally would wrap a terraform hull around my absinble code and call it, just to have terraform handle the locking for my playbooks) But just watch out for the hidden state in your workflows and better make it explicit. This is why people love GitOps for traceability. You can all do this by hand and document your process in a Wiki for your colleagues so that they known what the “tag:state:absent” means for them. Or you can rely on somebody who has done this for you already and maintains documentation and what not.