Where on disk does Ansible look for `group_vars/` and `host_vars/`, and which file wins when a host belongs to several groups?

## They are directories, and location matters `group_vars` and `host_vars` are not configuration keys — they are directory names Ansible searches for automatically. It searches two roots: 1. the directory containing the inventory you passed to `-i` (if `-i` is a directory, that directory itself), 2. the directory containing the playbook you are running. Both are loaded if both exist, and the playbook-adjacent files take precedence over the inventory-adjacent ones. This single fact explains most "my variable is being ignored" reports: someone put `group_vars/prod.yml` at the repository root while the inventory lives in `inventories/prod/hosts.yml`, so the file the *inventory* would have loaded was never there, or a stale playbook-level copy is quietly overriding it. A typical layout that keeps the two straight: ``` inventories/ prod/ hosts.yml group_vars/ all.yml webservers.yml host_vars/ web01.yml staging/ hosts.yml group_vars/ all.yml site.yml ``` Here `-i inventories/prod` finds the prod variables and nothing else. Switching to `-i inventories/staging` swaps the entire variable set with it, which is the point. ## File naming rules The file base name must equal the group or host name exactly: `group_vars/webservers.yml` for the group `webservers`, `host_vars/web01.yml` for the host whose inventory name is `web01`. Extensions `.yml`, `.yaml`, `.json` or none are all accepted. A typo produces no error at all — the file is simply never loaded, which is the second most common failure after wrong directory. Two names are worth calling out. `group_vars/all.yml` applies to every host, because every host is in the implicit `all` group. And `host_vars` keys off the inventory *name*: for the entry `web01 ansible_host=10.0.1.11`, the file is `host_vars/web01.yml`, never `host_vars/10.0.1.11.yml`. Either name can also be a directory: ``` group_vars/ webservers/ 00-network.yml 10-tuning.yml ``` All files inside are loaded in alphabetical order, later files overriding earlier ones for the same key. Teams use this to keep large groups readable, and to isolate an encrypted file from plain ones. ## Resolution when a host is in several groups Within these inventory variable files the rule is *more specific wins*: - `group_vars/all` is applied first, - then parent groups, then their children — a child group's value overrides its parent's, - then `host_vars`, which beat every group file. When two groups sit at the same depth and neither is an ancestor of the other, Ansible applies them in alphabetical order by group name, so the alphabetically last one wins. That is deliberate but rarely what a reader expects, so Ansible offers `ansible_group_priority` — set it in a group's vars (default `1`, higher wins) to break same-depth ties explicitly instead of relying on the group's name. ## Replace, not deep merge By default a value defined in a more specific place replaces the less specific one outright, including dictionaries. If `group_vars/all.yml` defines `app: {port: 8080, workers: 4}` and `group_vars/webservers.yml` defines `app: {port: 9090}`, hosts in `webservers` see only `port: 9090` — `workers` is gone. There is a global hash-behaviour setting that switches this to merging, but flipping it changes the semantics of every variable in the project and is widely discouraged; the maintainable fix is to flatten the keys (`app_port`, `app_workers`) or merge explicitly where you need it. ## Practical checks `ansible-inventory -i inventories/prod --list --yaml` dumps the fully resolved variables per host, which settles any argument about which file won. `ansible-inventory --graph --vars` shows the same information laid out over the group tree. Reaching for either takes seconds and beats adding debug tasks to a playbook.