# Made check mode tell the truth across the whole platform after finding six probes deciding on a value the host never gave, because Ansible's command module reports success under --check while skipping the command entirely. 2025 **Situation.** A dry run against production is supposed to be the safe way to find out what a change will do. In September 2026 a dry run failed on an assertion that was simply wrong about the host, and advised the operator to set a flag that would have relaxed a security sandbox. The dry run had not read the host. It had read a value the host never gave and drawn a conclusion from it. **Task.** Every probe whose result feeds a decision had to be made honest under check mode, and the ones that could not be had to say so out loud instead of staying quiet. **Action.** The cause is a property of the tool that is documented and easy to forget: the command module does not execute under check mode, and what it registers is not an empty result — it is a success with empty output. Any conditional reading that register therefore decides on a value that was never measured, and it decides in whichever direction its own logic happens to point. A sweep of every registered probe found six of them, each lying differently: one reported that the supervisor accepts every unit directive without having asked the supervisor, another reported nothing to do on a host with the firewall switched off. Each was given one of two shapes. A probe that reads pre‑existing state the run has not touched is marked to run even under check mode. A probe that cannot run is skipped, and a message names what was specifically not verified — because silence in a run log reads exactly like a pass. **Result.** A dry run now either measures something or says it did not, and neither of those is the third option it used to have. The general rule went into the development guide in the same change: check mode must not lie, and a probe that cannot see is required to announce its blindness rather than infer a verdict from it. --- - Role: Infrastructure Automation Engineer - Categories: [DevOps](https://engineer.company/categories/devops/), [Infrastructure](https://engineer.company/categories/infrastructure/), [Automation & CI/CD](https://engineer.company/categories/automation/), [Reliability & Backups](https://engineer.company/categories/reliability/), [Linux & Servers](https://engineer.company/categories/linux/), [Testing & QA](https://engineer.company/categories/testing/) - Services: [Infrastructure as Code](https://engineer.company/services/infrastructure-as-code/), [DevOps & CI/CD Automation](https://engineer.company/services/devops-cicd/), [Site Reliability & Monitoring](https://engineer.company/services/site-reliability/)