1. The modules wrap up a whole set of shell scripting functionality, including the conditionals that would be required to ensure that the script only makes changes when required and can report back on whether the change was made and whether it was successful.
2. There are several ways—you can run the entire playbook with the --limit parameter set, or you can use the when clause within the playbook to ensure that the tasks only run on given hostnames.
3. Name your tasks after the benchmark (including the number) so you can easily identify what they are for. Also, include the level and scoring detail to make it easy to interpret and audit results from playbook runs.
4. Tag the tasks as level1 and level2 accordingly, and then run the playbook with the --tags level1 parameter.
5. The --tags parameter only runs tasks with the tags specified, whereas the --skip-tags parameters runs all tasks except those specified.
6. The CIS Benchmarks are very large in size, and there is no point in reinventing the wheel, especially with open source code as you can audit the playbooks before you use them to ensure they are secure and meet your requirements.
7. It tells Ansible to run in check mode, which means that no changes are performed, but Ansible will try to predict which changes would have been made if it had been run in its normal mode.
8. No—the shell module can't support check mode because it is impossible to know what command someone may have passed to it in a playbook.