🧵Module 04 — Jinja2 Templating

ok: [web01] => {
    "out.stdout_lines": [
        "rendered_on_control_node = zaeem-laptop",
        "rendered_for_target      = web01",
        "target_reported_hostname = web01",
        "control_node_user        = zaeem"
    ]
}

Line 1 is the proof. lookup('pipe', 'hostname') ran hostname and got your laptop, not web01 — because lookups and template rendering both happen on the control node.

Line 3 shows the target's hostname, but only because it arrived as a gathered fact — collected earlier by the setup module and then substituted locally during rendering. The template itself never executed anything on web01.

Why this matters practically: if you need a value that only exists on the target and is not a fact, you cannot get it with a lookup. You must run a task with register first, then reference the registered value in the template. Reaching for lookup('file', '/etc/something') and getting the control node's copy is a genuinely common bug.

{{ }} is an expression — it evaluates and prints the result into the output.

{% %} is a statement — control flow such as for, if, set, macro. It prints nothing itself.

{# #} is a comment — stripped entirely, never present in the rendered file. Useful for notes you do not want shipped to production.

The control node, always. Jinja2 renders the file locally using that host's variables and facts, then the finished plain text is transferred to the target.

That is why the managed node needs no templating library, and why lookup() inside a template reads control-node files rather than target files. To use a value that exists only on the target, run a task and register it first.

template when you own the entire file and its content varies by host. copy when you own it and it is identical everywhere — cheaper and clearer.

lineinfile or blockinfile when the file is owned by the OS or a package and you only need to manage a line or a section within it.

The warning worth adding: fifteen lineinfile tasks against one file should have been a template. Each is an independent regex that can drift, and the result is far harder to review than a single declared file.

Almost everything. Task names, module arguments, when: conditions, loop: sources, variable definitions that reference other variables — all rendered through Jinja2 before use.

The notable exception is a file transferred with copy, which is sent byte-for-byte. That is deliberate, and it is how you deploy a file that legitimately contains Jinja2 syntax of its own — a Grafana dashboard or a Prometheus rule, for example.

TASK [Active non-root users, sorted, comma-separated] **************
ok: [localhost] => {
    "msg": "deploy, monitor"
}

TASK [What happens WITHOUT the final list] *************************
ok: [localhost] => {
    "msg": "<generator object do_map at 0x7f2a1c4d5e40>"
}

TASK [With the final list] *****************************************
ok: [localhost] => {
    "msg": ["root", "deploy", "monitor", "olduser"]
}

The middle task is the lesson. map returned a lazy generator, and rendering it produced a Python repr string. No error, no warning — and if that had gone into a config file you would have deployed <generator object do_map at 0x7f2a1c4d5e40> to production.

The rule: map, select, reject, selectattr and rejectattr all need a trailing | list unless another filter that consumes them follows (join, sort, length all force evaluation, which is why the first task worked without one).

Also note the >- folded scalar used to split the chain across lines. A six-filter chain on one line is unreadable; this keeps it reviewable in a diff without changing the value.

{{ users | map(attribute='name') | list }}.

To filter first, selectattr and rejectattr: {{ users | selectattr('active') | map(attribute='name') | list }}.

The detail worth volunteering: map and select return generators, so a trailing | list is needed unless a consuming filter such as join or sort follows. Without it you render a <generator object ...> string into your file with no error.

Without a fixed salt it generates a new random salt on every run, producing a different hash each time. The user module then sees a different value, reports changed, and resets the password on every single run — which also fires any handler attached to it.

The fix is a deterministic salt, typically derived from something stable like inventory_hostname via random(seed=...). Better still, store an already-hashed value in Vault.

| quote — it shell-escapes the value, so a string containing ; or backticks cannot break out and run a second command.

The stronger answer is to not use shell at all where a real module exists. When you must, | quote on every user-controlled value is mandatory, and command is preferable to shell because it does not involve a shell at all.

An inline conditional inside an expression: {{ (vcpus > 4) | ternary('auto', 2) }}. It keeps a template readable when a full {% if %} block would be heavy for a single value.

It takes an optional third argument for the undefined case.

{{ base | combine(overrides, recursive=True) }}.

recursive=True matters whenever there are nested dictionaries — without it the nested level is replaced wholesale rather than merged, which silently drops keys. Covered in Module 02 Part D2.

Default — trim_blocks: true, lstrip_blocks: false:

upstream backend {
        server web01:8080;
        server web02:8080;
        server web03:8080;
}

Look closely: eight spaces of indent instead of four. The four spaces you used to indent {% for %} were emitted into the output and added to the four in front of server.

With lstrip_blocks: true:

upstream backend {
    server web01:8080;
    server web02:8080;
    server web03:8080;
}

And if trim_blocks were false — as it is in plain Jinja2 — you would additionally get a blank line after every {% endfor %} and {% if %}, producing a config file with gaps scattered through it.

Why this is worth caring about: a generated config with erratic indentation and stray blank lines is harder for humans to review during an incident, and in whitespace-sensitive formats — YAML, Python, Makefiles — it is not cosmetic at all, it is broken output. Set lstrip_blocks: true on templates where you indent your tags.

It removes the first newline after a block tag, so {% for %} and {% endfor %} on their own lines do not each leave a blank line behind.

Ansible sets it to true by default, which differs from plain Jinja2 where it is false. lstrip_blocks defaults to false in both, and is the one you usually want to enable so you can indent your tags to match the file structure without those indents appearing in the output.

Jinja2 scoping — a variable {% set %} inside a loop body is discarded at the end of each iteration, so the total resets. It produces a wrong answer silently rather than an error.

Fix with a namespace() object whose attributes persist across iterations. In Ansible the better fix is usually to avoid the loop entirely: {{ items | map(attribute='size') | sum }}.

{% if not loop.last %}, {% endif %} inside the loop, using the loop.last boolean.

The loop object also gives you index, index0, first, length and revindex.

Often cleaner in Ansible, though: skip the loop and use {{ mylist | join(', ') }}.

{% include %} renders another template inline and inherits the current context, so it sees your variables.

{% import %} brings in macros and does not get the current context unless you add with context. A macro referencing ansible_facts under a plain import fails with an undefined-variable error.

The cleaner design is to pass what a macro needs as explicit arguments rather than relying on ambient context — it is easier to test and easier to read.

TASK [This fails - undefined variable] *****************************
fatal: [localhost]: FAILED! => {
    "msg": "AnsibleUndefinedVariable: 'maybe_missing' is undefined"
}
...ignoring

TASK [Check the type of a templated number] ************************
ok: [localhost] => {
    "msg": "str"
}

Two lessons in four lines of template.

The undefined variable killed the entire file, not just that line — /tmp/gotchas.txt was never created. Add | default('unset') and it renders. This is why every optional value in a real template needs a default.

5 + 5 produced the string "10". Jinja2 arithmetic worked, then the result was stringified on the way out. So when: computed_value > 5 compares a string to an integer and behaves unpredictably — the same family of bug as the "false" string in Module 02 Part D5. Cast with | int, or enable jinja2_native.

Now fix the template and re-run to see {% raw %} working:

optional_value = unset
math_result    = 10
literal_braces = {{ this_stays_literal }}

{% raw %} passed the braces through untouched — which is how you template a file for a system that has its own {{ }} syntax.

Runs a validation command against the temporary file before it is moved into place, substituting %s with the temp path. If validation fails, the task fails and the live file is never touched.

Use it wherever a broken config is costly: nginx -t -c %s, visudo -cf %s, sshd -t -f %s. A malformed sudoers file locks everyone out of sudo, including you.

Three options. Wrap the literal sections in {% raw %} ... {% endraw %}. Change the delimiters on the task with variable_start_string and block_start_string. Or — if nothing in the file actually needs substituting — use copy instead, which transfers bytes verbatim and never templates.

The same problem arises with Grafana dashboards, Prometheus rules and most front-end frameworks.

Something in the rendered content differs each time. The usual culprits: a timestamp — including a customised ansible_managed containing one; password_hash without a fixed salt; unsorted iteration over a dictionary or a set, where ordering is not stable; or a random filter without a seed.

The fix is to make the render deterministic — | dictsort or | sort on anything iterated, a fixed salt, and a static ansible_managed. Diagnose it with --diff, which shows exactly which line moved.

By default every Jinja2 expression renders to a string, so {{ 5 + 5 }} yields "10" and a list becomes its string representation. jinja2_native = True in ansible.cfg preserves real Python types — integers, lists, dictionaries, booleans.

It is genuinely useful when passing structured data between tasks, but it changes behaviour subtly across the entire project, so it is a deliberate project-wide decision rather than a quick fix. Existing playbooks relying on string coercion can break.

ansible-playbook --check --diff --limit web01 renders against the real host with its real facts and shows the exact diff, changing nothing — this is the everyday answer.

For quick syntax iteration, lookup('template', 'file.j2') in a debug task, with the caveat that it renders using localhost's facts.

For anything serious, Molecule renders against real containers and asserts on the output.

templates/nginx.conf.j2:

# {{ ansible_managed }}
# DO NOT EDIT - generated by Ansible

{# Requirement 4: twice the CPUs, capped at 16 #}
{% set workers = [(ansible_facts['processor_vcpus'] | int) * 2, 16] | min %}
worker_processes {{ workers }};

http {
    upstream app_backend {
{% for host in groups['web'] | sort %}
{%     if hostvars[host]['ansible_facts']['default_ipv4'] is defined %}
        server {{ hostvars[host]['ansible_facts']['default_ipv4']['address'] }}:8080 max_fails=3;
{%     else %}
        # {{ host }}: facts unavailable - gather facts for the web group first
{%     endif %}
{% endfor %}
    }

    server {
{% if enable_tls | default(false) | bool %}
        listen 443 ssl;
        ssl_certificate     {{ tls_cert | default('/etc/ssl/certs/app.pem') }};
        ssl_certificate_key {{ tls_key  | default('/etc/ssl/private/app.key') }};
{% else %}
        listen 80;
{% endif %}
        server_name {{ server_name | default('_') }};

        location / {
            proxy_pass http://app_backend;
        }
    }
}

The task:

- name: Deploy nginx configuration
  ansible.builtin.template:
    src: nginx.conf.j2
    dest: /etc/nginx/nginx.conf
    owner: root
    group: root
    mode: "0644"
    lstrip_blocks: true          # requirement 6
    validate: nginx -t -c %s     # requirement 7
    backup: true
  become: true
  notify: Reload nginx

The seven decisions, each mapped to a requirement:

1. {{ ansible_managed }}, kept static — no timestamp, or requirement 7 fails on the second run.
2. groups['web'] | sort — without it, group ordering can vary and the file differs between runs, breaking requirement 7 in a way that looks inexplicable.
3. is defined guard — requirement 3. hostvars[host]['ansible_facts']['default_ipv4'] is undefined for any host whose facts were not gathered, and one undefined variable aborts the whole template.
4. [x, 16] | min — the idiomatic way to express a cap. [value, ceiling] | min reads better than a nested ternary.
5. enable_tls | default(false) | bool — default for requirement 5, and | bool because -e enable_tls=false arrives as the string "false", which is truthy. Module 02 Part D5.
6. lstrip_blocks: true with tags indented to match the structure — requirement 6. Without it, every {% if %} indent lands in the output.
7. validate: — requirement 7's other half. A broken nginx config that reaches disk and triggers a reload takes the site down.

Verify:

ansible-playbook site.yml --check --diff --limit web01
ansible-playbook site.yml --limit web01
ansible-playbook site.yml --limit web01           # changed=0
ansible-playbook site.yml -e enable_tls=false --check --diff --limit web01

On the control node. The target receives finished plain text and needs no templating library.

It follows that lookup() inside a template reads control-node files, and that a value existing only on the target must be captured with register first before a template can use it.

Expression (prints a value), statement (control flow, prints nothing), comment (stripped entirely from the output).

map is lazy and returns a generator. Add a trailing | list, or a consuming filter such as join, sort or length, which forces evaluation.

It fails silently — no error, just a Python repr string in your config file.

A timestamp in the content — including a customised ansible_managed. password_hash without a fixed salt. Unsorted iteration over a dictionary or a set, where ordering is not stable between runs. Also random without a seed.

Fix by making the render deterministic: | dictsort, | sort, a fixed salt, a static ansible_managed. Diagnose with --diff.

It removes the first newline after a block tag. Ansible defaults it to true, unlike plain Jinja2 where it is false.

lstrip_blocks defaults to false and is the one you usually want to enable, so you can indent your tags to match the file structure without those indents appearing in the output.

{% raw %} ... {% endraw %} around the literal sections, or change the delimiters on the task with variable_start_string and block_start_string, or use copy if nothing actually needs substituting.

The common cases: Helm charts, Grafana dashboards, Prometheus rules, Vue templates.

Jinja2 scoping discards a {% set %} at the end of each iteration. Use a namespace() object, or — better in Ansible — replace the loop with a filter: {{ items | map(attribute='size') | sum }}.

Runs a checker against the temporary file before it is moved into place, with %s substituted for the temp path. The task fails and the live file is untouched if validation fails.

sshd -t -f %s, visudo -cf %s, nginx -t -c %s — the three files most capable of locking you out or taking the site down.

A setting that makes Jinja2 expressions return real Python types instead of strings — so {{ 5 + 5 }} gives the integer 10 rather than "10".

Useful when passing structured data between tasks, but it changes behaviour project-wide and can break playbooks that relied on string coercion. A deliberate decision, not a quick fix.

Own the file and it varies per host → template. Own it and it is static → copy. Need one line in a package-owned file → lineinfile. Need a managed section in a file you do not own → blockinfile.

The anti-pattern: many lineinfile tasks against a single file. Each is an independent regex that can drift, and it should have been a template.

Behaviour verified against the current official Ansible templating documentation and the Jinja2 template designer 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.