// learn · linux · rhce · 10 min

Ansible core modules.

Modules are the verbs that do Ansible's real work — and they're idempotent. Instead of running commands, you declare a desired state (`state: present`, `enabled: true`) and the module figures out whether to act. Walk through file/copy/template, user/group, dnf/package, and service/systemd.

Ansible core modules animated tutorial. The idempotent desired-state model, file copy lineinfile and template for files, user and group for accounts, dnf and package for software, service and systemd for daemons, and reading ansible-doc to find any module's arguments, return values, and examples offline. RHCE EX294 ready.
// ansible · core modules

Modules are the verbs that do Ansible's real work — and they're idempotent. Watch a file, a user, a package, and a service each get brought to a declared state by the module that manages it.

// before you start
you should know
  • ·The Ansible control node + inventory model
  • ·Basic YAML (tasks are YAML mappings)
  • ·Comfortable with Linux files, users, packages, services
by the end you'll

Reach for the right core module for files, accounts, software, and services — file/copy/template, user/group, dnf/package, service/systemd — declaring desired state instead of running commands, and read ansible-doc to find any module's args.

pace: 10 minutes

ansible — step 1 / 6 · the idea
🧩 managed resourcesdeclare state → module converges →
📄 /etc/motd● ok
missingpresent
👤 deploy● ok
absentpresent
📦 httpd● ok
not installedinstalled
🔌 firewalld● ok
stoppedrunning

Modules are the verbs — and they're idempotent

A module is a self-contained unit of work that brings ONE kind of resource to a declared state. Instead of running a command, you set `state:` and let Ansible check the resource first and act only if it isn't already there. That's idempotency: the same task is safe to run a hundred times. Always reach for the fully-qualified name — ansible.builtin.MODULE (FQCN) — so there's no ambiguity about which collection a module comes from.

$ansible-doc -l
$ansible-doc ansible.builtin.file
$ansible-doc -s copy
// key insight

With modules you declare the desired STATE (state: present, enabled: true) and Ansible figures out whether to act. That's why the same task is safe to run a hundred times — and why command/shell should be your last resort, not your first.

// exam-ready · core modules & ansible-doc
$ansible.builtin.file
$ansible.builtin.copy
$ansible.builtin.lineinfile
$ansible.builtin.blockinfile
$ansible.builtin.template
$ansible.builtin.user
$ansible.builtin.group
$ansible.builtin.dnf
$ansible.builtin.package
$ansible.builtin.service
$ansible.builtin.systemd
$ansible-doc -l
$ansible-doc MODULE
$ansible-doc -s MODULE
// check yourself
4 quick questions
Q1

Which is the idempotent way to ensure httpd is installed?

Q2

What's the difference between state=present and state=latest for a package?

Q3

On the exam, with no internet, how do you discover a module's arguments and examples?

Q4

You set a user's password with the `user` module by passing the plaintext, but login fails. Why?

These aren't graded — they're just for active recall, which is what actually makes the lesson stick.

🔢
// next: data

Ansible variables & facts

Modules need values — where do they come from? Play vars, group_vars/host_vars, the command line, and the facts Ansible gathers automatically from every managed node.

open →
// more in systems

keep going — these pair well with what you just learned.

see all systems
back to RHCSA / RHCE trackall lessons