In an Ansible playbook targeting a remote server, where does `{{ lookup('file', '/etc/motd') }}` read that file from — the control node or the managed host?

## Where templating happens Ansible's execution model is: the controller renders the task — resolving variables and Jinja expressions — then packages the module with its arguments, ships it to the target, executes it there, and collects the JSON result. Everything in `{{ }}` is resolved *before* anything reaches the managed host. Lookup plugins are part of that templating step. They are plugin code that runs inside the controller's own Python process, with the controller's filesystem, environment variables, network position and credentials. This is not a quirk; it is the whole point. Lookups exist so the controller can pull data *into* the run from where the controller sits — a file in the repository, a secret store the controller can authenticate to, an environment variable set by CI. ## The consequences people get wrong - `lookup('file', '/etc/motd')` reads the controller's `/etc/motd`. On a run against 200 servers, all 200 tasks get the same content — the controller's. - `lookup('env', 'HOME')` reads the controller user's environment, not the remote user's, and not the `become` user's. - `lookup('pipe', 'git rev-parse HEAD')` runs the command on the controller, in the controller's working directory. - `lookup('password', 'creds/db.txt')` generates and stores the password file on the controller. - `delegate_to: other_host` does not move any of this. Delegation changes the host the module executes against; templating, and therefore lookups, still happen on the controller. That last one is the trap most worth internalising, because delegation feels like it should relocate everything about the task. ## How to actually read remote data Use a module, because modules are the part that runs on the target: ```yaml - name: Read a remote file ansible.builtin.slurp: src: /etc/motd register: motd_raw - name: Decode it ansible.builtin.set_fact: motd: "{{ motd_raw.content | b64decode }}" ``` `slurp` returns the content base64-encoded, hence the `b64decode`. `fetch` is the alternative when you want the file copied back to the controller as a file rather than into a variable. For arbitrary output, a `command` with `register` and `changed_when: false` does the job. ## Lookup versus query ```yaml - ansible.builtin.debug: msg: "{{ lookup('file', 'a.txt', 'b.txt') }}" # one comma-joined string - ansible.builtin.debug: msg: "{{ item }}" loop: "{{ query('file', 'a.txt', 'b.txt') }}" # a real list ``` `lookup()` returns a string by default, joining multiple terms with commas — a legacy behaviour that silently mangles data when you feed it to a loop. `query()` (and its short form `q()`) is equivalent to `lookup(..., wantlist=True)` and always returns a list. Modern `loop:` should be fed by `query()`; the older `with_file:`, `with_items:` style keywords are themselves thin wrappers over the corresponding lookup plugin, which is the historical reason the two concepts are entangled. ## Errors and safety A lookup that fails — missing file, unreachable secret store — is a fatal error for the task by default. Most lookup plugins accept `errors='warn'` or `errors='ignore'` to soften that, and wrapping the expression in Jinja's `default()` will not save you, because the failure happens inside the plugin rather than producing an undefined value. Two operational notes worth carrying into an interview. First, because lookups run on the controller with the controller's credentials, a lookup against a secret store means every operator (and every CI runner) executing that playbook needs that access — the blast radius of a lookup is the controller's identity, not the target's. Second, lookups are evaluated every time the expression is rendered, so a lookup embedded in a variable used inside a large loop can be executed once per iteration; assigning it once with `set_fact` avoids surprising repeated calls to whatever the lookup talks to.