🔀Module 03 — Playbook Control Flow

TASK [Only on Debian family] ***************************************
ok:       [web01] => {"msg": "web01 is Debian family"}
ok:       [web02] => {"msg": "web02 is Debian family"}
skipping: [db01]                                   <-- RedHat family

TASK [Only on hosts with 4GB or more] ******************************
ok:       [web01] => {"msg": "web01 has 7936 MB"}
skipping: [web02]                                  <-- only 2048 MB
ok:       [db01] => {"msg": "db01 has 16384 MB"}

TASK [Only on hosts in the web group] ******************************
ok:       [web01] => {"msg": "web01 is a web server"}
ok:       [web02] => {"msg": "web02 is a web server"}
skipping: [db01]

PLAY RECAP *********************************************************
web01 : ok=4  changed=0  skipped=0
web02 : ok=3  changed=0  skipped=1
db01  : ok=2  changed=0  skipped=2

Look at the recap — three different outcomes from one playbook. Each host evaluated each condition against its own facts and group membership. That is what "conditionals are per-host" means concretely, and it is why a single playbook can serve a heterogeneous fleet.

skipping: is not a failure. A skipped task is a successful decision not to act. Interviewers sometimes probe this: skipped counts in the recap separately from failed precisely because skipping is normal, expected behaviour.

TASK [WITHOUT parentheses - this runs, and it should not] **********
skipping: [localhost]

TASK [WITH parentheses - correctly skipped] ************************
skipping: [localhost]

Both skipped here — now change env to "staging" and run it again:

TASK [WITHOUT parentheses] ***   ok: [localhost] => {"msg": "DEPLOYING - no parentheses"}
TASK [WITH parentheses] ******   ok: [localhost] => {"msg": "DEPLOYING - with parentheses"}

Still the same. Now set force_deploy: false and env: "prod":

TASK [WITHOUT parentheses] ***   ok: [localhost]      <-- RUNS despite force_deploy being false
TASK [WITH parentheses] ******   skipping: [localhost]  <-- correctly blocked

There it is. Without parentheses the expression parses as env == "prod" OR (env == "staging" AND force_deploy). Because env is prod, the first branch is true and the whole expression short-circuits to true — force_deploy is never even consulted.

Why this is genuinely dangerous: the safety flag you added to prevent accidental production deploys does nothing, and it does nothing only in production, which is the one case you were guarding. The bug is invisible in dev and staging testing. Parenthesise whenever you mix and with or.

when: on a task, evaluated as a Jinja2 expression without {{ }} braces, per host. If it evaluates false the task is skipped for that host only, and skipped is reported separately from failed in the recap.

Conditions can be combined as a YAML list, which is an implicit AND and reads more clearly, or with explicit and / or / not.

when: is already evaluated as a Jinja2 expression, so the braces are redundant. ansible-lint flags it, and on more complex expressions the double evaluation can break — particularly with nested quoting or filters.

The exception people cite is embedding a variable inside a string comparison, and even there the correct form is when: myvar == "value", not braces.

when: "'web' in group_names" — group_names is a magic variable listing the groups the current host belongs to.

For the reverse direction, checking whether a named host is in a group, use when: "'web01' in groups['web']".

Note the outer quoting: the expression contains single quotes, so the whole thing is wrapped in double quotes to keep YAML happy.

The version test: when: app_version is version('2.0', '>=').

String comparison is wrong because "10.0" < "9.0" lexically, and float comparison is wrong because 1.10 becomes 1.1. The version test understands semantic ordering and also supports strict=True for strict semver.

and binds tighter than or, so a or b and c parses as a or (b and c).

The realistic failure: when: env == "prod" or env == "staging" and force_deploy — in production the first branch is true, the expression short-circuits, and the force_deploy safety flag is never evaluated. The guard silently does nothing, and only in the environment it was protecting.

Always parenthesise when mixing.

TASK [WITHOUT label - look at the output carefully] ****************
ok: [localhost] => (item={'name': 'app_rw', 'password': 'S3cr3t-App', 'privs': 'ALL'}) => {
    "msg": "Creating app_rw"
}
ok: [localhost] => (item={'name': 'app_ro', 'password': 'S3cr3t-RO', 'privs': 'SELECT'}) => {
    "msg": "Creating app_ro"
}

TASK [WITH label] **************************************************
ok: [localhost] => (item=app_rw) => {
    "msg": "Creating app_rw"
}
ok: [localhost] => (item=app_ro) => {
    "msg": "Creating app_ro"
}

The passwords are printed in plain text in the first task. Not in the msg — in the item echo that Ansible adds automatically. They are now in your terminal scrollback, in your CI job log, and in any log aggregation shipping that output.

loop_control: label: fixes it, and no_log: true on the task suppresses output entirely. For any loop over data containing secrets, you need at least one of them — and this is the concrete reason interviewers ask about no_log.

Readability is the secondary benefit and still a real one: a loop over 200 dictionaries is unusable output without a label.

loop is the modern syntax, recommended since 2.5. with_* is the older family, still functional and everywhere in existing code.

The behavioural difference that matters: with_items flattens one level of nesting, loop does not. Migrating a list-of-lists from with_items to loop changes what the task does unless you add | flatten(1).

The with_* forms that were not simple lists — with_dict, with_fileglob, with_nested — become loop plus a filter or a query().

Because the package modules accept a list natively. name: [nginx, git, htop] is one transaction and one round trip; looping is three of each, roughly three times slower, and Ansible warns about it.

The general rule: check whether the module already takes a list before reaching for loop. The same applies to user, file and several others in specific cases.

Not a single result — an object with a results list, one entry per iteration, each being a full result object. Each entry also carries .item, the original loop value that produced it.

So iterating the results reads as loop: "{{ svc.results }}" with item.item for the original value and item.rc for that iteration's exit code.

It configures loop behaviour: label controls what is printed per iteration, index_var exposes the counter, pause inserts a delay, and loop_var renames item — which is required for nested loops, since an inner loop would otherwise shadow the outer one.

label matters for two reasons: without it, a loop over dictionaries prints the entire dictionary, including any password in it, into your terminal and CI logs. And with hundreds of items the output is unreadable. For secrets, combine it with no_log: true.

until: with retries: and delay: — it re-runs the same task until the condition is true or the retries are exhausted, at which point the task fails.

Defaults are 3 retries and 5 seconds. It pairs with register because the condition normally tests the registered result.

Related modules worth naming: wait_for for a port or file condition, and wait_for_connection for waiting on a host to come back after a reboot.

TASK [This will fail] **********************************************
fatal: [localhost]: FAILED! => {"changed": true, "cmd": "/bin/false", "rc": 1}

TASK [Recovery ran] ************************************************
ok: [localhost] => {
    "msg": "Rescued. Failed task was: This will fail"
}

TASK [Cleanup always runs] *****************************************
ok: [localhost] => {"msg": "always block"}

TASK [The play continues normally] *********************************
ok: [localhost] => {"msg": "still running after the failure"}

PLAY RECAP *********************************************************
localhost : ok=3  changed=1  unreachable=0  failed=0   rescued=1  ignored=0

Read the recap: failed=0 and rescued=1. Despite a red fatal: line in the output, the play succeeded and would exit zero in CI.

Note also that "Never reached" did not run. A block aborts at the first failure — the remaining block tasks are skipped entirely, which is what makes rollback logic safe to write.

The trap: if your rescue only logs, you have converted a real failure into a green build. Anyone reading the exit code sees success. If the rescue does not genuinely restore a good state, end it with:

- name: Re-raise after logging
  ansible.builtin.fail:
    msg: "Deployment failed and could not be recovered"

Ansible's try/catch/finally. block groups tasks; if any fails, the block aborts immediately and rescue runs; always runs regardless of outcome.

The critical detail: if rescue completes successfully the host is no longer marked failed — the recap shows rescued=1, failed=0 and the play continues.

That is correct for a genuine recovery and dangerous if the rescue only logs, because you have turned a real failure into a green CI build. If the rescue does not restore a good state, end it with fail.

ansible_failed_task and ansible_failed_result are available inside rescue for reporting.

Both let the play continue. ignore_errors still reports the task as failed with a red fatal: ...ignoring line, which trains people to overlook red text in CI. failed_when: false declares the task cannot fail and reports ok.

Prefer a real failed_when: condition — failed_when: result.rc not in [0, 2] — because it encodes which outcomes are actually acceptable rather than blanket-suppressing everything.

And neither handles an unreachable host; that needs ignore_unreachable: true.

By default the failed host is removed from the play and every other host continues. The failure is reported in the recap and the run exits non-zero.

Change it with any_errors_fatal: true to abort everywhere on the first failure, or max_fail_percentage: N to abort once a threshold of the current batch has failed — which only has meaning together with serial.

block containing drain, deploy and health check; rescue performing the rollback and alerting; always returning the node to the load balancer whatever happened.

Combine with serial so only a batch is affected, and max_fail_percentage: 0 so the rollout halts rather than continuing through the fleet.

And a caveat worth volunteering: if the rescue cannot genuinely restore a good state, it must end with fail, otherwise the pipeline reports success on a broken deployment.

assert for input validation at the start of a playbook — it states positively what must be true and reports which specific condition failed.

fail for a deliberate stop based on a more complex or procedural condition, where you want to control the message precisely.

The practical argument: failing in two seconds with a clear message beats failing four minutes in with a half-written config on disk.

TASK [This works - resolved at run time] ***************************
included: /home/zaeem/lab/os-Debian.yml for localhost

TASK [debug] *******************************************************
ok: [localhost] => {"msg": "Debian tasks ran"}

ERROR! Unable to retrieve file contents
Could not find or access 'os-{{ ansible_facts[\'os_family\'] }}.yml'

The error is the lesson. import_tasks is processed before any host is contacted, so ansible_facts does not exist yet — the filename is still the literal, untemplated string. The include succeeded because by the time it was reached, facts had been gathered.

Now run ansible-playbook importvsinclude.yml --list-tasks with only the include, and note that the inner debug task does not appear. The tooling cannot see inside a dynamic include, which is exactly the trade-off: runtime flexibility costs you static visibility.

The rule that follows: if a filename or a loop depends on runtime data, you have no choice — use include_*. Otherwise prefer import_* and keep your playbook introspectable.

import_tasks is static, processed at parse time — the contents are inserted inline as though you had typed them. include_tasks is dynamic, processed at run time when the task is reached.

The consequences: only include can take a variable filename or be looped, because those depend on runtime data. Only import is visible to --list-tasks, usable with --start-at-task, and fully analysable by ansible-lint.

Tags and when: also behave differently: on an import they are applied to every inner task; on an include they apply to the include as a single unit.

Prefer import_* by default — static structure keeps the playbook introspectable by tooling and by humans.

Break it when you need runtime behaviour: a filename built from a fact, a loop over includes, or a conditional that must be evaluated against gathered data.

The performance caveat worth adding: importing a very large role tree expands everything at parse time, which slows startup and uses memory. Dynamic includes stay cheap until reached, so at scale it becomes a genuine trade-off rather than a style preference.

always — runs regardless of --tags, unless explicitly skipped. never — runs only when requested by name, for destructive or very slow tasks. tagged and untagged — select tasks that do or do not carry any tag. all — the default.

The practical point: anything that sets up state other tasks depend on, such as include_vars, must be tagged always, otherwise --tags config skips it and you get confusing undefined-variable errors that look like a variable bug.

Always that order, regardless of how they are arranged in the file — and handlers are flushed between each section.

That is why pre_tasks is the natural home for draining a node from a load balancer or applying config that must take effect before the roles run, and post_tasks for verification and re-enabling.

PLAY [Zero-downtime rolling deployment] ****************************

TASK [Drain from the load balancer] ***   ok: [web01]        <-- batch 1: ONE host
TASK [Wait for connections to finish] *   ok: [web01]
TASK [Deploy the new version] *********   changed: [web01]
RUNNING HANDLER [Restart app] *********   changed: [web01]
TASK [Verify health] ******************   ok: [web01]
TASK [Return to the load balancer] ****   ok: [web01]

PLAY [Zero-downtime rolling deployment] ****************************

TASK [Drain from the load balancer] ***   ok: [web02]        <-- batch 2: TWO hosts
                                          ok: [web03]
...

PLAY RECAP *********************************************************
web01 : ok=6  changed=2  failed=0
web02 : ok=6  changed=2  failed=0
web03 : ok=6  changed=2  failed=0

Notice the play header repeats. Each serial batch is a fresh pass through the entire play — that is the mechanism, made visible.

Seven deliberate decisions, each worth being able to justify:

1. serial: [1, 2] — canary first. A bad release breaks one host, not the fleet.
2. max_fail_percentage: 0 — the rollout halts rather than continuing.
3. delegate_to: localhost on the LB calls — the load balancer API is reached from the control node, but inventory_hostname still names the host being drained.
4. meta: flush_handlers before the health check — without it the restart happens at the end of the play and you would verify the old version. Module 01 Part D3.
5. until / retries on the health check — services take time to come up; a single immediate check would fail spuriously.
6. always for re-enabling — a node must never be left drained, no matter what failed.
7. fail at the end of rescue — without it, a successful rescue clears the failure, max_fail_percentage never triggers, and the rollout continues happily through a broken deployment.

Point 7 is the one that separates candidates. It is the interaction between two features — rescue clearing failure state, and max_fail_percentage depending on failure state — and you only find it by having been burned.

It runs a task on a different host while keeping the current host's variables in scope — so inventory_hostname still refers to the host being processed.

Typical uses: calling a load balancer API from localhost to drain the current node; adding a DNS record on a management host; running a database migration on a single DB node.

delegate_facts: true assigns gathered facts to the delegated host instead of the current one. local_action is the older shorthand for delegate_to: localhost.

serial: [1, 10, "25%"] for a canary then progressive batches, with max_fail_percentage: 0 so the rollout halts on the first failure.

Per batch: drain from the load balancer with delegate_to: localhost, pause for connection draining, deploy inside a block, meta: flush_handlers to apply the restart, health check with until/retries, and always to re-enable.

rescue performs the rollback and must end with fail, otherwise the recovered state clears the failure, max_fail_percentage never fires, and the rollout continues through a broken release.

Before any of it: --check --diff --limit one-host.

It executes a task on the first host of the batch only, while applying the result to the whole play — used for singular operations such as a schema migration, creating a shared resource, or sending one deployment notification.

Commonly paired with delegate_to to control which host it runs on, since "the first host of the batch" is otherwise arbitrary.

Caveat: with serial, run_once fires once per batch, not once per play — which surprises people writing migrations.

Only the hosts in the current batch, not the whole group. For the complete list use ansible_play_hosts_all.

It matters when building a config that must list every peer — an nginx upstream block or a cluster member list — because with serial you would otherwise generate a config naming only the two hosts in the current batch.

---
- name: Rolling patch with rollback
  hosts: web
  serial: 1                          # requirement 1
  max_fail_percentage: 0             # requirement 1
  become: true

  pre_tasks:
    - name: Requirement 2 - refuse to run without approval
      ansible.builtin.assert:
        that:
          - approved | default(false) | bool
        fail_msg: "Refusing to patch. Re-run with -e approved=true"
      tags: always                   # must run even with --tags patch

    - name: Requirement 3 - load vars, always
      ansible.builtin.include_vars: vars/patching.yml
      tags: always

  tasks:
    - name: Requirement 5 - drain from the load balancer
      ansible.builtin.uri:
        url: "http://lb.internal/disable/{{ inventory_hostname }}"
        method: POST
        status_code: [200, 204]
      delegate_to: localhost
      changed_when: false
      tags: patch

    - name: Patch with rollback
      block:
        - name: Requirement 4 - ONE transaction, not a loop
          ansible.builtin.package:
            name: "{{ patch_packages }}"      # a LIST variable
            state: latest

        - name: Requirement 6 - is a reboot needed?
          ansible.builtin.stat:
            path: /var/run/reboot-required
          register: reboot_flag

        - name: Requirement 6 - reboot only if required
          ansible.builtin.reboot:
            reboot_timeout: 600
          when: reboot_flag.stat.exists

        - name: Requirement 7 - health check
          ansible.builtin.uri:
            url: "http://{{ inventory_hostname }}:8080/health"
            status_code: 200
          register: health
          until: health.status == 200
          retries: 12
          delay: 5
          changed_when: false

      rescue:
        - name: Roll back the packages
          ansible.builtin.command: /opt/scripts/rollback-packages.sh

        - name: Requirement 7 - re-raise so the rollout HALTS
          ansible.builtin.fail:
            msg: "Patching failed on {{ inventory_hostname }}; rolled back and stopping"

      always:
        - name: Requirement 5 - always re-enable
          ansible.builtin.uri:
            url: "http://lb.internal/enable/{{ inventory_hostname }}"
            method: POST
            status_code: [200, 204]
          delegate_to: localhost
          changed_when: false
      tags: patch

  post_tasks:
    - name: Requirement 8 - slow suite, opt-in only
      ansible.builtin.command: /opt/tests/full-suite.sh
      changed_when: false
      tags: [never, fulltest]

The six things most people miss:

1. tags: always on the assert and include_vars. Run with --tags patch and without them, the approval gate is skipped entirely and patch_packages is undefined.
2. name: "{{ patch_packages }}" with a list variable — one transaction. A loop here would be three or ten round trips and Ansible would warn about it.
3. fail at the end of rescue. Without it the rescue clears the failure, max_fail_percentage: 0 never fires, and the patch rolls on to every remaining host.
4. always: on the block re-enables the node even when the rescue itself failed. A host left drained is an outage you created while trying to be careful.
5. stat before reboot — requirement 6 said "only if required". Rebooting unconditionally is both slower and a needless availability risk.
6. tags: [never, fulltest] — never is what makes it opt-in. A plain fulltest tag would still run in a normal untagged execution.

Verify:

ansible-playbook patch.yml                                  # should FAIL on the assert
ansible-playbook patch.yml -e approved=true --check --diff --limit web01
ansible-playbook patch.yml -e approved=true --list-tasks
ansible-playbook patch.yml -e approved=true --tags patch
ansible-playbook patch.yml -e approved=true --tags fulltest

when: is already evaluated as a Jinja2 expression, so the braces are redundant, ansible-lint flags them, and on complex expressions the double evaluation can break — particularly with nested quoting or filters.

and binds tighter than or, so a or b and c parses as a or (b and c).

The realistic failure: when: env == "prod" or env == "staging" and force_deploy — in production the first branch is true, the expression short-circuits, and the safety flag is never evaluated. The guard silently does nothing, only in the environment it was protecting.

The package modules take a list natively — one transaction, one round trip. Looping runs the package manager once per item, which is several times slower, and Ansible warns about it.

The general rule: check whether the module already accepts a list before reaching for loop.

Without it, a loop over a list of dictionaries prints the entire dictionary on every iteration — including any password or token — into your terminal, CI logs and log aggregation.

It also makes a 200-item loop readable. For genuine secrets, combine with no_log: true.

A results list, one full result object per iteration. Each entry carries .item, the original loop value that produced it — hence the item.item idiom when iterating over results.

It is no longer marked failed — the recap shows rescued=1, failed=0 and the play continues.

Correct for a genuine recovery, dangerous if the rescue only logs, because a real failure becomes a green build. If the rescue does not restore good state, end it with fail.

Both continue the play. ignore_errors still reports a red fatal: ...ignoring, training people to overlook red text in CI. failed_when: false reports ok.

Prefer a real condition — failed_when: rc not in [0, 2] — which encodes which outcomes are acceptable. Neither covers an unreachable host; that needs ignore_unreachable.

Import only: visible to --list-tasks; usable with --start-at-task; tags and when: are applied to every inner task individually.

Include only: a variable in the filename; being looped; a when: evaluated once against runtime state.

Import is parse time, include is run time — every difference follows from that.

Because running with --tags config skips every untagged task, including the variable load — so the config template then fails on undefined variables, and the error looks like a variable bug rather than a tagging bug.

Anything that sets up state other tasks depend on needs tags: always.

It changes where the task executes. It deliberately does not change the host context — inventory_hostname and all the current host's variables still refer to the original host.

That is what makes "tell the load balancer to drain this node" a single line.

serial: [1, 5, "25%"] for a canary then progressive batches. max_fail_percentage: 0 to halt on failure. block/rescue/always for rollback and guaranteed re-enable. And a fail at the end of the rescue so the failure state survives for max_fail_percentage to act on.

Preceded by --check --diff --limit one-host.

Only the current batch. For every host in the play use ansible_play_hosts_all.

It matters when templating a config that must list all peers — an nginx upstream block or a cluster member list — because otherwise you generate a config naming only the current batch.

Behaviour verified against the current official Ansible documentation.

Question selection cross-referenced against publicly published 2026 Ansible interview question sets:

• Spacelift — 50+ Top Ansible Interview Questions & Answers for 2026
• GeeksforGeeks — Top 50+ Ansible Interview Questions and Answers
• Vinsys — Top 30 Ansible Interview Questions and Answers 2026
• K21 Academy — Ansible Interview Questions & Answers 2026
• Hirist — Top 25+ Ansible Interview Questions and Answers 2026

Answers were rewritten and deepened rather than reproduced — published versions are usually correct but shallow, and the added operational detail is what differentiates a candidate in the room.