Red Hat Ansible Automation Platform has been great to learn and excited to see what else I can do with it

Getting started with Red Hat Ansible Automation Platform was difficult for me. Having to learn yaml to get started, setting up secrets and learning the ins and the outs of Red Hat Ansible Automation Platform had a learning curve that I am still trying to overcome. The hardest thing I have had to do with Red Hat Ansible Automation Platform is find its limitations but when I did find them, see if there were ways around it. I found the Red Hat Ansible Automation Platform documentation less helpful than finding people with similar issues on Reddit or stack. There are so many modules available its hard to keep track of them so you will find yourself relying on specific ones that may not actually be the right tool for the job but you can make it work. Currently we are having issues with WinRM on RHEL8 after our RHEL7 machines was decommissioned and that had it working on it. Some of this comes down to the nature of our environment. While it does not overshadow the amazingness of Red Hat Ansible Automation Platform, it does certain things difficult and in some cases redirects our attention to other tools. Again, I want to stress I am pretty new to Red Hat Ansible Automation Platform...so this could all be a limitation of my knowledge. But I feel that as a tool, the documentation could be better.

We use Red Hat Ansible Automation Platform to push out STIG hardening requirements which makes deploying machines effortless. Ideally we should be working the full deployment process via Red Hat Ansible Automation Platform which would significantly decrease the deployment process as we can running it through a CI/DI. That all being said, I have tried using Red Hat Ansible Automation Platform to do other system monitoring tasks like monitoring disk space or CPU usage and did not find it useful enough as I could not narrow down the data to manageable amount. I was able to cobble together a playbook that would shutdown containers during patching before allowing a reboot. Then running another playbook that would verify the machines were up and certain services were running before starting up containers in a specific order.