certslothcertsloth
EX294/Topic 04

Red Hat / Advanced

Handlers, Failure Paths and Idempotence

2 min read5 recall promptsReviewed 2026-10-10

Memory hook: A change should trigger only the work it requires.

Must remember

Handlers run when notified by changed tasks, typically at defined handler execution points. Multiple notifications normally coalesce for a handler rather than restarting a service for every changed line. A template task can notify a service restart after a valid configuration is deployed. Handler names/listen topics must match the intended notification.

changed_when defines when a task reports change; failed_when defines failure criteria. Use them to reflect real semantics, not to hide errors. A command returning zero can still leave the wrong state, while a documented nonzero result may represent an expected condition. If change reporting is wrong, notifications and idempotence checks become misleading.

Blocks group related tasks; rescue handles supported task failures and always runs cleanup according to Ansible's error rules. Unreachable hosts and invalid task definitions do not behave like every normal failed task. ignore_errors continues after certain failures but does not repair the underlying problem or handle every failure class.

Use retries with an until condition for transient readiness, including bounded delay and attempts. A fixed sleep waits without checking whether the service became ready. Control rollout batches with serial where availability requires it, and consider how failure thresholds affect remaining hosts.

Idempotence means repeated execution converges on the desired state without unnecessary changes. Verify a second run, but remember zero reported changes is not proof of correctness if conditions skipped everything. Confirm service behavior, security settings and reboot persistence independently. Translate imperative scripts into modules and guarded operations rather than copying each shell line into a task.

Choose under exam pressure

Requirement Choice and reason
Restart only when configuration changes Notify a handler from the changed task.
Wait for a service to become ready Bounded retries with a real condition.
Limit hosts affected at once A deliberate serial rollout and failure policy.

Traps

  • changed_when: false can hide real changes and prevent needed handlers.
  • Ignoring an error does not make the desired state true.

Active recall

1. Why use a handler?

To run dependent work when a meaningful change occurs, avoiding unnecessary repetition.

2. failed_when versus changed_when?

Failure classification versus change reporting.

3. What is rescue for?

A controlled response to supported failed tasks within a block.

4. Why prefer until to a fixed sleep?

It tests readiness and can finish early or fail meaningfully.

5. What proves idempotence usefully?

A repeat run plus independent state/function checks, not merely a quiet recap.

Sources

CLOSE THE NOTES. EXPLAIN THE CHOICE.

How well could you recall it?

Your next review is based on this answer. Progress stays in this browser.

Search across every published topic.