Ansible / Basic: execution, inventory, and typed state / Lesson 3

Design inventory and verify target selection

Separate inventory identity, connection addresses, group membership, host patterns, and effective execution scope.

About 4 min readContent reviewed 2026-10-25

On this page

Lesson goals

Explain inventory sources and group relationships.
Distinguish inventory_hostname from connection parameters.
Validate intended host populations before any effects.

An inventory name is not necessarily a DNS name

A host’s inventory identity can be a stable project alias, while ansible_host supplies a connection address or name. Group membership describes automation roles rather than proving network reachability or application authorization. Keep these concepts separate so renaming an alias does not silently change connection intent. The same inventory host can belong to several groups and should still be understood as one host identity. Repeating a host in different sources can merge associated data under documented rules, so source order and plugin behavior matter. Inventory is executable selection input, not merely a decorative server list.

Use a readable hierarchy for synthetic inventory

YAML inventory can define groups, child groups, hosts, and variables. A child group inherits relevant parent membership relationships, while a host can receive variables from more than one level. Avoid a hierarchy whose incidental names encode conflicting deployment dimensions. Roles such as application tier and environments such as review can be modeled deliberately, with intersections selected through documented patterns. The example uses fictional aliases and documentation addresses only. It is parsed as data and is never supplied to an Ansible connection command, so no hostname resolution or SSH access occurs.

yaml Illustrative YAML inventory with explicit aliases

all:
  children:
    lab_nodes:
      hosts:
        lab_web_a:
          ansible_host: 192.0.2.10
        lab_web_b:
          ansible_host: 192.0.2.11
      vars:
        lab_role: report

The host aliases and connection addresses are separate fields. This inventory is non-runnable and was checked for YAML structure only, never used as a real target source.

Patterns select a population from the inventory

A play’s hosts expression and command-line limits interact to select hosts under Ansible’s pattern rules. Union, intersection, exclusion, and group names have specific syntax; do not substitute a mental regular-expression model. An empty match can skip all work, while an overly broad match can affect unintended targets. Review the resolved population in a safe workflow before changes. A limit does not automatically constrain every lookup, delegation, or controller-side action in a play. Selection review should therefore include task behavior, not only the initial play host set.

Model set membership without resolving real inventory

An offline set calculation can demonstrate an intended intersection and exclusion. It does not implement Ansible’s pattern parser or inventory plugins. Label that distinction and compare the model with actual resolved inventory only in an independently authorized environment. Keep a small expected-host fixture in version control so an inventory edit can be reviewed as a population change. Include negative cases such as an excluded maintenance node. A passing population model does not prove variable merging, connection safety, or privilege choices, so preserve those as separate review items.

python Check a declared intersection and exclusion

web = {'lab_a', 'lab_b', 'lab_c'}
review = {'lab_b', 'lab_c', 'lab_d'}
maintenance = {'lab_c'}
selected = (web & review) - maintenance
print(','.join(sorted(selected)))

Expected output

lab_b

Only lab_b belongs to both required sets and is not excluded. This pure set model reads no configured inventory and cannot connect to any host.

Treat dynamic sources as versioned dependencies

Inventory plugins can query external systems and construct groups or variables, so generating inventory may itself contact services and require credentials. Do not assume a list-only operation is always offline. Pin the plugin collection, define cache behavior, and separate production and disposable sources through explicit project configuration. Keep credentials out of inventory files and diagnostic output. A source that changes between review and execution can change the target population, so establish a reproducible handoff or revalidation rule. This course never executes inventory plugins or reads the machine’s configured Ansible inventory.

Common errors and fixes

An alias is assumed to be the connection address

Why it happens: Inventory identity and ansible_host were conflated.
How to fix it: Inspect the explicit connection variables in the plan.
Prevent it next time: Document alias and endpoint separately.

A limit is assumed to constrain delegated actions automatically

Why it happens: Play-host selection was confused with task execution location.
How to fix it: Review delegation and controller-side actions explicitly.
Prevent it next time: Test scope at each execution boundary.

An inventory preview unexpectedly queries a service

Why it happens: Dynamic plugin evaluation was assumed inert.
How to fix it: Use synthetic static fixtures for offline review.
Prevent it next time: Classify inventory sources by external effects.

Check your understanding

1. Two groups contain the same alias. Does that imply two independent managed machines?

Show worked solution

No. One inventory host can have several memberships. Review its merged variables and identity rather than double-counting it. If two actual endpoints are intended, represent their identities explicitly and avoid accidental alias collision.

2. What should an inventory-change review prove before task execution?