Ansible Handlers and Notifications Flashcards

In Ansible, what is the primary purpose of using handlers instead of regular tasks for service restarts?

Answer: Handlers prevent redundant restarts by only running once even when notified multiple times, maintaining idempotency

The main value of handlers is deduplication—ensuring a service is only restarted once regardless of how many configuration changes triggered notifications.

What status must a task report for its 'notify' directive to actually queue the handler?

Answer: changed

Only tasks with a 'changed' status trigger their notified handlers. 'ok' means the system was already in the desired state, so no handler execution is needed.

How do you define a handler in an Ansible playbook that restarts the 'httpd' service?

Answer: handlers:\n - name: Restart Apache\n service:\n name: httpd\n state: restarted

Handlers use the same syntax as tasks (name + module + args) but are placed in the 'handlers' section.

What is a common anti-pattern when using Ansible handlers, and how should it be avoided?

Answer: Using generic names like 'restart service' across multiple roles causes conflicts; use role-prefixed names like 'apache : restart service'

Generic handler names across roles create naming conflicts since handlers are globally scoped. Role-prefixed names prevent unintended handler calls.

When using Ansible with 'serial' execution (rolling updates), when do handlers run?

Answer: At the end of each serial batch, not at the very end of the entire play

With serial execution, handlers run at the end of each batch (serial group), ensuring rolling restarts happen properly before the next batch begins.

Can Ansible handlers use 'when' conditions to conditionally execute?

Answer: Yes, handlers support 'when' conditions just like regular tasks

Handlers support all standard task directives including 'when', allowing conditional execution even when notified.