How do you find out what Puppet would change on a node or fleet without letting it change anything, and what are the limits of that report?

## Turning enforcement off without turning inspection off Puppet's apply step is already a compare-then-write: for each resource, the provider is asked what the current state of each managed property is, and only differing properties are written. No-op mode simply stops at the compare. Everything before it still happens — Facter runs, facts go to the server, the catalog is compiled, the graph is walked, providers read live state. What changes is that the agent logs and reports each out-of-sync resource as a `noop` event rather than correcting it. There are three places to switch it on, and they nest: ```bash # One run, right now, showing file content diffs sudo puppet agent -t --noop --show_diff ``` ```ini # /etc/puppetlabs/puppet/puppet.conf — every run on this node is no-op [agent] noop = true ``` ```puppet # Per resource, in the manifest service { 'nginx': ensure => running, noop => false, } ``` The per-resource `noop` metaparameter overrides the run-level setting in both directions: `noop => true` makes one resource report-only during an otherwise enforcing run, and `noop => false` makes one resource apply for real even during a no-op run. That second form is how a module author keeps something safety-critical enforced while a team evaluates the rest of a change. The `-t` (`--test`) flag is worth knowing separately: it bundles the options you want for a one-off interactive run — a single foreground run, verbose output, no splay — so `puppet agent -t --noop` is the standard "tell me what you'd do, now" invocation. ## What you legitimately use it for **Reviewing a change before it enforces.** Pin a canary node group to the candidate environment, run no-op there, read the report. This is the closest Puppet gets to a preview of a code change against real machines, and it is far more informative than a syntax check because it runs against actual node state. **A fleet-wide "what is out of sync" pass.** Because no-op runs post normal reports, and reports land in PuppetDB, you can query across the fleet for nodes with pending changes rather than reading logs node by node. **Bringing a legacy machine under management.** Point a catalog at a hand-built server in no-op first. The report is the inventory of everything you are about to overwrite, which is precisely the list you want before the first enforcing run. ## The limits, which are the interesting half of the answer **It only knows what you declared.** Puppet is not a whole-machine auditor. A resource nobody wrote does not exist as far as the report is concerned — an extra cron entry, a stray package, a firewall rule added by hand. A completely clean no-op run means "everything I manage matches", not "this node is correct". Confusing the two is the classic misreading. **Cascading effects cannot be simulated.** Because nothing was written, the run cannot observe what would have followed. A package that would have been installed was not, so the config file templated against it, the service that would have been refreshed, and any `exec` gated on its presence are all reported against a node state that never came into being. Expect the first real run to produce more events than the no-op run predicted, especially on a node that is far from desired state. **`exec` behaves specially and it matters.** In no-op mode an `exec` resource does not run its command — but its `onlyif`, `unless` and `creates` guard conditions *do* execute, because that is how Puppet decides whether it would have run. A guard with side effects therefore still has them during a "dry run". Guards should be cheap, read-only checks; this is one of the concrete reasons why. **It is a report, not a lock.** Setting `noop = true` on a node stops enforcement, and stopping enforcement is not free: the node quietly drifts for as long as it stays that way, while still reporting in and looking healthy on a dashboard. No-op left on "temporarily" during an incident is a genuinely common way to end up with a fleet nobody is enforcing. **Exit codes need checking against your version before you gate on them.** `--detailed-exitcodes` distinguishes "nothing to do" from "changes" and "failures", which is what a CI drift-check job keys on — but confirm how your Puppet version reports a no-op run's pending changes before wiring a pipeline to fail on it.