In an Ansible task, what does the when keyword do, and why is its expression written without the {{ }} delimiters?

## What when does `when` is the conditional on an Ansible task. Ansible evaluates its expression separately **for each host** in the play, using that host's variables and facts, and runs the task only where the result is truthy. Where it is false, the task reports `skipped` for that host and the play moves on. ```yaml - name: Install the RPM package ansible.builtin.package: name: nginx state: present when: ansible_facts['os_family'] == 'RedHat' ``` Because evaluation is per host, one play can branch across a mixed fleet without splitting into separate plays. ## Why no curly braces In Jinja2, `{{ ... }}` means "substitute the value of this expression into surrounding text". It is for building strings. The `when` value is not a string to be templated — Ansible hands it to the template engine as a **bare expression** and uses the resulting object directly. So the variable name goes in raw: ```yaml when: install_nginx # right when: "{{ install_nginx }}" # warns, and can misbehave ``` Modern ansible-core emits a warning for the braced form ("conditional statements should not include jinja2 templating delimiters"). The practical hazard is that templating a boolean can hand back the *string* `"False"`, and a non-empty string is truthy — so the task runs when you expected it to skip. The same reasoning applies to `changed_when`, `failed_when`, `until` and `assert`'s `that`: all of them take raw expressions. ## The string-truthiness trap Variables that arrive from the command line (`-e enable_tls=false`), from an INI inventory, or from some environment sources are strings, not YAML booleans. `when: enable_tls` is then testing a non-empty string and is always true. The defensive form is explicit: ```yaml when: enable_tls | bool ``` A value defined in YAML as `enable_tls: false` really is a boolean and does not need it, but the filter is harmless and makes the task robust to how the value was supplied. ## Combining conditions A YAML list of conditions is ANDed: ```yaml when: - ansible_facts['os_family'] == 'Debian' - ansible_facts['distribution_major_version'] | int >= 12 ``` This is the readable way to express several requirements. For OR you write one expression with `or`. Jinja tests are available and idiomatic: `is defined`, `is not defined`, `is truthy`, and — against a registered result — `is failed`, `is succeeded`, `is skipped`, `is changed`. ```yaml - name: Check the health endpoint ansible.builtin.uri: url: http://localhost:8080/health register: health failed_when: false - name: Report the outage ansible.builtin.debug: msg: "health check failed" when: health is failed ``` ## when with loop, and when on a block With `loop`, the condition is evaluated **per item** — items that fail it are skipped individually, and the task as a whole may report a mix. That is a common source of confusion: `when` does not gate the loop, it gates each iteration. `when` on a `block` is distributed to every task in the block, which is the tidiest way to guard a group of related tasks with a single condition rather than repeating it five times. ## Consequences of a skip A skipped task **notifies no handlers**, because notification requires a `changed` result. It also registers a result object whose `skipped` field is true — so a later `when: earlier_task is skipped` works, but a later task that assumes `earlier_task.stdout` exists will fail with an undefined-attribute error. Guard downstream uses with `is not skipped` or `is defined`. ## Where when is the wrong tool If the condition is really "only do this on hosts in group X", the host pattern on the play or a group-scoped play is clearer than a `when` on every task. And if the condition is "only if this file does not exist yet", most modules are already idempotent — checking the state yourself with a `stat` task and a `when` re-implements, usually worse, what the module does natively.