The last task of the Ansible playbook involves manipulating files. Since Ansible attempts to parallelize execution when there are multiple hosts, that task should be somehow declared as "serialized".

The way to do that is through throttle: 1, or by setting serial: 1 and executing the entire play on a single host at a time.

Since the swapfile is not being "unmounted" (swapoff'd) when detected, the
system refuses to remove it or overwrite it (lucky!).

Thus, the bootstrap playbook, though not exactly required to be so, is no longer
idempotent.

Perhaps a comparison between the actual file size and the file size being
"requested" should be made to avoid having to let go of swap when running the
bootstrap plays on a machine that has undergone the process before.

fail2ban can help prevent (or at least slow down) brute-force attacks on the
active services of each host, listening in on incoming connections and when a
certain number of retries has been reached, graylisting or blacklisting the
origin IP.

It would be interesting to set it up on the bootstrap playbook and/or on the
essentials playbook, to ensure hosts in the Ansible inventory are moderately
secure.

Add behavior to optionally create a file for swap in disk through setting an
Ansible fact, potentially set in the inventory.

A firewall can be used to strengthen security policies across a computer network, keeping some ports completely closed while allowing services to listen on specified ports for a certain protocol on a specific firewall zone.

Setting up a firewall like firewalld should probably be part of the bootstrap process of new hosts, and should hence be featured in the bootstrap.yml playbook. There's an Ansible module for it, which can be used later on for playbooks that ensure services can listen on given ports.

Add a playbook that adds users according to a directory tree with "branches" corresponding to machines and groups on the target machine, and leaves (files) corresponding to users and their public SSH keys.

It is unlikely there will be more users than me on my target machines, but hey, it would at least be interesting to have the option readily available whenever I find friends with whom to collaborate on things.

Create a GitHub Actions workflow to (perhaps periodically) run the Ansible playbooks present in this repository. The inventory, while not exactly sensitive information, can be kept as an Actions secret. Similarly, the private SSH key(s) used to authenticate with the user Ansible will be using in the target hosts would be a secret as well.

This way we can automate some server tasks.

This repository is a collection of playbooks used for many things. It could very
well be an Ansible collection instead of a bare repo with a few playbooks.