🧮Module 02 — Variables, Facts & Precedence

ERROR! We were unable to read either as JSON nor YAML, these are the errors we got from each:
JSON: Expecting value: line 1 column 1 (char 0)

Syntax Error while loading YAML.
  found unacceptable key (unhashable type: AnsibleMapping)

The offending line appears to be:

      ansible.builtin.debug:
        msg: {{ http_port }}
                          ^ here

We could be wrong, but this one looks like it might be an issue with
missing quotes. Always quote template expression brackets when they
start a value. For instance:

    with_items:
      - {{ foo }}

Should be written as:

    with_items:
      - "{{ foo }}"

Ansible tells you the fix directly — this is one of the few error messages that names the exact problem. Worth triggering once so you recognise "found unacceptable key (unhashable type: AnsibleMapping)" instantly. It means: YAML saw { at the start of a value and tried to parse a dictionary.

Jinja2, with {{ variable_name }}. Ansible templates strings at run time, so variables can be used in task arguments, in when: conditions, in templates, and in file paths.

The two syntax rules worth stating: quote the value if it starts with {{, and do not use braces inside when:, which is already evaluated as a Jinja2 expression.

Letters, digits and underscores only; cannot begin with a digit; cannot be a Python keyword.

The practical trap is hyphens — app-port is invalid because Jinja2 parses it as subtraction, and it can fail silently rather than loudly. Also avoid names that collide with playbook keywords like environment or name.

TASK [Dot notation on a key called 'keys'] *************************
ok: [localhost] => {
    "msg": "<built-in method keys of dict object at 0x7f3a2c1d4a40>"
}

TASK [Bracket notation on the same key] ****************************
ok: [localhost] => {
    "msg": ["alpha", "beta"]
}

No error. No warning. config.keys returned Python's built-in dict.keys method object, because dot notation resolves attributes before dictionary keys, and every Python dict has a .keys attribute.

Now imagine that value being written into a config file by a template task. You would deploy the literal string <built-in method keys of dict object at 0x7f3a2c1d4a40> into production and spend a long time working out where it came from.

The reserved names to watch: keys, items, values, count, index, update, pop, get, copy, clear. Use bracket notation for any data you did not personally write.

They behave identically for simple keys, but bracket notation is safer in two situations.

First, keys containing special characters or spaces — myvar['some-key'] works where myvar.some-key does not.

Second, and more dangerous, keys that collide with Python dict methods: keys, items, count, update, pop. Dot notation returns the method object rather than your value, silently, with no error.

So: dot notation for variables I wrote myself, bracket notation for anything from an external source such as an API response or cloud tags.

A YAML parsing bug where the unquoted country code NO is interpreted as the boolean false. The same applies to ON, OFF, Y, N, YES.

The fix is to quote any string that could be mistaken for a boolean or a number. The related cases are version strings like 1.10, which becomes the float 1.1, and file modes like 0644.

1043

web01 | SUCCESS => {
    "ansible_facts": {
        "ansible_distribution": "Ubuntu",
        "ansible_distribution_file_parsed": true,
        "ansible_distribution_file_path": "/etc/os-release",
        "ansible_distribution_file_variety": "Debian",
        "ansible_distribution_major_version": "22",
        "ansible_distribution_release": "jammy",
        "ansible_distribution_version": "22.04"
    },
    "changed": false
}

"ansible_memfree_mb": 5122,
"ansible_memory_mb": {
    "nocache": {"free": 6903, "used": 1033},
    "real": {"free": 5122, "total": 7936, "used": 2814},
    "swap": {"cached": 0, "free": 0, "total": 0, "used": 0}
},
"ansible_memtotal_mb": 7936

"ansible_default_ipv4": {
    "address": "10.0.1.15",
    "alias": "eth0",
    "gateway": "10.0.1.1",
    "interface": "eth0",
    "macaddress": "06:1a:2b:3c:4d:5e",
    "netmask": "255.255.255.0",
    "network": "10.0.1.0"
}

Over a thousand lines per host. That is the cost of fact gathering, and it is why gather_facts: false is a real optimisation in plays that never use a fact.

Note ansible_default_ipv4 is a dictionary, which is why you write ansible_default_ipv4.address and not just ansible_default_ipv4. Same for ansible_memory_mb — nested dicts all the way down. filter= is how you explore without drowning.

facts-on.yml   real  0m6.412s
facts-off.yml  real  0m1.883s

Roughly 4.5 seconds of pure overhead on a handful of hosts, for a play that used no facts at all. Fact gathering is a full extra module execution per host — the entire ten-step lifecycle from Module 01 Part B6, just to collect data you are not going to read.

Three ways to control it, in increasing sophistication:

gather_facts: false                     # the play uses no ansible_* variable
gather_subset: "!all,!min,network"      # gather only what you need

# ansible.cfg — gather once, reuse across runs
[defaults]
fact_caching = jsonfile
fact_caching_connection = /tmp/ansible_facts
fact_caching_timeout = 7200

The interview framing: on a 500-host fleet this is not 4 seconds, it is minutes on every single run, including runs triggered by CI on every merge. Being able to name gather_subset and fact caching as the fixes — not just gather_facts: false — is what marks the difference between having read about it and having tuned it.

Variables automatically discovered about each managed host by the setup module, which runs at the start of any play with gather_facts: true (the default). They cover OS, distribution, network interfaces, CPU, memory, mounts, service manager and more.

They are accessed either as ansible_facts['distribution'] (modern, namespaced, preferred) or the injected flat form ansible_distribution.

It is a full extra module execution per host — over a thousand data points, one complete SSH round trip. On a large fleet that is minutes per run.

Three fixes, escalating: gather_facts: false for plays that reference no ansible_* variable; gather_subset to collect only the categories you need, for example "!all,!min,network"; and fact caching via jsonfile or redis, so facts are gathered once and reused across runs within the cache timeout.

ansible_os_family. It groups related distributions: Debian covers Debian and Ubuntu, RedHat covers RHEL, CentOS, Rocky and Alma.

Using ansible_distribution means enumerating every distro name individually, and the playbook breaks the first time someone deploys on a variant you did not list.

Better still, avoid the conditional entirely where a portable module such as package already handles the difference.

The ansible.cfg setting that controls whether facts are also exposed as top-level ansible_* variables. Default true.

Setting it to false means only ansible_facts['...'] works — which avoids any chance of your own variables colliding with fact names, but breaks every playbook written in the flat style.

The practical takeaway: write ansible_facts['distribution'] in new code so you are not dependent on the injection.

TASK [Ensure the facts.d directory exists] *************   changed: [web01]
TASK [Deploy a static custom fact] *********************   changed: [web01]
TASK [Re-gather facts so the new one is visible NOW] ***   ok: [web01]

TASK [Read it back] ************************************
ok: [web01] => {
    "msg": "Tier is production, version 2.4.1"
}

The third task is the one that matters, and it is the one people omit. Facts were gathered at the start of the play, before the .fact file existed. Without explicitly re-running setup, ansible_local.deployment would be undefined and the play would fail — even though the file is sitting right there on disk.

This is the same class of ordering problem as meta: flush_handlers in Module 01 Part D3: Ansible captured state at a point in time, and you changed that state afterwards. Recognising that pattern is worth more than memorising either individual fix.

Confirm on the target:

ssh web01 'cat /etc/ansible/facts.d/deployment.fact'
ansible web01 -m ansible.builtin.setup -a 'filter=ansible_local'

Facts the host itself advertises, defined in /etc/ansible/facts.d/ on the managed node and exposed under ansible_local.

Two forms: a static .fact file in INI or JSON, or any executable that prints JSON to stdout, which lets a fact be computed at gather time.

Accessed as ansible_local.<filename>.<section>.<key>.

The use case worth naming: letting a host declare things Ansible cannot infer — its tier, its owning team, its patch window, its compliance class — so playbooks stop hard-coding hostnames.

Facts were gathered at the start of the play, before the file existed. The fact cache for that host is a snapshot.

Fix by re-running the setup module explicitly mid-play — ideally with filter: ansible_local so you re-gather only what changed.

It is the same category of problem as a handler running after the task that verifies it: state captured at one point, changed at another.

TASK [Show the ENTIRE object] **************************************
ok: [web01] => {
    "result": {
        "changed": false,
        "cmd": "echo \"line one\"\necho \"line two\"\n",
        "delta": "0:00:00.004521",
        "end": "2026-08-14 12:31:07.882314",
        "failed": false,
        "rc": 0,
        "start": "2026-08-14 12:31:07.877793",
        "stderr": "",
        "stderr_lines": [],
        "stdout": "line one\nline two",
        "stdout_lines": [
            "line one",
            "line two"
        ]
    }
}

TASK [Show just the useful parts] **********************************
ok: [web01] => {
    "msg": "rc=0 | first line=line one | changed=False"
}

debug: var=result is the single most useful debugging habit in Ansible. Before writing when: result.something, dump the whole object once and look at what is actually in it. Guessing key names is how people waste afternoons.

Note stdout_lines — Ansible has already split the output into a list for you. Reaching for result.stdout.split('\n') is the beginner move; stdout_lines is right there.

Also note changed=False even though this was a shell task — because changed_when: false was set. That is the Module 01 idempotency lesson applied.

PLAY [Play two - same host, different play] ************************

TASK [Can I still see the fact?] ***********************************
ok: [web01] => {
    "msg": "I am a fact"
}

TASK [Can I still see the play var?] *******************************
ok: [web01] => {
    "msg": "*** GONE ***"
}

This is the scoping rule made visible. set_fact attaches the value to the host, so it persists for the rest of the run. vars: is scoped to the play and evaporates when the play ends.

Why it matters practically: it is how you pass information between plays. Play one queries a database for the current leader node and set_facts it; play two, targeting a different host group, reads it via hostvars. There is no other clean mechanism for that.

⚠️ One caveat worth knowing: set_fact values are not written to the fact cache by default — they live only for the current run. Add cacheable: true if you need them persisted across separate ansible-playbook invocations.

register captures the complete result object a module returned — changed, failed, rc, stdout, stdout_lines, and for looped tasks a results list.

set_fact assigns a value you computed, typically from other variables, filters or facts.

Both are host-scoped and both persist for that host across subsequent plays in the same run, and both sit at level 19 of the precedence ladder.

vars: is play-scoped — it exists only within the play that defines it and disappears when that play ends.

set_fact is host-scoped — attached to the host and available in every later play of the same run.

That is precisely how you pass data between plays: set_fact in play one, then read it from another host group in play two via hostvars.

register the first task, then use a when: referencing the registered object — when: result.rc != 0, when: not stat_result.stat.exists, when: "'ERROR' in result.stdout".

The practical advice: run debug: var=result once first and look at the real structure rather than guessing key names. And prefer stdout_lines over splitting stdout yourself.

No, not by default — it lives for the current run only. Pass cacheable: true and it is written to the fact cache, which then persists across invocations subject to fact_caching_timeout.

Worth flagging the trade-off: cached values can go stale, and a stale cached fact is a genuinely unpleasant bug because the playbook looks correct.

TASK [Who am I and where do I belong?] *****************************
ok: [web01] => {
    "msg": "I am web01 | groups: ['prod', 'web'] | active in play: ['web01', 'web02', 'web03']"
}
ok: [web02] => {
    "msg": "I am web02 | groups: ['prod', 'web'] | active in play: ['web01', 'web02', 'web03']"
}

TASK [What does the whole inventory look like?] ********************
ok: [web01] => {
    "groups": {
        "all": ["web01", "web02", "web03", "db01", "stg01"],
        "db": ["db01"],
        "prod": ["web01", "web02", "web03", "db01"],
        "staging": ["stg01"],
        "ungrouped": [],
        "web": ["web01", "web02", "web03"]
    }
}

Three things to read out of this:

1. group_names shows ['prod', 'web'] — the host is in both, because web is a child of prod. That is the group inheritance from Module 01 Exercise B1.1, now visible as data.
2. groups contains the entire inventory, including hosts this play is not targeting. That is what makes hostvars['db01'] possible — Ansible knows db01 exists even when the play does not touch it. Knowing it exists is not the same as having its facts.
3. run_once: true printed it a single time instead of once per host. Without it you get the same large dictionary three times.

Also note >- in the YAML — a folded block scalar that lets a long string span lines while stripping the trailing newline. Handy for readable msg: values.

TASK [Try to read db01's IP] ***************************************
fatal: [web01]: FAILED! => {
    "msg": "The task includes an option with an undefined variable.
    The error was: \"hostvars['db01']\" is undefined"
}

Fix A — a preliminary fact-gathering play. The idiomatic answer:

- name: Gather facts from the database tier
  hosts: db
  gather_facts: true
  tasks: []            # no tasks - the point is purely the fact gathering

- name: Configure web to point at db
  hosts: web
  gather_facts: true
  tasks:
    - name: Read db01's IP
      ansible.builtin.debug:
        msg: "DB is at {{ hostvars['db01']['ansible_default_ipv4']['address'] }}"

ok: [web01] => {
    "msg": "DB is at 10.0.2.11"
}

Fix B — fact caching. With fact_caching enabled in ansible.cfg, db01's facts from any earlier run are still available and no preliminary play is needed. Faster, but the values can be stale.

Fix C — avoid facts entirely. If all you need is an address you already know, put it in the inventory as a host var. hostvars['db01']['db_ip'] works with no gathering at all, because inventory variables for every host are always loaded. Often the simplest correct answer, and worth saying so.

Variables Ansible always provides describing the run itself rather than the host's hardware.

inventory_hostname (the host's inventory name), group_names (groups this host is in), groups (every group and its members), hostvars (access to other hosts' variables and facts), ansible_play_hosts (hosts still active in the play), playbook_dir, and ansible_check_mode.

hostvars['db01']['ansible_default_ipv4']['address'].

The critical caveat: db01's facts must have been gathered in this run, otherwise it is undefined. Fix with a preliminary - hosts: db play that gathers facts and has no tasks, or enable fact caching, or — often simplest — store the address as an inventory host variable so no gathering is required at all.

inventory_hostname is the name in your inventory file — a label you chose, available with no fact gathering.

ansible_hostname is a gathered fact: the machine's actual configured hostname, which requires gather_facts and can differ entirely from the inventory name.

In a cloud inventory keyed by private IP, inventory_hostname might be 10.0.1.15 while ansible_hostname is ip-10-0-1-15.

Lowest priority at the top, highest at the bottom. Later entries override earlier ones.

 1. command line values          (e.g. -u my_user — not really variables)
 2. role defaults                (role/defaults/main.yml)
 3. inventory file or script group vars
 4. inventory group_vars/all
 5. playbook group_vars/all
 6. inventory group_vars/*
 7. playbook group_vars/*
 8. inventory file or script host vars
 9. inventory host_vars/*
10. playbook host_vars/*
11. host facts / cached set_facts
12. play vars
13. play vars_prompt
14. play vars_files
15. role vars                    (role/vars/main.yml)
16. block vars                   (only for tasks in the block)
17. task vars                    (only for that task)
18. include_vars
19. set_fact / registered vars
20. role params and include_role params
21. include params
22. extra vars                   (-e)  — ALWAYS WIN

Source: Ansible documentation — variable precedence

Run 1 — no extra vars:

TASK [Which one won?] **********************************************
ok: [web01] => {"msg": "from_play_vars"}

TASK [Task vars beat play vars] ************************************
ok: [web01] => {"msg": "from_task_vars"}

Play vars (level 12) beat host_vars (level 10), which beat group_vars (level 6). Task vars (level 17) beat everything so far.

Run 2 — with -e:

TASK [Which one won?] **********************************************
ok: [web01] => {"msg": "from_extra_vars"}

TASK [Task vars beat play vars] ************************************
ok: [web01] => {"msg": "from_extra_vars"}

Look carefully at the second task in run 2. It has vars: greeting: from_task_vars written directly on it — and it still printed from_extra_vars.

That is the meaning of "extra vars always win." Not "usually", not "unless overridden locally". There is no way to beat -e from inside a playbook. That property is what makes -e both powerful and dangerous: a stray -e env=prod in a CI job overrides every safeguard you wrote into the playbook.

There are 22 documented levels, resolved lowest to highest, but the shape is what matters:

Role defaults are the lowest real variable source — they exist to be overridden.

Extra vars (-e) are the highest and always win, with no exception.

In between, more specific beats more general: host vars beat group vars, child groups beat parent groups, and task vars beat block vars beat play vars.

One asymmetry worth calling out: a role's vars/main.yml (level 15) sits far above its defaults/main.yml (level 2) — high enough to override inventory and group_vars, which surprises people.

defaults/ for anything a user of the role might legitimately want to change — ports, versions, paths, feature flags. It is the lowest precedence, so inventory and group_vars can override it, which is the whole point.

vars/ for internal constants the role depends on and the user should not touch. It is level 15, above inventory and group_vars, so it cannot be overridden from there.

The rule of thumb: almost everything belongs in defaults/. Putting a user-facing setting in vars/ produces silent, hours-long debugging sessions where someone's group_vars change appears to do nothing.

Role vars, at level 15, beat inventory group_vars at level 6.

And this is usually a bug in the role's design rather than intended behaviour — if the value is one a consumer would want to set, it should have been in defaults/.

No. Level 22 is the ceiling — -e cannot be overridden from inside a playbook, not even by a task-level vars:.

The operational implication worth stating: -e bypasses every safeguard written into the playbook, so it should be used deliberately and, in CI, sparingly. It is convenient for a one-off override and dangerous as a habit.

Before setting a priority:

web01 | SUCCESS => {
    "winner": "zulu_won"
}

zulu won purely because z sorts after a. Nothing about the configuration expressed that intent — it is an accident of naming.

After adding ansible_group_priority=10 to [alpha:vars]:

web01 | SUCCESS => {
    "winner": "alpha_won"
}

Now the outcome is declared rather than incidental. This is a small feature that almost nobody uses and that produces genuinely mystifying bugs when they need it and do not know it exists.

The stronger design point, worth making in an interview: relying on group priority at all is usually a smell. If two groups fight over a value, the cleaner fix is often to restructure — make one a child of the other, so rule 1 settles it explicitly and readably, rather than tuning priority numbers.

{
    "ansible_host": "10.0.1.15",
    "ansible_user": "deploy",
    "deploy_batch": "first",
    "http_port": 80,
    "winner": "alpha_won"
}

@all:
  |--@prod:
  |  |--@web:
  |  |  |--web01
  |  |  |  |--{ansible_host = 10.0.1.15}
  |  |  |  |--{http_port = 80}
  |  |  |--{deploy_batch = standard}

ansible-inventory --host <name> is the fastest possible answer to "what value does this host actually have?" It resolves everything from the inventory layer and prints the result, with no connection to the host at all.

⚠️ Important limitation to state if asked: this shows the inventory-derived variables only. It cannot show play vars, role vars, facts, or set_fact values, because those exist only during a play. For the full runtime picture you need debug: var=... inside the play itself, or -vvv.

In group_vars/ and host_vars/ directories, one file per group or host, rather than inline in the inventory file. group_vars/all.yml for global defaults, then per-group files, then host_vars/ for genuine per-host exceptions.

The filename must exactly match the group or host name — a mismatch is ignored silently with no warning.

A directory such as group_vars/prod/ also works and merges every file inside it, which is how teams separate plain config from Vault-encrypted secrets.

First: a child group beats its parent, always.

Between siblings at the same level: the higher ansible_group_priority wins, default 1.

If priorities tie, it falls back to alphabetical order by group name, last one winning — which is non-obvious and a real source of bugs, because renaming a group can silently change behaviour.

And host vars beat all group vars regardless.

Good closing thought: if two groups are fighting over a value, restructuring so one is a child of the other is usually cleaner than tuning priority numbers.

ansible-inventory --host web01 shows everything resolved from the inventory layer, without connecting to anything.

For runtime values — facts, set_fact, play vars — use debug: var=myvar inside the play, or debug: var=hostvars[inventory_hostname] to dump the host's entire variable space at once.

-vvv also reveals the resolved arguments a module received, which catches templating mistakes.

ok: [localhost] => {
    "msg": [
        "undefined,       default()      -> FALLBACK",
        "empty string,    default()      -> ''",
        "empty string,    default(x,true)-> 'FALLBACK'",
        "zero,            default()      -> 0",
        "zero,            default(x,true)-> FALLBACK",
        "real value,      default()      -> actual"
    ]
}

Rows 2 and 4 are the ones that catch people. An empty string and a zero are defined, so plain default() passes them straight through. You end up writing an empty value into a config file and wondering why the service will not start.

⚠️ But note row 5 is a genuine trap in the other direction. default('FALLBACK', true) replaced a legitimate 0. If your variable is retry_count: 0 or enable_feature: false, the boolean form will silently override a deliberate falsy setting.

The rule: use default(x, true) for strings that must not be empty; use plain default(x) for numbers and booleans where 0 and false are meaningful values.

{{ myvar | default('fallback') }} to supply a value, {{ myvar | mandatory }} to fail loudly and clearly if it is missing, or when: myvar is defined to skip the task entirely.

The nuance to add: default('x') only triggers on undefined. Use default('x', true) to also catch empty strings — but not for numbers or booleans, where it would wrongly replace a legitimate 0 or false.

When there is no sensible default and running without the value would do something wrong. mandatory fails fast with a clear message naming the variable, rather than proceeding with a placeholder that silently produces a broken configuration.

A common example: a deployment version. Defaulting it to latest is worse than refusing to run.

Shallow merge:

{
    "debug": false,
    "host": "0.0.0.0",
    "port": 9090,
    "tls": {
        "cert": "/etc/ssl/custom.pem"
    }
}

Recursive merge:

{
    "debug": false,
    "host": "0.0.0.0",
    "port": 9090,
    "tls": {
        "cert": "/etc/ssl/custom.pem",
        "enabled": true
    }
}

Compare the tls block. The shallow merge kept top-level keys but replaced the entire nested tls dictionary, losing enabled: true. Only recursive=True merged inside the nested level.

This is the bug in miniature. Shallow-merging a config with nested TLS settings silently drops enabled: true, TLS quietly turns off, and nothing in the output suggests anything went wrong. When merging any dictionary that has nested dictionaries, you almost always want recursive=True.

By default the higher-precedence definition replaces the whole dictionary — keys present only in the lower-precedence version are lost. It does not merge.

The fix is the combine filter, and recursive=True when the dictionary has nested dictionaries, otherwise nested levels are replaced wholesale.

There is also a global hash_behaviour = merge setting, but it is deprecated and changes semantics for every dictionary in the project — including inside imported Galaxy roles that were written expecting replace.

It changes behaviour globally and invisibly. Any role written and tested against the default replace semantics may behave differently, and the same playbook produces different results on a machine with a different ansible.cfg.

combine() is explicit at the point of use, reviewable in a diff, and scoped to the one place you meant it.

TASK [Create a file with a known owner] ****************   changed: [web01]

TASK [Update it, passing an EMPTY owner] ***************
fatal: [web01]: FAILED! => {"msg": "chown failed: failed to look up user ''"}
...ignoring

TASK [Update it, using omit instead] *******************   changed: [web01]

An empty string is a value. The module dutifully tried to chown the file to a user literally named "" and failed. omit removed the argument entirely, so copy simply left the existing ownership alone.

Why this matters for roles: a role that exposes app_file_owner as an optional setting must use default(omit), otherwise every consumer who does not set it gets a hard failure. Using default('') there is a genuine bug, and it is one that only shows up for the users who did not configure the option — the people least likely to know why.

A special value that tells Ansible to not pass that parameter at all, as distinct from passing an empty one.

Use it for genuinely optional module arguments — owner: "{{ file_owner | default(omit) }}". Without it, an unset variable becomes an empty string and the module tries to act on it, typically failing.

It matters most when writing reusable roles, where you cannot know which options the consumer will supply.

Always the control node. lookup('file', '/etc/hostname') reads the control node's file, lookup('pipe', 'hostname') runs the command locally.

To read a file on the target you need the slurp module, or command: cat with register.

Getting this wrong is insidious because you get a real, plausible-looking value — from entirely the wrong machine.

The environment differs. Ansible runs a non-interactive SSH session, so profile scripts that are guarded to interactive shells — much of .bashrc, and often .bash_profile — are never sourced. PATH in particular is frequently shorter.

Fixes: use an absolute path to the binary; set what you need explicitly with environment:; or inspect ansible_env.PATH to see what the task actually has.

ok: [localhost] => {
    "msg": [
        "real_bool   is bool",
        "string_bool is str"
    ]
}

TASK [This is correctly SKIPPED] ***********************************
skipping: [localhost]

TASK [This RUNS - and it should not] *******************************
ok: [localhost] => {
    "msg": "string_bool was truthy!"
}

"false" is a non-empty string, and every non-empty string is truthy. The task ran despite the variable saying false in plain sight.

Where this actually bites you: -e passes everything as a string. So ansible-playbook site.yml -e enable_debug=false sets enable_debug to the string "false", and every when: enable_debug guard in your playbook fires.

Three defences:

when: myvar | bool               # cast it explicitly

ansible-playbook site.yml -e '{"enable_debug": false}'    # JSON syntax preserves the real type

- ansible.builtin.assert:
    that: myvar is boolean
    fail_msg: "myvar must be a real boolean, not a string"

| bool is the everyday answer, and knowing why it is needed — that -e stringifies everything — is the part interviewers are actually probing.

debug: var=myvar for the value, debug: var=hostvars[inventory_hostname] to dump every variable the host has, and {{ myvar | type_debug }} to check its type — which is the actual cause more often than people expect.

ansible-inventory --host <name> for the inventory-derived layer without connecting, and -vvv to see the resolved arguments a module actually received.

And assert to fail early with a clear message rather than letting a bad value propagate into a config file.

Because myvar is the string "false", not the boolean false — and any non-empty string is truthy.

The usual source is -e, which passes everything as a string: -e enable_debug=false yields "false".

Fixes: when: myvar | bool to cast explicitly, or pass JSON on the command line — -e '{"enable_debug": false}' — which preserves the real type. type_debug is how you confirm the diagnosis in one line.

---
# Requirement 1: db01's facts must exist before web can read them
- name: Gather facts from the database tier
  hosts: db
  gather_facts: true
  tasks: []

- name: Capstone - variables, facts and precedence
  hosts: web
  gather_facts: true
  vars:
    base_config:
      host: 0.0.0.0
      port: 8080
      tls:
        enabled: true
        cert: /etc/ssl/default.pem
    env_overrides:
      production:
        port: 443
        tls:
          cert: /etc/ssl/prod.pem
      staging:
        port: 8443

  tasks:
    - name: Requirement 3 - fail fast on a missing env
      ansible.builtin.assert:
        that:
          - env is defined
          - env in env_overrides
        fail_msg: "env must be set to one of: {{ env_overrides.keys() | list }}"

    - name: Requirement 2 - merge, preserving nested keys
      ansible.builtin.set_fact:
        final_config: "{{ base_config | combine(env_overrides[env], recursive=True) }}"
        app_version_resolved: "{{ app_version | default('1.0.0', true) }}"
        tls_on: "{{ enable_tls | default(true) | bool }}"      # requirement 5

    - name: Requirement 1 + 4 - write the config
      ansible.builtin.copy:
        dest: /etc/myapp/app.conf
        owner: root
        group: root
        mode: "0644"
        content: |
          # generated by ansible - do not edit
          app_version={{ app_version_resolved }}
          environment={{ env }}
          listen_host={{ final_config.host }}
          listen_port={{ final_config.port }}
          tls_enabled={{ tls_on }}
          tls_cert={{ final_config.tls.cert }}
          db_host={{ hostvars['db01']['ansible_facts']['default_ipv4']['address'] }}
      become: true

The five things most people miss:

1. The preliminary hosts: db play with tasks: []. Without it, hostvars['db01'] has no facts and requirement 1 fails. This is Exercise B4.2.
2. recursive=True. Without it the nested tls dictionary is replaced wholesale and enabled: true silently disappears — TLS quietly turns off.
3. default('1.0.0', true) with the boolean argument — so an empty app_version also falls back, not only an undefined one.
4. | bool on enable_tls. -e enable_tls=false arrives as the string "false", which is truthy. Without the cast, requirement 5 fails and TLS stays on when you asked for it off.
5. assert rather than default for env. There is no safe default for an environment name — defaulting it would deploy staging config to production. Fail loudly.

Verify all six:

ansible-playbook capstone.yml -e env=production
ansible-playbook capstone.yml -e env=production            # changed=0
ansible-playbook capstone.yml                              # should FAIL on the assert
ansible-playbook capstone.yml -e env=production -e enable_tls=false
ssh web01 'cat /etc/myapp/app.conf'

Lowest real variable source: role defaults (defaults/main.yml) — they exist to be overridden.

Highest: extra vars (-e) — they always win and cannot be overridden from inside a playbook, not even by a task-level vars:.

In between, more specific beats more general: host beats group, child group beats parent, task beats block beats play.

It sits at level 15, above inventory group_vars (6) and host_vars (9–10). A consumer of the role setting the value in group_vars sees it silently ignored, with no warning.

Anything a user might want to change belongs in defaults/ at level 2.

register captures a module's complete result object. set_fact assigns a value you computed. Both are host-scoped and persist across later plays in the same run, both at level 19.

vars: is play-scoped and disappears when the play ends. That difference is how you pass data between plays.

Higher ansible_group_priority wins (default 1). If tied, alphabetical by group name, last one winning — which means renaming a group can silently change behaviour.

Child groups always beat parents regardless of priority, and host vars always beat all group vars.

Because db01's facts were never gathered — the play never connected to it. groups knows db01 exists; that is not the same as having its facts.

Fix with a preliminary - hosts: db play with gather_facts: true and tasks: [], or fact caching, or store the value as an inventory host var so no gathering is needed.

The higher one replaces the whole dictionary — it does not merge. Keys only in the lower version are lost.

Fix with combine(), and recursive=True whenever there are nested dictionaries, otherwise nested levels are still replaced wholesale.

myvar is the string "false", and non-empty strings are truthy. Usually caused by -e, which passes everything as a string.

Fix with | bool, or pass JSON: -e '{"myvar": false}'. Confirm the diagnosis with type_debug.