RHCE key terms

A file, in INI or YAML format, that lists the managed hosts Ansible can target, optionally grouped under labels so tasks can be addressed to whole sets of machines at once.

A named collection of hosts inside an inventory file, used to target plays or tasks at many machines together. Groups may contain child groups and can carry group-level variables.

The expression given to a play or ad hoc command that selects which inventory hosts to act on, such as all, a group name, a single host, or a wildcard combination.

The configuration file Ansible reads to set defaults such as inventory location, remote user, privilege escalation, log path, and plugin paths. Values are resolved in a defined precedence order of files and environment.

The ordered rule set deciding which configuration value wins: environment variables, then the nearest ansible.cfg found, then the user home file, then the system-wide file, then built-in defaults.

An environment variable that points Ansible at a specific configuration file, overriding the automatic search order and thereby taking the highest practical precedence among config sources.

An inventory supplied as a plain text file that Ansible parses each run; it is manually maintained rather than generated from an external source such as a cloud provider.

An executable script or plugin that queries an external system at runtime and returns host and group data in JSON, so inventories stay current without manual editing.

A single ansible invocation that runs one module against chosen hosts without writing a playbook, useful for quick checks, one-off changes, and testing connectivity.

A reusable unit of work, such as copy, user, or service, that Ansible ships to a managed node and runs to make a specific change or gather information.

The property that running the same task repeatedly produces the same end state, reporting no change on later runs once the desired condition is already true.

A YAML file describing a sequence of plays that map inventories hosts to tasks, allowing repeatable multi-step automation that can be stored in version control.

A top-level entry inside a playbook that binds a set of hosts to a list of tasks plus settings like variables, remote user, and privilege escalation.

The smallest named step in a play, pairing one module with its arguments and optional keywords such as conditionals, loops, and handlers notification.

A task that only runs when notified by another task that reports a change, typically used to restart a service once even if several tasks touched its configuration.

A task keyword naming one or more handlers to trigger if that task results in a change, so follow-up actions run only when something actually changed.

A reusable, standardized directory structure holding tasks, handlers, defaults, variables, files, templates, and metadata, so related automation can be shared and applied repeatedly.

The configuration setting listing directories where Ansible searches for roles by name when a playbook references them, letting shared role libraries stay outside the project.

The documented ranking that decides which value wins when the same variable name is defined in several places, from low-precedence role defaults up to extra vars.

Variables supplied with -e on the command line. They carry the highest precedence in Ansible, overriding every other variable source for that run.

A directory or file convention where variables are stored for an inventory group; files named after the group apply automatically to every host that belongs to it.

A directory or file convention holding variables for a single inventory host, applied automatically and taking precedence over group-level variables for that host.

A play keyword listing external YAML variable files to load for the play, keeping large or sensitive variable sets out of the playbook body itself.

System information such as hostname, interfaces, memory, and distribution that Ansible collects from a managed node and exposes as prepopulated variables for use in plays.

A play keyword, true by default, that controls whether Ansible automatically collects system facts from each targeted host before running the play's tasks.

The module Ansible runs behind the scenes to collect facts from a managed node; it can also be called directly through an ad hoc command.

A module that defines or overrides a variable during play execution, so a value computed from facts or earlier results can be reused by later tasks and plays.

A task keyword that stores a task's result, including return values and change status, in a variable so later tasks can test or reuse that output.

A task keyword holding a condition that decides whether the task runs at all, evaluated per host using variables, facts, or registered results.

A task keyword that repeats the module once for each item in a supplied list, with the current item available as a variable inside the task arguments.

Files containing static text plus Jinja2 expressions that Ansible renders on the control node and then deploys, commonly used to generate configuration with per-host values.

The module that renders a Jinja2 template file and copies the result to a managed host, changing the file only when the rendered content differs.

The default transport Ansible uses to reach Linux managed nodes, connecting as a chosen remote user and optionally using keys, agent forwarding, or password authentication.

The setting or play keyword naming the account Ansible authenticates as on a managed node before escalating privileges inside tasks.

The mechanism, usually via sudo, that lets a task run with root rights on the managed node even though Ansible connected as an ordinary user; controlled by become keywords.

The keyword or command-line flag that enables privilege escalation for a play, task, or ad hoc command, optionally paired with become_user and become_method settings.

A command-line utility that inspects an inventory and prints hosts, groups, or resolved variables in various formats, helpful for validating parsing and debugging group data.

A command-line tool that shows documentation for installed modules and plugins, including parameters, return values, and usage examples, without leaving the terminal.

The command that executes a playbook, offering flags for syntax checking, dry runs with check mode, listing hosts or tasks, and overriding variables at run time.