Ansible Automation Ansible Handlers and Notifications 3

Question 1

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

Accepted Answer

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

Answer

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

Question 2

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

Accepted Answer

changed

Answer

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.

Question 3

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

Accepted Answer

handlers:
  - name: Restart Apache
    service:
      name: httpd
      state: restarted

Answer

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

Question 4

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

Accepted Answer

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

Answer

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

Question 5

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

Accepted Answer

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

Answer

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

Ansible Automation Practice Test

Ansible Automation Practice Test

Ansible Automation Ansible Handlers and Notifications 3