1. AWX stores credentials in a manner that is not easily reversible, even to administrators—as a result, it prevents those running automation tasks from accessing secure credentials and making use of them in another context.

2. If two people are working from a set of playbooks, how can you ensure they are consistent? Equally, how can you ensure that you understand the changes that have been made in your playbooks, especially when issues arise? Good version control strategies address these and many more challenges.
3. AWX has all of the dynamic inventory scripts provided as part of the Ansible project built in, along with all supporting libraries. They can be configured through the AWX user interface, and so can be considered to work out of the box, whereas additional work is required to use them on the command line.
4. A project is a logical grouping of playbooks—it might be a single directory on a filesystem or a repository in a version control system such as Git.
5. A template is analogous to the ansible-playbook command, along with all its switches and parameters, which you might run on the command line.
6. This is visible in the Job History pane for each job in the user interface—every job has the Git commit hash stored along with other valuable information about the task that was run.
7. The AWX server itself houses some very sensitive data, including the database, which contains reversibly encrypted credentials. Also, it is possible to run playbooks from a known path on the local filesystem of the AWX host and so, to enforce version control usage, it is important that as few people as possible have access to this server.
8. AWX has a built-in scheduler that can run playbooks at a time of your choosing (either as a one-off or regularly).