Ansible check mode handling of unsupported modules

Direct Answers

1. Is there a reliable way to force unsupported modules to become no‑ops during --check without modifying the playbook? No. By default Ansible skips shell, command, and raw tasks in check mode, but if a task explicitly sets check_mode: no it will run despite --check. There is no global flag to override that opt‑out.

2. Does Ansible provide a version‑specific flag or module attribute that guarantees check‑mode safety for all modules? No. The only control is the per‑task check_mode attribute; modules that implement check mode simulate changes, unsupported ones are skipped unless opted out.

3. Should teams treat any playbook containing unsupported modules as ineligible for --check? Not necessarily. A playbook with shell/command/raw tasks can be safely checked provided none of those tasks carry check_mode: no. The presence of unsupported modules alone does not invalidate --check; the explicit opt‑out does.

Default Behavior (Confirmed)

• When you run ansible-playbook --check, tasks using shell, command, or raw are skipped by default. They report skipped and produce no changes on the target.
• Modules with native check mode support (e.g., copy, template, apt, systemd) simulate their actions and report changed or ok without applying changes.

The Opt‑Out Caveat

A task author can add check_mode: no to force execution during a dry run:

- name: Run a script that must execute even in check mode
  shell: ./deploy.sh
  check_mode: no

When this attribute is present, the task runs for real on the target host despite --check. Ansible does not provide a CLI flag, environment variable, or configuration setting to ignore check_mode: no globally.

Practical Verification Steps

1. Create a minimal playbook with a shell task and no check_mode attribute.
2. Run ansible-playbook --check playbook.yml and confirm the task shows skipped.
3. Add check_mode: no to that task and rerun with --check; the task will execute and may modify the target.
4. Search your playbooks for check_mode: no (or check_mode: false) to audit whether any tasks bypass the dry run.

Recommendation

Treat --check as a conditional safety net. It is reliable only when you have verified that no task in the playbook (or included roles) sets check_mode: no. For playbooks you do not control, or where such tasks exist, supplement with:

• Staging environments that mirror production.
• Idempotent module replacements (e.g., use copy + script instead of shell where possible).
• Code review gates that flag check_mode: no usage.

Missing Diagnostic Detail

If you are evaluating a specific playbook, the one detail that changes the recommendation is: Does any task in the playbook (including imported roles) explicitly set check_mode: no? A simple grep -r "check_mode: no" . across the playbook directory answers this.