LEARN. PRACTICE. GROW.Structure and expansion time
A fictional middleware team separates a playbook into files to reuse preparation, configuration and validation. A task file contains tasks; a playbook contains plays with host selection and other attributes. import_tasks and include_tasks do not automatically accept any valid YAML document. import_tasks expands the list statically during playbook parsing; include_tasks loads it when execution reaches the include. The choice affects variable availability, inspection and when errors are found. If a filename depends on a result registered by an earlier task, that result exists at runtime and should not be treated as an already-known static-expansion input. Splitting work into more files does not itself provide isolation or transactions.
A copied condition can change between tasks
In the lab, rollout_enabled starts as true. The reused file contains two tasks: the first sets rollout_enabled=false; the second writes a synthetic marker. With when: rollout_enabled on import_tasks, the condition applies to imported tasks and is evaluated separately. The first runs, changes the variable and causes the second to be skipped. With the same condition on include_tasks, the decision permits loading the file once; it is not automatically copied to each child, so the marker is written. Neither variant is universally better. Decide whether the intent is to admit the group using entry state or reevaluate a requirement before every action. If a task’s safety depends on a current condition, place that condition at the scope that must check it.
Repeat a list without losing identity
To configure two components with two ports each, the trial loops over include_tasks. The outer variable is component and the inner variable service_port. Four distinct files are produced: alpha-8080, alpha-9090, beta-8080 and beta-9090. Their names preserve the component-port association; using item indiscriminately at both levels can obscure or replace the value the task intended to use. import_tasks does not support the same direct loop, and the trial confirms rejection. Repeating an include also does not mean retrying until healthy: include_tasks does not support do-until. For a probe, place supported retry behavior on the state-observing task and define completion condition, limit and failure outcome.
What parsing can see
The lab compares --list-tasks for both forms. The import exposes the child write task; the include shows the inclusion without expanding the same child list. A short listing can therefore represent work still to be loaded rather than a small execution. The missing-file case reinforces the distinction: syntax-check passes a dynamic include referencing not-present.yml, and execution with a false condition skips it. When the condition becomes true, execution fails while opening the file. Importing the missing file fails during parsing even with when:false. A runtime condition does not repair a missing static artifact. Retain these check results, but do not describe syntax-check as evidence that every branch works.
Accept the reusable task library
Before promoting the task library to RUN, record file revision, Ansible version, required variables and executed branches. Ask for predictions before the trial: which task should run, which should skip and what state should remain? Then compare predictions, recap and artifacts. This lesson’s trial ran twice under core 2.16.14 on macOS with one local alias and synthetic temporary files. It does not configure RHEL, execute AAP, or test services or reboot persistence. AU294 publishes a core 2.16 training baseline, but that does not fix every EX294 booking variant. To transfer the exercise, repeat relevant branches in the authorized environment and versions, adding functional observation of the actual service.
# Local fixture only; see the complete task files in the lab.
- hosts: lab
gather_facts: false
vars:
rollout_enabled: true
tasks:
- ansible.builtin.import_tasks: change-gate.yml
when: rollout_enabled
# The first child sets rollout_enabled=false.
# Predict whether the second child runs, then compare include_tasks.
A preparation task changes the flag used by the import condition. The next activation is skipped; switching to include changes semantics and requires confirming intent.
Common pitfalls
Import as equivalent include; false conditions as protection against every parsing error; shared item in nested loops; syntax-check as a test of every branch.
Related topics: Variables and facts · Tags and partial execution
Choose deliberately when work expands and when its condition is reevaluated.
Reference: Reusing Ansible artifacts · EX294 current objectives inspected 2026-09-30; RHCE in Ansible framework effective 2026-05-11; booking product version not publicly pinned