Ansible Core Modules for Real Work: package, service, copy, file, template, user & lineinfile

You have learned what a playbook is — plays, tasks, become, the execution model. But a play is only ever as useful as the modules the tasks call, and a handful of modules do the overwhelming majority of real work. If you can install a package, manage a service, lay down a file (verbatim or rendered from a template), make a surgical edit to a config that something else owns, create a user, fetch a tarball and unpack it, and pull a log back for inspection — you can already automate the configuration of almost any Linux server. This lesson is the exhaustive reference for exactly that toolkit: ansible.builtin.package/dnf/apt, ansible.builtin.service/systemd, ansible.builtin.copy/template/file, ansible.builtin.lineinfile/blockinfile, ansible.builtin.user/group, and ansible.builtin.get_url/unarchive/fetch. For each one you get the key options laid out in a table — what it is, the choices, the default, when to reach for it and the gotcha — plus the single most important property of all of them: idempotency, the rule that re-running a task already in the desired state changes nothing and reports ok, not changed.

I have written this to be the page you keep open while you write playbooks. It is beginner-accessible — every option and every term is explained the first time it appears — but it is deliberately complete, because the difference between a fragile script and a production-grade playbook is almost always a module option somebody did not know existed: the backup that saves you, the validate that refuses to install a broken config, the mode you got wrong because you typed 644 instead of '0644', the create: yes that turns lineinfile from a surgical tool into a file generator. We use fully-qualified collection names (FQCN) throughout — ansible.builtin.copy, not bare copy — because that is the modern, unambiguous, lint-clean way to write Ansible in 2026, and the habit will save you the day two modules in different collections share a short name. By the end you will reach for the right module and the right option by reflex, and the closing “configure a web server” mini-playbook shows the whole toolkit working together to turn a bare host into a running, content-serving, hardened web server — idempotently, so the hundredth run is as safe as the first.

Learning objectives

After working through this lesson you will be able to:

• Install, upgrade and remove software with ansible.builtin.package and the OS-specific dnf/apt modules, and know when to use the generic versus the specific module.
• Start, stop, enable and restart daemons with ansible.builtin.service and ansible.builtin.systemd, and explain state versus enabled and when daemon_reload is required.
• Choose correctly between copy (verbatim bytes), template (Jinja2-rendered), and file (state of a path: file/directory/link/absent) — and set ownership and permissions on all three.
• Make surgical, idempotent edits to files you do not fully own with lineinfile (one line) and blockinfile (a managed region), using regexp, line, insertafter/insertbefore and validate.
• Manage accounts and groups with user and group — shells, supplementary groups, SSH keys, hashed passwords and system accounts.
• Move files around with get_url (download), unarchive (fetch + unpack), and fetch (pull a file back from a managed node).
• Read and write Linux file modes in both octal ('0644') and symbolic (u=rw,g=r,o=r) form, and avoid the classic YAML octal gotcha.
• State the idempotency rule of each module — what makes it report changed versus ok — and use --check/--diff to verify before you act.

Prerequisites

You need a working control node and at least one managed node you can reach over SSH with privilege escalation, plus the playbook fundamentals: a play’s hosts, become, tasks, and the ansible-playbook command with --check and --diff. If you have read Ansible Playbooks, In Depth: Plays, Tasks, Modules, Become & Your First Playbook you have exactly the right footing — this lesson is the natural sequel, filling the otherwise-empty tasks: list with the modules that actually do the work. This is a Foundation (Playbooks) lesson in the Ansible Zero-to-Hero ladder: everything later — variables and facts, conditionals and loops, Jinja2 templating, roles — assumes you already know these modules cold, because they are what every role’s tasks/main.yml is built from. The lab at the end runs entirely against localhost and a free local container, so there is no cost to follow along.

Core concepts: modules, idempotency and the change report

Before the option tables, fix four ideas that apply to every module below.

A module is a small program that runs on the managed node and reports JSON. When a task calls ansible.builtin.copy, Ansible ships the module code (Python) plus your arguments to the target, runs it there against the target’s own Python interpreter, captures a JSON result, and removes the temporary code. Your control node never touches the target’s files directly — the module does, locally on the host. This is why modules are fast and why the target needs Python (for most modules), and why the result of every task is a structured object you can register and inspect (.changed, .rc, .stdout, module-specific keys).

Idempotency is the whole point — declare state, not steps. A well-written module is declarative: you describe the desired end state (“this package is present”, “this line exists in the file”, “this service is running and enabled”) and the module figures out whether reality already matches. If it does, the module does nothing and reports ok (unchanged); if it does not, the module makes the minimum change and reports changed. This is what lets you run the same playbook a hundred times safely. The two modules that are not idempotent — ansible.builtin.command and ansible.builtin.shell — run their command every time regardless, which is exactly why you prefer a purpose-built module whenever one exists, and why you use changed_when/creates/removes to teach the command modules when they really changed something.

changed versus ok is a status, and it drives handlers. Every task reports one of ok, changed, skipped, failed, or unreachable. The distinction between ok and changed is not cosmetic: a changed result is what fires a handler via notify (restart the service only if the config actually changed), and a clean run that reports all ok is your proof the system has converged on the desired state. If a task you expect to be idempotent reports changed on every run, that is a bug in how you described the state (a common cause: a command with no changed_when, or a lineinfile whose regexp does not match the line it just wrote).

Check mode and diff mode are your safety net. Run any playbook with --check (-C) and most of these modules will predict what they would change without touching anything (a “dry run”); add --diff and copy/template/lineinfile/blockinfile will show you the exact before/after of the file. Make this a reflex: --check --diff before a real run tells you precisely what is about to happen. (A few modules cannot fully support check mode — for example unarchive may report a change it cannot verify without extracting — but the core file/package/service modules support it well.)

Key terms used throughout: FQCN (fully-qualified collection name, namespace.collection.module, e.g. ansible.builtin.copy); idempotent (safe to re-run; converges on a declared state); become (privilege escalation, usually to root, required by most of these system-changing modules); handler (a task run only when notified by a changed result); mode (Unix permission bits, octal or symbolic); and fact (auto-discovered data about the host, e.g. ansible_facts['os_family'], used to pick the right package manager).

Managing software: package, dnf & apt

Installing and removing software is task number one on almost every host. Ansible gives you a generic module that auto-selects the right package manager and several specific modules (dnf, apt, yum, zypper, pacman, apk…) that expose options unique to one manager.

ansible.builtin.package is the portable choice: it inspects ansible_facts['pkg_mgr'] and dispatches to the right backend (dnf on RHEL/Fedora, apt on Debian/Ubuntu, and so on). Use it when your only requirement is “ensure this package is in this state” and the package name is the same across the distros you target. The moment you need a manager-specific feature — update_cache with a cache validity window on apt, enablerepo on dnf, autoremove, GPG-key handling — reach for the specific module.

Idempotency rule. state: present/absent are fully idempotent — the module checks the package database and only acts if the package’s installed-ness does not match. state: latest is idempotent against the current newest version: it reports ok if you already have the newest, changed if it upgraded. The realistic, portable pattern that respects facts looks like this:

- name: Ensure the web server and tools are present
  ansible.builtin.package:
    name:
      - nginx
      - curl
      - vim
    state: present
  become: true

# Debian/Ubuntu: refresh the cache (cheaply) then install
- name: Install on apt systems with a cached index
  ansible.builtin.apt:
    name: nginx
    state: present
    update_cache: true
    cache_valid_time: 3600
  become: true
  when: ansible_facts['os_family'] == "Debian"

Managing services: service & systemd

A package installed is not a service running. Two modules manage daemons: ansible.builtin.service (generic — works across SysV init, systemd, BSD rc, etc. by detecting the init system) and ansible.builtin.systemd (systemd-specific, which is what virtually every modern Linux uses; exposes daemon_reload, masked, and unit scope). Use service for portability; use systemd when you need a systemd-only feature.

The single most important distinction here is state versus enabled, and beginners conflate them constantly:

• state controls the service right now (started, stopped, restarted, reloaded).
• enabled controls whether it starts on boot (yes/no) — it is the equivalent of systemctl enable/disable.

A service can be running now but disabled at boot, or enabled at boot but stopped now. Production tasks almost always want both state: started and enabled: true.

Idempotency rule. started/stopped/enabled converge on a state and report ok if already there. restarted/reloaded are actions, not states — they always run and always report changed. This is why the canonical pattern separates the config change (idempotent) from the restart (a handler, fired only on change):

- name: Ensure nginx is running now and on boot
  ansible.builtin.systemd:
    name: nginx
    state: started
    enabled: true
  become: true

# elsewhere: a config task that notifies, and a handler that restarts
- name: Deploy nginx config
  ansible.builtin.template:
    src: nginx.conf.j2
    dest: /etc/nginx/nginx.conf
    validate: nginx -t -c %s
  become: true
  notify: Restart nginx

# handlers:
#   - name: Restart nginx
#     ansible.builtin.systemd:
#       name: nginx
#       state: restarted
#     become: true

Delivering files: copy vs template vs file

This trio is the heart of configuration management, and choosing the right one is mostly about where the bytes come from:

• ansible.builtin.copy — put fixed bytes on the target: a static file from your control node (src), or literal inline content (content). No transformation.
• ansible.builtin.template — render a Jinja2 template (.j2) using your variables and facts, then write the result. Use this whenever the file content depends on anything (hostname, port, environment).
• ansible.builtin.file — do not deliver content at all; enforce the state of a path: create a directory, make a symlink, set ownership/permissions on something that already exists, or delete a path.

The rule of thumb: static file → copy; dynamic file → template; just a path’s existence/attributes/permissions → file.

copy

template

template takes all the file-attribute options of copy (dest, mode, owner, group, backup, validate, force) plus the rendering controls below. The source is a .j2 file (looked up in a role’s templates/ automatically).

A good template starts with the ansible_managed marker so humans know not to hand-edit it: # {{ ansible_managed }}.

file

Idempotency rules. copy/template are idempotent by content checksum (and attributes): if the rendered/source bytes and the mode/owner already match the target, the task reports ok; otherwise it writes and reports changed (and with --diff shows you the change). file is idempotent for file/directory/link/absent — it only acts if the path’s state or attributes differ — except state: touch, which always updates the timestamp and therefore always reports changed.

Surgical edits: lineinfile & blockinfile

Sometimes you do not own a whole file — it is managed by a package, or shared, and you only need to ensure one setting is present (or absent). Dropping a full template over such a file is brittle. Two modules edit in place:

• ansible.builtin.lineinfile — ensure a single line matches a state: present (optionally replacing a line that matches a regexp) or absent.
• ansible.builtin.blockinfile — manage a multi-line region delimited by auto-inserted # BEGIN/END ANSIBLE MANAGED BLOCK markers, so the whole block can be updated or removed as a unit.

The single biggest lineinfile gotcha: regexp finds the line to act on; line is what it becomes. If your regexp does not match the line you ultimately write, the task will append a duplicate on the next run and report changed forever. Write the regexp to match the key (e.g. ^PermitRootLogin) and the line to be the full desired line.

Idempotency rules. Both are idempotent provided your markers/regexp are stable: lineinfile re-checks whether a line matching the final state exists; blockinfile re-checks the content between its markers. The classic non-idempotent failure is a lineinfile whose regexp does not match its own line (duplicates accumulate), or a blockinfile whose block contains something that changes every run.

Accounts: user & group

ansible.builtin.group ensures a group exists (or not); ansible.builtin.user manages a user account end to end — shell, home, supplementary groups, password, and even SSH keys. Create groups before users that reference them.

To install a user’s authorized public key, prefer the dedicated ansible.posix.authorized_key module (FQCN, from the ansible.posix collection) over hand-editing ~/.ssh/authorized_keys — it is idempotent and supports exclusive, key_options, and removal.

Idempotency rules. user/group converge on the declared account state and report ok if nothing differs. The two re-run traps are: update_password: always with a password value (it may report changed each run depending on hashing — prefer on_create), and forgetting append: yes (so each run “corrects” the supplementary groups back to the listed set).

Moving files around: get_url, unarchive & fetch

The last three close the loop on getting bytes onto — and off — a host:

• ansible.builtin.get_url — download a file from an HTTP(S)/FTP URL to the managed node, with checksum verification.
• ansible.builtin.unarchive — unpack an archive on the managed node; it can pull the archive from the control node or download it from a URL in one step.
• ansible.builtin.fetch — the reverse direction: copy a file from the managed node back to the control node (e.g. gather logs or generated certs).

Idempotency note for unarchive: by itself it tends to report changed because it cannot cheaply diff every extracted file (and check mode is limited). Give it a creates: path (something the archive yields) so subsequent runs skip extraction and report ok. get_url with a checksum is genuinely idempotent — it skips the download when the target already matches.

Idempotency rule. fetch is idempotent by checksum — it only re-downloads if the control-node copy differs from the target’s file.

File modes: octal vs symbolic (and the YAML gotcha)

Every file/copy/template/get_url task can set mode, and getting it right matters for security. Linux permissions are three triads — owner, group, other — each with read (r=4), write (w=2), execute (x=1).

The single most common Ansible-beginner bug: writing mode: 0644 unquoted. YAML interprets a leading-zero integer differently from the octal you intended, and Ansible can apply the wrong permissions silently. Always quote octal modes — mode: '0644' — or use the unambiguous symbolic form mode: u=rw,g=r,o=r. Symbolic also supports relative changes (mode: u+x to add execute for the owner without restating the rest), which is handy for file tasks that adjust one bit.

Diagram

The diagram groups the core modules by job — install (package/dnf/apt), run (service/systemd), deliver (copy/template/file), edit in place (lineinfile/blockinfile), accounts (user/group) and transfer (get_url/unarchive/fetch) — and shows each acting on the managed node while reporting ok/changed back to the control node, the loop that makes idempotent convergence visible.

Hands-on lab

We will build a real, running web server with this exact toolkit — package install, a directory and a templated config, content, a service, a hardened sshd edit, an account, a downloaded file and a fetched log — entirely free. You have two ways to run it; pick one:

• Option A (recommended, zero cost, isolated): a local container as the managed node (Docker/Podman). We use a systemd-capable image so the service/systemd module works.
• Option B (also free): target localhost with connection: local and become: true. Only do this on a throwaway VM, because it really installs nginx and edits sshd on the machine running it.

0. Prerequisites check. On the control node confirm Ansible is present:

ansible --version        # ansible-core 2.17+ expected

1. (Option A) Start a systemd-capable container as the target.

# Podman or Docker; this image runs systemd as PID 1
docker run -d --name web1 --hostname web1 \
  --tmpfs /tmp --tmpfs /run -v /sys/fs/cgroup:/sys/fs/cgroup:ro \
  registry.access.redhat.com/ubi9/ubi-init:latest /sbin/init

Create an inventory inventory.ini that reaches the container through the Docker connection plugin (no SSH needed):

[web]
web1 ansible_connection=docker

(For Option B instead, use web1 ansible_connection=local ansible_host=localhost and run on a disposable VM.)

2. Create the project files. Make a folder ansible-webserver/ containing the inventory above, the template, the homepage, and the playbook.

nginx_index.html.j2 (a Jinja2 template so it shows facts):

{# This is rendered by ansible.builtin.template #}
<!doctype html>
<html>
  <head><title>Served by {{ inventory_hostname }}</title></head>
  <body>
    <h1>Hello from {{ inventory_hostname }}</h1>
    <p>OS family: {{ ansible_facts['os_family'] }} — managed by Ansible.</p>
  </body>
</html>

site.yml — the mini web-server playbook that exercises the whole toolkit:

---
- name: Configure a web server end to end
  hosts: web
  become: true

  vars:
    web_root: /usr/share/nginx/html
    app_user: webadmin

  tasks:
    # --- install (package) ---
    - name: Ensure nginx and tools are installed
      ansible.builtin.package:
        name:
          - nginx
          - curl
        state: present

    # --- account (group + user) ---
    - name: Ensure the web group exists
      ansible.builtin.group:
        name: web
        state: present

    - name: Ensure a non-login web admin user exists
      ansible.builtin.user:
        name: "{{ app_user }}"
        groups: web
        append: true
        shell: /usr/sbin/nologin
        create_home: true
        state: present

    # --- deliver (file: a dir; template: rendered config & homepage) ---
    - name: Ensure the document root exists
      ansible.builtin.file:
        path: "{{ web_root }}"
        state: directory
        owner: "{{ app_user }}"
        group: web
        mode: '0755'

    - name: Render the homepage from a template
      ansible.builtin.template:
        src: nginx_index.html.j2
        dest: "{{ web_root }}/index.html"
        owner: "{{ app_user }}"
        group: web
        mode: '0644'
        backup: true

    # --- deliver (copy: inline static content) ---
    - name: Drop a static health-check file (verbatim)
      ansible.builtin.copy:
        content: "ok\n"
        dest: "{{ web_root }}/health.txt"
        mode: '0644'

    # --- download (get_url) ---
    - name: Download a static asset with checksum verification
      ansible.builtin.get_url:
        url: https://raw.githubusercontent.com/torvalds/linux/master/README
        dest: "{{ web_root }}/README.txt"
        mode: '0644'
      # In a locked-down lab without egress, comment this task out.

    # --- surgical edit (lineinfile) on a file we do not own ---
    - name: Harden sshd — disable root login (validated)
      ansible.builtin.lineinfile:
        path: /etc/ssh/sshd_config
        regexp: '^#?PermitRootLogin'
        line: 'PermitRootLogin no'
        validate: 'sshd -t -f %s'
        backup: true
      notify: Restart sshd

    # --- run + enable (service) ---
    - name: Ensure nginx is started and enabled
      ansible.builtin.service:
        name: nginx
        state: started
        enabled: true

  handlers:
    - name: Restart sshd
      ansible.builtin.service:
        name: sshd
        state: restarted

3. Dry-run first (the safety reflex).

ansible-playbook -i inventory.ini site.yml --check --diff

Expected: every task shows what it would do; --diff prints the rendered index.html, the health.txt content, and the one-line change to sshd_config. Nothing is applied.

4. Apply for real.

ansible-playbook -i inventory.ini site.yml

Expected recap: a row of changed= for the first run. Read it — package install changed, the user/group changed, the directory and both files changed, the sshd line changed (and the handler Restart sshd runs once, at the end, because the line changed).

5. Validate it actually serves.

# From inside the container (Option A):
docker exec web1 curl -s localhost/health.txt          # -> ok
docker exec web1 curl -s localhost/ | grep "Hello from" # -> the templated homepage
docker exec web1 grep '^PermitRootLogin' /etc/ssh/sshd_config  # -> PermitRootLogin no
docker exec web1 id webadmin                            # -> shows the 'web' group
docker exec web1 systemctl is-enabled nginx             # -> enabled

6. Prove idempotency — run it again.

ansible-playbook -i inventory.ini site.yml

Expected: the recap now shows changed=0 (or close to it; get_url with a checksum and the rest all converge). The handler does not run, because no config changed. This ok-everywhere second run is the proof your playbook is idempotent — the single most important property to demonstrate in an interview.

7. Pull a file back (fetch).

# Append a fetch play, or run ad-hoc:
ansible -i inventory.ini web -b -m ansible.builtin.fetch \
  -a "src=/var/log/messages dest=./pulled/ flat=no"
ls -R pulled/   # -> pulled/web1/var/log/messages

8. Cleanup.

docker rm -f web1            # Option A: removes the whole target — nothing left behind
rm -rf ./pulled              # remove fetched files

For Option B (you targeted a real VM), reverse the changes by setting state: absent/stopped or simply discard the throwaway VM. Cost note: the entire lab runs on your machine — a local container or VM and Ansible itself — so the cost is ₹0. No cloud resources are created.

Common mistakes & troubleshooting

Best practices

• Prefer the purpose-built module over command/shell. If a module exists for the job (it almost always does), use it — you get idempotency, check mode and diff for free. Drop to command/shell only as a last resort, and then add creates/removes/changed_when to restore idempotency.
• Use FQCN everywhere (ansible.builtin.copy, not copy). It is unambiguous, lint-clean, and future-proofs you against short-name collisions between collections.
• Always quote octal modes and reach for symbolic when adjusting a single bit. Set the least permission that works — '0600' for secrets on disk.
• Make the second run prove itself. A correct playbook reports changed=0 on a no-op re-run. Run --check --diff before applying and re-run after applying to confirm convergence.
• Separate “change the config” from “restart the service.” The config task is idempotent and notify:s a handler; the handler does the (non-idempotent) restart only when something actually changed, once, at the end of the play.
• Validate before you install (validate:) and back up before you overwrite (backup:) on every task that touches an existing, load-bearing file (sshd_config, sudoers, nginx.conf).
• Install lists, not loops. package: name: [a, b, c] is one transaction; a loop over packages is N transactions and far slower.
• Pin where reproducibility matters. Use state: present (not latest) and explicit versions for deterministic builds; reserve latest for hosts you intend to roll forward.
• Reach for lineinfile/blockinfile only on files you partly own; for files you fully control, a template is clearer and atomically correct.

Security notes

These modules are your security posture on a host, so a few rules carry weight. File modes and ownership are the front line: lay secrets down as '0600' owned by the right user, document roots as '0644'/'0755', and never world-write a config — a stray '0666' from an unquoted mode is a real vulnerability. Never put a plaintext password in user: password: — it expects a hash; pass "{{ 'S3cret' | password_hash('sha512') }}" and keep the source vaulted, and prefer update_password: on_create so you are not rewriting /etc/shadow on every run. Keep TLS and signature verification on: get_url’s validate_certs: true and dnf/apt’s GPG checks default to secure for a reason — disable them only for trusted internal sources, never as a blanket workaround. validate: is a security control, not just a convenience: validating sshd_config (sshd -t -f %s) or sudoers (visudo -cf %s) before installation prevents a templating mistake from locking you out or escalating privilege. When you download-and-extract with unarchive from a URL, verify the source (pin the URL, supply a checksum to get_url and extract the verified file) rather than piping arbitrary internet bytes into tar. Finally, become only where needed — these tasks need root, but scope become: true to the play or the specific tasks that require it rather than leaving it on globally where a templating bug could write somewhere sensitive.

Interview & exam questions

1. What is idempotency, and which two core modules are not idempotent by default? Idempotency means re-running a task already in the desired state changes nothing and reports ok. Modules declare a desired state and only act if reality differs. ansible.builtin.command and ansible.builtin.shell are not idempotent — they run their command every time — which is why you prefer purpose-built modules or add creates/removes/changed_when.

2. In the service/systemd module, what is the difference between state and enabled? state controls the service right now (started/stopped/restarted/reloaded); enabled controls whether it starts on boot (yes/no). They are independent — a service can be running now but disabled at boot, or vice versa. Production usually wants both state: started and enabled: true.

3. When do you need daemon_reload: true? After you add or change a systemd unit file (e.g. you templated a new .service). Without daemon-reload, systemd has not re-read the unit, so a started/restarted may act on the old definition.

4. copy vs template vs file — when each? copy puts fixed bytes (a static src or inline content) on the target with no transformation. template renders a Jinja2 .j2 using variables/facts, then writes the result — use it whenever content depends on anything. file delivers no content; it enforces a path’s state (directory/link/touch/absent) and attributes (mode/owner/group).

5. Why might a lineinfile task be changed on every run, and how do you fix it? Because its regexp does not match the line it writes, so on the next run Ansible doesn’t recognise its own line and appends a duplicate. Fix: anchor regexp to the directive key (^PermitRootLogin) so it matches the line line produces.

6. How do you restart a service only when its config changed? Put the restart in a handler and notify: it from the config task. The config task is idempotent (reports changed only on a real change), and a handler runs once at the end of the play, only if notified. Using state: restarted directly in a task restarts on every run.

7. What is the mode: 0644 (unquoted) gotcha? YAML parses a leading-zero integer in a way that does not match the octal you intended, so Ansible can apply the wrong permissions silently. Always quote octal ('0644') or use symbolic (u=rw,g=r,o=r).

8. In the user module, what does append default to and why does it matter? append defaults to no, which means groups: sets the user’s exact supplementary group list — removing them from any group not listed. Use append: true to add a user to a group (e.g. wheel/sudo) without clobbering their other memberships.

9. How should a password be supplied to the user module? As an already-computed hash (e.g. "{{ 'pw' | password_hash('sha512') }}" or mkpasswd --method=sha-512), stored vaulted — never plaintext, which would set a literally-wrong hash. Prefer update_password: on_create to avoid rewriting /etc/shadow each run.

10. How do you make unarchive idempotent, and how is that different from get_url? Give unarchive a creates: path (a file the archive produces) so re-runs skip extraction. get_url is idempotent natively when you supply a checksum: — it skips the download if the target file already matches.

11. What does fetch do, and how does it avoid filename collisions across hosts? fetch copies a file from the managed node back to the control node (the reverse of copy). By default it nests the file under dest/<hostname>/<src-path>, so the same file pulled from many hosts does not overwrite. flat: yes disables the nesting.

12. What is the purpose of the validate: option, and give two real uses? validate: runs a command (with %s as the temp file) to check the file before it is installed; a non-zero exit fails the task and nothing is written. Real uses: validate: 'sshd -t -f %s' for sshd_config and validate: 'visudo -cf %s' for sudoers — preventing a broken config from being deployed.

13. Why prefer package sometimes and dnf/apt other times? package is portable — it auto-selects the host’s package manager via facts — so use it when the package name is the same across distros and you need no manager-specific feature. Use dnf/apt when you need features unique to one manager (update_cache/cache_valid_time, enablerepo, autoremove, deb).

Quick check

1. Which option makes unarchive idempotent by skipping extraction when a path already exists?
2. True or false: mode: 0755 and mode: '0755' are equivalent in a YAML playbook.
3. You need a config change to trigger a service restart only when it actually changes. What mechanism do you use?
4. Which module copies a file from the managed node to the control node?
5. In the user module, what must you add so that groups: adds memberships instead of replacing them?

Answers

1. creates: — set it to a path the archive produces; subsequent runs report ok instead of changed.
2. False. Unquoted 0755 can be mis-parsed by YAML and apply the wrong bits; always quote octal modes (or use symbolic form).
3. A handler plus notify: — the idempotent config task notifies a handler that does the restart, which runs once at the end of the play only if something changed. (Do not use state: restarted directly in the task.)
4. ansible.builtin.fetch — the reverse of copy; it pulls a file back to the control node (nesting it under the hostname by default).
5. append: true — without it, groups: sets the exact supplementary-group list and removes the user from any group not listed.

Exercise

Extend the lab’s site.yml into a more production-shaped web role-in-a-playbook:

1. Replace the inline copy health file with a templated health.json (ansible.builtin.template) that includes {{ ansible_facts['hostname'] }} and a {{ ansible_managed }} header comment, with mode: '0644'.
2. Add a blockinfile task that manages a custom # BEGIN/END ANSIBLE MANAGED BLOCK region in a file under /etc/, with validate: where the file type supports it, and prove with --diff that it is added on the first run and unchanged on the second.
3. Create the web admin user’s SSH key with the user module’s generate_ssh_key: true (and ssh_key_type: ed25519), then use ansible.builtin.fetch to pull the generated public key (~webadmin/.ssh/id_ed25519.pub) back to your control node.
4. Download a release tarball with get_url with a checksum:, then unarchive it (remote_src: true, a creates: path, and extra_opts: ['--strip-components=1']) into a directory you first ensure exists with file: state=directory.
5. Convert the nginx restart to a proper handler notified by the template task, and demonstrate that editing the template fires exactly one restart while a no-op run fires none.

Write two or three sentences explaining which tasks reported changed on your second run and why each one did or did not — the ability to reason about ok vs changed per module is the core skill this lesson builds.

Certification mapping

This lesson maps to the Red Hat Certified Engineer (RHCE), exam EX294 — “Use Ansible modules for system administration tasks” and “Create and use templates to create customised configuration files.” Specifically it covers: software management with package/dnf/apt (state present/latest/absent, update_cache); service management with service/systemd (state vs enabled, daemon_reload); delivering files with copy (src/content, validate, backup), template (Jinja2 rendering, trim_blocks/lstrip_blocks, ansible_managed) and file (directory/link/touch/absent, recurse); editing with lineinfile and blockinfile (regexp, insertafter, validate); user and group administration with user (groups/append, shell, hashed password, SSH keys, system accounts) and group; and file transfer with get_url (checksum), unarchive (creates, extra_opts) and fetch. The EX294 exam is hands-on and explicitly tests idempotency, correct mode handling, and using validate/backup on edited config files — all drilled above. The same modules underpin Ansible work in the broader DevOps and Red Hat administration tracks.

Glossary

• Module — A small, idempotent program shipped to and run on the managed node; reports a JSON result (changed, rc, module-specific keys).
• FQCN — Fully-qualified collection name, namespace.collection.module (e.g. ansible.builtin.copy); the unambiguous modern way to name modules.
• Idempotent — Safe to re-run: the module converges on a declared state and reports ok when reality already matches, changed when it had to act.
• changed vs ok — The two convergence statuses; changed is what fires a handler via notify, and an all-ok re-run proves convergence.
• Handler — A task that runs only when a changed task notify:s it, once at the end of the play; used for restarts/reloads.
• become — Privilege escalation (usually to root) required by most system-changing modules.
• state (service) — The runtime state to enforce now: started/stopped/restarted/reloaded.
• enabled (service) — Whether the service starts at boot, independent of state.
• daemon_reload — Re-read systemd unit files (systemctl daemon-reload); needed after adding/changing a unit.
• copy — Deliver fixed bytes (src file or inline content) verbatim.
• template — Render a Jinja2 .j2 with variables/facts, then write the result.
• file — Enforce a path’s state (file/directory/link/touch/absent) and attributes (mode/owner/group); no content.
• lineinfile / blockinfile — Idempotent in-place editing of a single line / a marker-delimited managed region.
• mode — Unix permission bits, written octal (quoted, '0644') or symbolic (u=rw,g=r,o=r).
• validate — A command (with %s for the temp file) that must succeed before a file is installed; a safety/security gate.
• backup — Save a timestamped copy before overwriting/editing, enabling rollback.
• append (user) — Add supplementary groups rather than replacing the whole list (default no).
• creates — A path whose existence makes unarchive/command skip its action — the idempotency lever for those.
• get_url / unarchive / fetch — Download to the target / unpack on the target / pull a file back to the control node.
• ansible_managed — A configurable marker string you put in templated files so humans know not to hand-edit them.

Next steps

You now command the day-one module toolkit — installing software, running services, delivering and editing files, managing accounts, and moving bytes on and off a host, all idempotently. Every option here becomes far more powerful once it can react to data, so the natural next move is the data layer. Continue with Ansible Variables & Facts, In Depth: the 22-Level Precedence, Facts, register & set_fact, which explains where variables come from and in what order they win, how to capture a task’s result with register, and how facts feed the when conditions and templates that make these modules adapt per host. And to go deeper on the rendering engine behind the template module — filters, tests, loops and lookups — see Ansible Jinja2 Templating, In Depth: the template Module, Filters, Tests & Lookups.