In Ansible, when do you reach for set_fact versus register versus vars_files, and what is the scope and lifetime of a variable created by set_fact?

## Three different jobs Candidates often treat these as three syntaxes for the same thing. They are not. **`vars_files`** is a play keyword that loads YAML files at play start: ```yaml - hosts: web vars_files: - vars/common.yml - "vars/{{ env }}.yml" tasks: [] ``` Everything in those files is available for the whole play. The filename itself may be templated, but only from variables already known when the play begins — you cannot use `vars_files` to load something based on a fact you have not gathered yet in this play. For that, `include_vars` is the task-time equivalent, and it sits higher in precedence. **`register`** attaches the *result object* of a task to a name, per host: ```yaml - name: Read the deployed version ansible.builtin.command: cat /srv/app/VERSION register: version_out changed_when: false - ansible.builtin.debug: msg: "{{ version_out.stdout }}" ``` What you get is a dictionary, not a string: `rc`, `stdout`, `stdout_lines`, `stderr`, `changed`, `failed`, plus module-specific fields. When the task has a `loop`, you get `version_out.results`, a list with one entry per iteration — forgetting that is a very common bug. A registered variable is always set, even when the task is skipped; a skipped task's result carries `skipped: true` and no `stdout`, which is why defensive code writes `version_out.stdout | default('')`. **`set_fact`** is explicit assignment at task time: ```yaml - name: Name the thing properly ansible.builtin.set_fact: app_version: "{{ version_out.stdout | trim }}" is_stale: "{{ version_out.stdout | trim != desired_version }}" ``` This is where derived values belong. It also solves a real problem: unlike a `vars:` entry, which is a lazily-evaluated Jinja expression re-rendered every time it is referenced, `set_fact` freezes a computed value once, at the moment the task runs. ## Scope and lifetime — the part that gets asked A `set_fact` value is stored against the **host**, exactly like a gathered fact. Three consequences: 1. **It is not global.** If the task ran only on `web1` (because of a `when`, a `run_once`, or a failure elsewhere), only `web1` has the value. Other hosts referencing it get an undefined-variable error. To read one host's fact from another host you go through `hostvars['web1'].app_version`. 2. **It persists across plays in the same run.** Set it in play one, read it in play three, for the same host. This is the sanctioned way to hand information between plays. 3. **It does not survive the process.** The next `ansible-playbook` invocation starts clean — unless you pass `cacheable: yes`, which additionally writes the value into the configured fact cache (`fact_caching = jsonfile` or `redis` in `ansible.cfg`), where it will be read back on subsequent runs. There is a subtlety in precedence between those two forms. A `set_fact` executed in the current run sits near the top of the ladder (level 19 of 22), above play vars and role vars. A value restored from the fact cache is treated as a *host fact* and sits much lower (level 11), below play vars. So a value can win today and lose tomorrow depending on whether it was just computed or read from cache — worth stating explicitly if the interviewer probes. A related keyword is `delegate_facts: true`, which stores the fact against the *delegated* host rather than the current one — used when a task runs somewhere else (a bastion, a load balancer) but the resulting information logically belongs to that other host. And `meta: clear_facts` discards gathered and set facts mid-run, which is occasionally needed after an action that invalidates them, such as rebooting into a new kernel. ## Choosing between them - Static configuration known before the run: `defaults/main.yml`, `group_vars`, or `vars_files`. - The outcome of a command or module: `register`, then read the fields you need. - Anything derived, conditional or computed that more than one later task will use: `set_fact`, once, with a clear name. - A value that must cross plays for one host: `set_fact`. - A value that must cross runs: `set_fact` with `cacheable: yes`, plus fact caching configured — and be honest about the staleness that introduces. The anti-pattern to name is using `set_fact` inside a loop to accumulate a list by re-assigning `mylist: "{{ mylist + [item] }}"`. It works, but it is slow and unreadable at scale; Jinja filters such as `map`, `select` and `zip` usually express the same transformation in one expression.