Can check mode be trusted when a playbook mixes core and third-party Ansible modules?

Can Check Mode Be Trusted?

No, check mode cannot be fully trusted when mixing core and third-party modules. While core modules are generally reliable, third-party collection modules vary in their implementation of supports_check_mode. If a module does not support check mode, Ansible skips the task entirely. This creates a "simulation gap" where the state of the system is not updated in memory, and registered variables reflect a skip rather than a predicted change, potentially misleading downstream logic.

The Impact of Skipped Tasks on Playbook Logic

When a task is skipped during a --check run, the registered variable is not left undefined; instead, it is populated with {"skipped": true, "changed": false}. This leads to two primary risks:

• Conditional Failure: A task with when: previous_task.changed will evaluate to false during a check run, even if the task would have actually caused a change during a real run.
• Diff Inaccuracy: The --diff flag only reports changes for modules that actually execute. If a task is skipped, no diff is generated. Furthermore, because check mode does not persist changes, subsequent tasks that depend on the output of a skipped task (e.g., a file created by a skipped template) will report diffs based on the current state of the system, not the simulated state.

Implementation Strategy for Predictable Simulations

To maintain predictability when using third-party modules that may be skipped, use the following patterns:

1. Identify Module Support

There is no single command to list all skipped tasks before execution. You must verify support per module using ansible-doc:

ansible-doc -t module collection_name.module_name

Look for the "Supports check_mode" field in the documentation.

2. Structure Registered Variables for Conditionals

Avoid basing critical logic solely on .changed if the preceding module is third-party. Instead, use a default value or a check for the skipped key:

- name: API Task
  collection.name.module: 
    state: present
  register: api_result

- name: Downstream Task
  debug: msg="Executing because change is predicted or simulation is active"
  when: api_result.changed or api_result.skipped | default(false)

3. Use changed_when for Consistency

If a module's check mode behavior is inconsistent, explicitly define when it should be considered "changed" to force the registered variable into a known state for downstream tasks.

Verification Steps

1. Run the playbook with ansible-playbook --check --diff and specifically look for skipping messages in the output.
2. Insert a debug task - debug: var=your_registered_var immediately following a third-party module to verify if it returns skipped: true.
3. Compare the output of a --check run against a real run on a disposable staging target to identify discrepancies in task execution flow.

Diagnostic Detail Required: Are the third-party modules performing read-only API calls to determine state, or are they entirely opaque to Ansible's check mode?