In an Ansible play, how do you let a task fail without aborting the run, and what does block/rescue/always give you that ignore_errors does not?

## The default: a failed host leaves the play When a task fails on a host, Ansible removes that host from the rest of the play. Other hosts continue; the failed one runs no further tasks and, importantly, none of its pending handlers. That default is usually right — you do not want to keep applying a half-broken change — but it gives you no way to react. ## ignore_errors: the blunt tool ```yaml - name: Best-effort cache warm ansible.builtin.command: /usr/local/bin/warm-cache ignore_errors: true ``` The host survives the failure and the play continues. Two things people forget: the task is still **reported as failed** in the output (it just is not fatal), and the suppression is total — a typo in the path, a permissions problem and the expected condition are all swallowed identically. `ignore_unreachable: true` is the separate keyword for a host you cannot connect to at all; `ignore_errors` does not cover that case. ## failed_when: define failure correctly instead of hiding it Often the task is not really failing — your definition of failure is just wrong for that command. `failed_when` takes a raw Jinja expression (like `when`) and replaces the module's own verdict: ```yaml - name: Query the migration tool ansible.builtin.command: /usr/local/bin/migrate --check register: migrate failed_when: migrate.rc not in [0, 1] changed_when: migrate.rc == 1 ``` This is the better answer whenever the non-zero exit is a documented, meaningful outcome. It keeps the recap truthful, whereas `ignore_errors` makes the recap lie in the other direction. ## block / rescue / always `block` groups tasks so keywords apply to the group; `rescue` and `always` turn that group into structured error handling. ```yaml - name: Deploy with rollback block: - name: Take the node out of the pool ansible.builtin.command: /usr/local/bin/lb-drain changed_when: true - name: Install the new release ansible.builtin.unarchive: src: "/tmp/app-{{ release }}.tgz" dest: /opt/app remote_src: true - name: Smoke test ansible.builtin.uri: url: http://localhost:8080/health rescue: - name: Roll back to the previous release ansible.builtin.command: /usr/local/bin/rollback changed_when: true always: - name: Return the node to the pool ansible.builtin.command: /usr/local/bin/lb-add changed_when: true ``` Semantics worth stating precisely: - If a block task fails, the **remaining block tasks are skipped** and control moves to `rescue`. - If `rescue` completes without failing, the host is **no longer failed** — the play continues normally for it. This is the property `ignore_errors` cannot give you: recovery, not suppression. - If a rescue task itself fails, the host fails for real. - `always` runs on both paths, including the success path where rescue never ran. It is the cleanup slot. - Inside `rescue`, `ansible_failed_task` and `ansible_failed_result` describe what went wrong, so you can log or branch on it. - A task inside the block with `ignore_errors: true` never triggers rescue, because the block sees no failure. This surprises people who mix the two. ## Keywords on a block Because a block is a task container, keywords set on it apply to every task inside: `when`, `become`, `tags`, `vars`, `delegate_to`. Guarding six related tasks with one `when` on a block is both shorter and less error-prone than repeating it six times. Blocks can be nested, though deeply nested error handling is a smell. ## Choosing between them in an interview The answer an interviewer is listening for is a decision rule, not a feature list: - The command's non-zero exit is a **legitimate outcome** → `failed_when`. - A genuinely optional, best-effort step whose failure means nothing → `ignore_errors`, sparingly, and with a comment saying why. - The failure needs a **reaction** — roll back, notify, mark the host — or there is state that must be undone whatever happens → `block/rescue/always`. One more operational note: `always` is the right home for anything that restores availability (returning a node to the load balancer, clearing a maintenance flag), precisely because it runs on the failure path too. Putting that step as a plain task after the block means a failure skips it and leaves the node drained — a classic 3am incident with a very boring cause.