Concept and mechanism
Check mode helps anticipate changes but depends on module support and available data. Some tasks are skipped, and registered results may not represent a real run. A task with check_mode=false runs normally even when the playbook receives --check. Therefore inspect content before treating simulation as a guarantee of no writes. Diff displays differences and may reveal secrets. For a configuration template, validate allows checking the temporary file before copying it to the final destination. The %s placeholder identifies the file to validate; the option does not interpret shell pipes or expansion.
Guided application
Handlers connect changes to later actions such as reloading a service. They are notified when a task reports changed and execute in definition order rather than notify-list order. Several notifications before the same flush do not require several restarts. Automatic execution points exist between play sections; meta:flush_handlers can run pending handlers earlier when a subsequent check needs active configuration. In a fictional scenario, the template changed but the functional test still reads the old process. Validate the template, activate configuration at the intended point, and only then check service behavior. A handler may run again if notified after a flush.
Validated file, pending handler, old process: functional validation must follow intended activation.
Common pitfalls
Check as a universal guarantee; diff with secrets; notify as ordering; handler once under every circumstance.
Related topics: Inventory and execution context · Tasks and desired state · Batch orchestration
Distinguish prediction, file validation, activation, and function.
Reference: Validating tasks: check mode and diff mode · Ansible community 14 / ansible-core 2.21 documentation consulted 2026-09-30; executor, collection and plugin compatibility requires confirmation