С какими модулями Ansible знаком

Что проверяют

Не список названий, а понимаете ли вы идемпотентность и то, что модуль описывает желаемое состояние, а не команду. Заодно смотрят, работали ли вы после переезда модулей в коллекции: человек, который знает только короткие имена, давно не открывал документацию.

Как отвечать

Называйте модули группами и полными именами.

• Пакеты и файлы: ansible.builtin.apt, dnf, универсальный package, copy, template на Jinja2, file для прав и каталогов, lineinfile и blockinfile для точечных правок, unarchive, get_url.
• Система: systemd_service, service, user, group, cron, а также mount, sysctl и authorized_key из ansible.posix.
• Проверки и поток выполнения: stat, assert, wait_for, uri для запроса к поднятому сервису, debug, set_fact, include_tasks, и command с shell как крайнее средство.
• Из коллекций: community.docker, community.general, community.postgresql, kubernetes.core.k8s, коллекции облачных провайдеров.

Главное, чем ответ отличается от перечисления: почти все модули принимают state, сами сообщают, изменили они систему или нет, и на этом держатся обработчики по notify и запуск с --check --diff. Добавьте про секреты: ansible-vault и no_log: true на задачах, где переменная попадёт в вывод.

Где спотыкаются

Ставят shell и command там, где есть готовый модуль. Такая задача каждый раз считается изменившей систему, ломает холостой прогон и делает повторное применение плейбука непредсказуемым. Если без команды никак, ей нужны creates, removes или явный changed_when.

Второе: правят конфиг десятком вызовов lineinfile. Файл целиком описывается через template, тогда результат воспроизводим и не зависит от того, что в этом файле лежало раньше и кто его трогал руками.

Третье: перезапускают сервис отдельной задачей в конце вместо обработчика по notify. Обработчик сработает только при реальном изменении конфигурации, а безусловный перезапуск это лишний простой на каждом применении.