🧱Module 01 — Fundamentals, Connectivity & Your First Playbook

An open-source automation engine used for configuration management, application deployment, and orchestration. It is agentless, connecting over SSH (Linux) or WinRM (Windows), and is driven by YAML playbooks.

Strong close: "It covers provisioning, config management and orchestration in one tool, which is why teams reach for it instead of maintaining a pile of shell scripts."

No agent or special software is installed on the managed nodes. The control node opens an SSH connection, copies a self-contained Python module into a temporary directory, executes it with the target's own Python interpreter, reads the JSON result, and deletes the temp directory.

The operational argument to voice: nothing to install, patch, monitor or CVE-track across thousands of nodes, and no inbound port beyond SSH, which is already open.

Puppet and Chef are pull-based and agent-based: an agent on each node polls a master roughly every 30 minutes and re-applies state. Ansible is push-based and agentless.

Pick Puppet/Chef when you need continuous drift correction with no central scheduler, or at a scale where pushing to tens of thousands of nodes becomes the bottleneck.

Pick Ansible for orchestration, network devices, ad-hoc operations, and a far lower onboarding cost.

Terraform is declarative provisioning with state — it creates infrastructure and records it in a state file, so it can compute a diff and destroy cleanly.

Ansible is configuration management — it configures things that already exist and keeps no state file.

The common production pattern: Terraform provisions, Ansible configures, joined by dynamic inventory. Ansible can create cloud resources, but with no state it cannot reliably destroy them or detect orphans.

Linux — SSH, and the target needs Python.

Windows — WinRM or PSRP, with PowerShell-based modules; no Python needed on the target.

Network devices — connection: network_cli or httpapi, no Python on the device at all.

Bonus: the control node itself must be Linux, macOS or WSL2 — never native Windows.

ansible [core 2.16.3]
  config file = None
  configured module search path = ['/home/zaeem/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/lib/python3/dist-packages/ansible
  ansible collection location = /home/zaeem/.ansible/collections:/usr/share/ansible/collections
  executable location = /usr/bin/ansible
  python version = 3.11.2 (main, ...) [GCC 12.2.0]
  jinja version = 3.1.2
  libyaml = True

Three lines are worth understanding right now:

• core 2.16.3 — the engine version. Modules come and go between versions, so this is the first thing you check when documentation and reality disagree.
• config file = None — you have not created a configuration file yet. That is expected and fine; we cover configuration in Part C once you have felt the need for it.
• python version — this is the control node's Python. The managed nodes use their own, which can be a different version entirely.

exit code: 1
Python 3.11.2

which ansible found nothing and returned exit code 1 — Ansible is absent from the target, exactly as designed. But Python is there, which is the only real dependency.

This is the entire agentless model demonstrated in two commands. Keep it in mind for the rest of the module: everything you write lives on the control node, and nothing is ever permanently installed on the targets.

On the control node only. Managed nodes need nothing installed for Ansible's sake — just an SSH daemon and Python, both of which a normal Linux server already has.

ansible-core is the engine plus ansible.builtin modules. The ansible package is that engine bundled with a large set of community collections.

Production preference: install ansible-core and pin the collections you need in requirements.yml, so a collection upgrade is a deliberate act rather than a side effect of a package update.

SSH access and Python 3. That is the whole list.

For a bare host with no Python at all, bootstrap it using the raw module, which sends a literal SSH command and therefore needs no Python. Windows targets need WinRM and PowerShell instead, and network devices need neither.

On a minimal ansible-core install:

# /usr/lib/python3/dist-packages/ansible_collections
Collection        Version
----------------- -------
ansible.builtin   2.16.3

On a full ansible package install you will instead see dozens of lines:

Collection                    Version
----------------------------- -------
amazon.aws                    7.2.0
ansible.builtin               2.16.3
ansible.posix                 1.5.4
community.docker              3.5.0
community.general             8.3.0
kubernetes.core               3.0.0
...

This is the practical difference between ansible-core and ansible that Part A3 described — now visible as a list. If amazon.aws does not appear here, then amazon.aws.ec2_instance will fail with "couldn't resolve module/action", and the fix is ansible-galaxy collection install amazon.aws, not a change to your playbook.

For a real project, pin them in a requirements.yml instead of installing ad-hoc:

---
collections:
  - name: amazon.aws
    version: "7.2.0"
  - name: community.docker
    version: "3.5.0"

ansible-galaxy collection install -r requirements.yml

That file is what makes a playbook reproducible on someone else's machine and in CI — without it, a teammate installing today gets different collection versions than you did, and the playbook breaks for reasons that look like magic.

Fully Qualified Collection Name — namespace.collection.module, for example ansible.builtin.copy or amazon.aws.ec2_instance.

It exists because Ansible 2.10 split the monolithic package into ansible-core plus independently versioned collections. Once modules can come from hundreds of sources, flat names are no longer unique, so the FQCN removes the ambiguity.

Not removed, and still functional — unqualified names resolve through ansible.legacy. But FQCN is the recommended style, ansible-lint flags short names via its fqcn rule, and any team with CI will expect the long form.

The real argument is collision safety: with a short name, which module you get depends on collection search order, and that changes when someone installs a new collection.

ansible.builtin is strictly the module shipped in ansible-core — nothing can override it.

ansible.legacy is core's version plus any local library/ override in your project, and it is what unqualified names resolve to.

That is precisely the mechanism that lets a custom module in library/ shadow a builtin one — useful when you need to patch a core module's behaviour without forking Ansible.

Collection — a versioned, distributable package of Ansible content: modules, plugins, roles and playbooks, with its own dependencies.

Namespace — the owner prefix on a collection name, reserved on Galaxy so two vendors cannot both publish aws. Like a GitHub org or an npm scope.

Ansible Galaxy — the public registry those collections are published to and downloaded from, and the name of the ansible-galaxy CLI.

So amazon.aws is the collection aws, published under the amazon namespace, obtained from Galaxy. The analogy that lands: collection is to Galaxy as package is to PyPI, and ansible-galaxy is pip.

A role is the older unit: tasks, handlers, templates, files and defaults packaged for one job. It cannot contain modules or plugins.

A collection is the modern unit and a superset: it can contain modules, plugins, roles and playbooks together, is versioned, and can declare dependencies on other collections.

One line: a collection can contain roles; a role cannot contain a collection. Roles are not deprecated — collections are the packaging and distribution format around them.

Galaxy is the free public registry, open to anyone, community-maintained with no support contract.

Red Hat Automation Hub carries certified collections that are tested and supported under an Ansible Automation Platform subscription.

Private Automation Hub is the self-hosted version, which is what regulated environments actually use — you mirror vetted collection versions internally, point ansible.cfg at it with galaxy_server_list, and production never pulls from the public internet at run time.

A requirements.yml with pinned versions, installed via ansible-galaxy collection install -r requirements.yml, committed to the repository and installed as a step in CI.

Without pinning, a teammate or a CI runner installing next month gets different collection versions than you did, and the playbook breaks for reasons that look inexplicable. It is the same discipline as a lockfile in any other ecosystem.

@all:
  |--@prod:
  |  |--@web:
  |  |  |--web01
  |  |  |--web02
  |  |  |--web03
  |  |--@db:
  |  |  |--db01
  |--@staging:
  |  |--stg01
  |--@ungrouped:

hosts (3):
  web01
  web02
  web03

hosts (2):
  web02
  web03

hosts (3):
  web01
  web02
  web03

Two things to take away. First, --graph renders the nesting and is the fastest way to sanity-check a children: structure you have just written.

Second, prod:&web returned all three web hosts. That surprises people — but web sits inside prod, so every web host is also a prod host. Group membership is inherited downward, and that subtlety is exactly what an interviewer probes when they ask about intersections.

Notice you had to type -i inventory/hosts.yml four times. Hold that irritation — Part C fixes it.

hosts (2):
  web01
  web03

Patterns compose left to right: start with prod, intersect with web, then subtract web02.

Make this a reflex. --list-hosts costs nothing, connects to nothing, and changes nothing. Running it before any destructive command is the single cheapest habit in Ansible operations, and saying "I always dry-run the host pattern first" in an interview signals that you have actually operated this tool rather than only studied it.

The list of managed nodes Ansible targets, plus their grouping and connection variables. It can be INI or YAML, and it supports groups, nested groups via children, and both group-level and host-level variables.

The default location is /etc/ansible/hosts, overridden with -i on the command line or the inventory setting in ansible.cfg.

Static is a file you maintain by hand — fine for a small, stable estate.

Dynamic uses an inventory plugin that queries the real source of truth at runtime (AWS, Azure, VMware, a CMDB), so the host list can never go stale.

The clinching argument: the moment autoscaling exists, a static file is wrong within minutes. Anything cloud-based should be dynamic, with keyed_groups mapping instance tags to Ansible groups. (Covered fully in Module 09.)

web:db is union — hosts in web or db.

web:&db is intersection — hosts in web and db.

web:!db is exclusion — hosts in web that are not in db.

They compose, so prod:&web:!web01 means "in prod and in web, except web01". Patterns work identically in ad-hoc commands, in --limit, and in the hosts: line of a play.

all (every host), ungrouped (hosts in no group), and localhost (always available and implicitly local-connection — which is why hosts: localhost works even with a completely empty inventory).

ansible-inventory -i <file> --graph for the group tree, --list for the full JSON including every resolved variable, and ansible <pattern> --list-hosts to confirm a pattern selects what you expect before running anything against it.

Step 1:

Generating public/private ed25519 key pair.
Enter passphrase (empty for no passphrase):
Your identification has been saved in /home/zaeem/.ssh/ansible_ed25519
Your public key has been saved in /home/zaeem/.ssh/ansible_ed25519.pub
The key fingerprint is:
SHA256:xR3k9... ansible-control-node

Step 2 — note the permissions, they matter:

-rw-------  1 zaeem zaeem  399 Aug 14 10:22 /home/zaeem/.ssh/ansible_ed25519
-rw-r--r--  1 zaeem zaeem   96 Aug 14 10:22 /home/zaeem/.ssh/ansible_ed25519.pub

The private key is 0600 — readable only by you. If it is any more permissive, SSH refuses to use it entirely and prints "UNPROTECTED PRIVATE KEY FILE". This trips up people who copy keys around with a careless cp.

Step 3:

/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s)...
[email protected]'s password:
Number of key(s) added: 1

Step 4 — no password prompt:

web01

What ssh-copy-id actually did: it appended the contents of your .pub file to ~/.ssh/authorized_keys on the target, and set the permissions correctly (700 on ~/.ssh, 600 on the file). You could do it by hand, but people routinely get the permissions wrong and then spend an hour debugging — sshd silently ignores an authorized_keys file with loose permissions.

web01 | SUCCESS => {
    "changed": false,
    "ping": "pong"
}
web02 | SUCCESS => {
    "changed": false,
    "ping": "pong"
}

The connection variables you just used, and the rest of the family:

• ansible_host — the real IP or DNS name. The inventory name (web01) becomes just a friendly label, which is what lets you write readable playbooks against IP-addressed servers.
• ansible_user — the account to log in as
• ansible_ssh_private_key_file — which private key to present
• ansible_port — non-standard SSH port
• ansible_connection — ssh (default), local, winrm, docker, network_cli
• ansible_python_interpreter — override when the target has Python somewhere unusual

Through standard OpenSSH — either password authentication (which needs sshpass and the -k flag) or, in any real environment, SSH public key authentication.

The rule to state plainly: if plain ssh user@host does not work from the control node, Ansible cannot work either. Ansible adds no authentication layer of its own.

The private key never leaves the control node — the server only receives a signature it verifies against the stored public key, so no secret crosses the wire.

It works unattended, which is what makes CI/CD and scheduled runs possible at all. It is revocable per host by editing authorized_keys, and it leaves an auditable trail of which key was used.

Password auth requires sshpass, means storing a plaintext credential somewhere, and cannot be rotated cleanly.

1. Reproduce with plain SSH first — ssh -vvv user@host. The native client gives a much better error than Ansible does.
2. Check the obvious layer: is the host up, is port 22 reachable, is DNS resolving, is a security group or firewall in the way.
3. Check identity: right ansible_user, right key, and is the public key actually in the target's authorized_keys.
4. Check permissions — ~/.ssh must be 700, authorized_keys 600, private key 600. sshd silently ignores files that are too permissive, which produces a confusing "denied" with no explanation.
5. Check host key verification — a rebuilt server with a new host key fails until known_hosts is updated.
6. Then, and only then, run ansible ... -vvv to see the exact SSH command Ansible constructed.

Say this out loud: UNREACHABLE means the module never ran at all, so it is never a playbook bug.

In Ansible Vault, encrypted at rest and decrypted at run time with a vault password supplied by CI or a password file outside the repository. Never in plaintext in the inventory, never in Git.

Better still, avoid the question: use key auth with ssh-agent holding the passphrase, or on cloud infrastructure skip SSH keys entirely and use AWS SSM Session Manager, which authenticates through IAM and leaves no key to manage.

zaeem
HOME=/home/zaeem

web01 | CHANGED | rc=0 >>
deploy

web01 | CHANGED | rc=0 >>
root

IdentityFile="/home/zaeem/.ssh/ansible_ed25519"

All three identities, visible at once. You are zaeem locally, Ansible logs in as deploy, and tasks execute as root after become. The key came from /home/zaeem/.ssh/ — the local user's home.

That last grep is worth committing to memory. When authentication fails, -vvv plus grep IdentityFile tells you immediately whether Ansible even reached for the key you think it did — which instantly separates "wrong key" from "key not installed on the target".

web01 | SUCCESS => {"changed": false, "ping": "pong"}

web01 | UNREACHABLE! => {
    "changed": false,
    "msg": "Failed to connect to the host via ssh: [email protected]: Permission denied (publickey).",
    "unreachable": true
}

Nothing about the key changed. Nothing about the server changed. The only difference is that sudo set $HOME=/root, so Ansible looked in /root/.ssh/ — where your key does not exist. Confirm it:

sudo ansible web01 -m ansible.builtin.ping -vvv 2>&1 | grep -o 'IdentityFile=[^]*'
# IdentityFile="/root/.ssh/id_rsa"     <- not your key at all

The rule to carry away: never sudo the ansible or ansible-playbook command. Root on the control node buys you nothing — Ansible only needs to read your files and open an SSH connection, both of which your own account can already do. When you need root, you need it on the target, and become: true is how you get it.

The same trap in CI: a pipeline that runs as gitlab-runner or jenkins reads that user's ~/.ssh. "It works on my laptop but fails in the pipeline" is nearly always this, and the fix is to load the key into the job's own user — usually via ssh-agent seeded from a CI secret.

The remote user, resolved in this priority order: -u on the command line, then ansible_user on the host, then ansible_user on the group, then remote_user in ansible.cfg, then ANSIBLE_REMOTE_USER, then the User directive in ~/.ssh/config, and finally — if nothing is set — the local username of whoever is running the command.

That last fallback is a common source of confusing failures, so set it explicitly.

sudo changed $HOME to /root, so Ansible read /root/.ssh/ instead of your own ~/.ssh/, and your key was never offered.

The underlying misconception is thinking Ansible needs root on the control node. It does not — it only reads local files and opens an SSH connection. Root is needed on the managed node, and become: true provides it.

The same mechanism explains "works on my laptop, fails in CI": the runner executes as a different local user with a different home directory.

Local user — whoever runs ansible on the control node. Determines which ~/.ssh, ~/.ansible.cfg and collections are used. Never declared; it is just your login.

remote_user — the account Ansible logs into on the managed node. Must exist there, and your public key must be in its authorized_keys.

become_user — who tasks run as after escalation, default root. Requires the remote user to hold a sudoers rule on that host.

Set ansible_user per host or per group in the inventory — group vars for the common case, host vars for exceptions. ansible_ssh_private_key_file can vary the same way when the estate has several key pairs.

The cleaner long-term answer is to standardise on one automation service account across the estate, created at image-build time, so the inventory does not have to encode historical accidents.

SSH and authentication succeeded — this failure is at the escalation stage, not the connection stage. The remote user has no passwordless sudo rule on that host.

Fix by supplying -K to prompt for it, or by deploying /etc/sudoers.d/<user> with NOPASSWD:ALL — using validate: visudo -cf %s, because a malformed sudoers file locks everyone out of sudo on that machine.

On the control node the private key must be 0600 — anything looser and SSH refuses to use it, printing UNPROTECTED PRIVATE KEY FILE.

On the managed node the remote user's home must be no more permissive than 755, ~/.ssh must be 700, and authorized_keys 600.

The silence is deliberate: sshd will not tell a remote party why it rejected them, since that would leak information to an attacker. So it just says Permission denied (publickey). To see the real reason you must read /var/log/auth.log or journalctl -u sshd on the server, which is exactly what a strong troubleshooting answer mentions.

myserver | SUCCESS => {
    "changed": false,
    "ping": "pong"
}

Look at how little the inventory contained — one word. No IP, no user, no key path. Ansible shelled out to ssh myserver, and OpenSSH resolved the alias, the hostname, the user and the key from ~/.ssh/config.

When this is the right tool: jump hosts and bastions. Putting ProxyJump bastion in ~/.ssh/config is far cleaner than threading ansible_ssh_common_args through your inventory, and it keeps working when you SSH manually too.

When it is the wrong tool: anything a teammate or CI runner also needs. ~/.ssh/config lives on one laptop and is invisible to everyone else. Shared connection details belong in the inventory, which is in Git. Knowing which to use for which case is the senior answer.

You do not distribute them after the fact — you make sure the key is present before the machine is reachable. Inject it via cloud-init/user-data, bake it into a golden image with Packer, or let Terraform's key_name install it at instance creation.

For an existing estate you cannot rebuild, run a one-time bootstrap playbook using password auth that creates the service account, installs the key with the authorized_key module, and configures sudoers. Every run after that is key-based.

At cloud scale the better answer is to remove keys from the picture entirely — AWS SSM Session Manager authenticates through IAM, so there is nothing to distribute or rotate.

Through a bastion / jump host. Either ProxyJump bastion in ~/.ssh/config, or in the inventory:

ansible_ssh_common_args: '-o ProxyCommand="ssh -W %h:%p -q deploy@bastion"'

Alternatives worth naming: run the control node inside the VPC (a CI runner or AWX instance on a private subnet), or use SSM which needs no inbound network path at all.

ssh-agent — load the key once with ssh-add and the agent serves it for the session without re-prompting. In CI, start an agent in the job and add the key from a secret store.

Cleaner alternatives: a dedicated passphrase-less deploy key with tightly scoped permissions and a short lifetime, or short-lived SSH certificates from a CA such as HashiCorp Vault, which expire automatically and remove the rotation problem entirely.

Yes — Ansible shells out to the system ssh binary, so host aliases, ProxyJump, IdentityFile, and ControlMaster multiplexing all apply automatically.

The caveat worth adding: ~/.ssh/config is per-user and per-machine, so it is invisible to teammates and CI runners. Use it for your own convenience; put anything the team depends on in the inventory, which is version-controlled.

web01 | CHANGED | rc=0 >>
uid=1001(deploy) gid=1001(deploy) groups=1001(deploy)

web01 | CHANGED | rc=0 >>
uid=0(root) gid=0(root) groups=0(root)

web01 | FAILED | rc=1 >>
cat: /etc/shadow: Permission denied

web01 | CHANGED | rc=0 >>
root:$6$xyz...:19700:0:99999:7:::

Read the progression. You log in as deploy — an unprivileged account. --become runs sudo on the target and the same command now executes as uid=0. Ansible never logs in as root directly.

Why this design matters, and it is worth stating in an interview: permitting direct root SSH login is a standard compliance finding in any audited environment. The accepted pattern is to log in as a named, unprivileged service account — which produces an audit trail of who connected — and escalate through sudo, which is separately logged. become is Ansible honouring that convention rather than working around it.

Also note the FAILED above is genuinely different from UNREACHABLE: the connection succeeded and the module ran; it was the command that was denied.

remote_user (or -u) is the account you log in as over SSH. become is privilege escalation after login, by default sudo to root.

Related keys: become_method (sudo, su, doas, runas for Windows), become_user (the target identity, default root), and -K when sudo itself needs a password.

The best-practice statement: log in as an unprivileged service account and escalate via become, rather than permitting root SSH — direct root login is a standard audit finding.

-k prompts for the SSH login password. -K prompts for the sudo/become password. They are different credentials for different stages of the connection, and a run may legitimately need both.

Grant the service account passwordless sudo through a file in /etc/sudoers.d/, deployed by Ansible itself with validate: visudo -cf %s so a malformed file can never be written.

Scope it as tightly as the environment demands — full NOPASSWD:ALL is common for a dedicated automation account, but a hardened environment restricts it to specific command paths.

Never the alternative of storing the sudo password in plaintext; if you truly need one, it goes in Vault.

web01 | SUCCESS => {"changed": false, "ping": "pong"}
web02 | UNREACHABLE!: Failed to connect to the host via ssh: [email protected]: Permission denied (publickey).
db01  | UNREACHABLE!: Failed to connect to the host via ssh: ssh: connect to host 10.0.2.11 port 22: Connection timed out
stg01 | FAILED! => {"msg": "The module failed to execute correctly, you probably need to set the interpreter"}

Four different outcomes, four different root causes:

• SUCCESS — network, auth and Python all confirmed working.
• Permission denied (publickey) — the network path is fine, sshd answered. Your public key is not in that host's authorized_keys, or the wrong ansible_user is set, or the permissions on ~/.ssh are too loose for sshd to trust the file.
• Connection timed out — nothing answered at all. Host down, wrong IP, security group or firewall blocking port 22, or no route from the control node into that subnet. Not an Ansible problem in any sense.
• FAILED with an interpreter message — SSH and auth succeeded; the module ran and could not find a usable Python. Fix with ansible_python_interpreter: /usr/bin/python3.11, or bootstrap Python using the raw module.

Internalise the distinction: UNREACHABLE means the module never executed — debug at the network or auth layer. FAILED means it executed and returned an error — debug the target's state or your arguments. Confusing the two sends people down hour-long dead ends.

It is not ICMP. It opens an SSH connection, pushes the ping module, executes it with the remote Python interpreter, and expects {"ping": "pong"} in return.

It is therefore a single combined test of three things: network/SSH reachability, authentication, and a working Python on the target.

UNREACHABLE — the connection could not be established. SSH refused, wrong key, DNS failure, firewall, host down. The module never executed, and the host is dropped from the remainder of the play.

FAILED — the connection worked and the module ran, but returned an error result.

The practical consequence: unreachable hosts are debugged at the infrastructure layer, failed hosts at the playbook or target-state layer.

Bootstrap it with the raw module, which sends a literal SSH command and requires no Python:

- raw: apt-get update && apt-get install -y python3

Then run everything else normally. raw and script are the only modules that work without Python on the target — which is also why raw is what you use on stripped-down appliances and network gear.

• raw — sends a literal SSH command. No Python, no temp file, no JSON. Used to bootstrap Python onto a bare host.
• script — copies a local script to the target and runs it.
• shell / command — still use the Python wrapper, but are not idempotent by themselves.
• connection: local or delegate_to: localhost — executes on the control node instead. Every cloud module works this way: amazon.aws.ec2_instance, community.docker.*, uri. They talk to an API, so there is no target to SSH into.

<web01> ESTABLISH SSH CONNECTION FOR USER: deploy
<web01> SSH: EXEC ssh -o ControlMaster=auto -o ControlPersist=60s -o 'IdentityFile="/home/zaeem/.ssh/ansible_ed25519"' -o User=deploy 10.0.1.15 '/bin/sh -c ...'
<web01> EXEC /bin/sh -c 'echo ~deploy && sleep 0'
<web01> EXEC /bin/sh -c '( umask 77 && mkdir -p "` echo /home/deploy/.ansible/tmp `"&& mkdir "` echo /home/deploy/.ansible/tmp/ansible-tmp-1755166234.12-8891-273 `" ...'
<web01> EXEC /bin/sh -c '/usr/bin/python3 /home/deploy/.ansible/tmp/ansible-tmp-1755166234.12-8891-273/AnsiballZ_ping.py && sleep 0'
<web01> EXEC /bin/sh -c 'rm -f -r /home/deploy/.ansible/tmp/ansible-tmp-1755166234.12-8891-273/ > /dev/null 2>&1 && sleep 0'

Map each line onto the diagram above:

1. ESTABLISH SSH CONNECTION → step 4
2. SSH: EXEC ssh -o ControlMaster=auto... → step 4, and note it shows you the exact ssh command Ansible built, including which key it chose. When authentication misbehaves, this line is the answer.
3. mkdir -p ... umask 77 → step 5, creating the temp directory with restrictive permissions
4. /usr/bin/python3 .../AnsiballZ_ping.py → step 6, the target's Python running the pushed module
5. rm -f -r ... → step 8, cleaning up so nothing persists

Six lines contain the entire agentless architecture. Run this once and the model stops being abstract.

/home/deploy/.ansible/tmp/ansible-tmp-1755166234.12-8891-273:
AnsiballZ_ping.py

#!/usr/bin/python3
# -*- coding: utf-8 -*-
# This code is part of Ansible, but is an independent component...
# The purpose of this file is to create a zipfile in memory...
import base64
import runpy
import shutil
import sys
import tempfile
import zipfile

ZIPDATA = """UEsDBBQAAAAIAA...   <- the entire module, zipped and base64-encoded

There it is. A small Python bootstrapper wrapping a base64-encoded zip archive containing the module source and your arguments. That is step 3 of the diagram, made concrete.

⚠️ Clean up afterwards: ssh web01 'rm -rf ~/.ansible/tmp/*'

And never leave ANSIBLE_KEEP_REMOTE_FILES=1 set outside of debugging — module arguments can contain passwords and API tokens, and this leaves them sitting on disk.

Parse inputs and build the host list → select the module → generate a self-contained Python file (module + arguments, zipped and base64-encoded inside the AnsiballZ wrapper) → open or reuse the SSH connection → copy the file into a temp directory on the target → execute it with the remote Python, optionally through sudo → the module prints JSON to stdout → the control node parses that JSON and deletes the temp directory → the result renders as ok/changed/failed/skipped → next task.

The detail that impresses: emphasise that the module is executed by the target's Python, which is the whole reason a managed node needs Python.

Because modules are Python. The control node pushes module code to the target and the target executes it locally — which is far more efficient and far more capable than trying to express everything as remote shell commands.

"Agentless" means no persistent daemon, not no runtime. Nothing is installed; the module is copied, run, and deleted within a single task.

The exceptions prove the rule: raw needs no Python, Windows uses PowerShell instead, and network modules run entirely on the control node.

The wrapper Ansible generates for each task. It bundles the module source plus the task's arguments into a zip archive, base64-encodes it into a single self-contained Python file, and ships that one file to the target.

It exists so a task is a single file transfer and a single execution rather than a negotiation of dependencies, and so the module can be executed and cleaned up atomically.

web01 | SUCCESS => {
    "changed": false,
    "ping": "pong"
}

ansible [core 2.16.3]
  config file = /home/zaeem/ansible-lab/ansible.cfg

No -i, no -u, no key path. Every command from here on is shorter.

Remember config file = None from Exercise A3.1? It now shows a real path. That second line of ansible --version tells you which config file actually won the precedence race, and it is the first thing to check whenever a setting mysteriously "isn't applying" — because nine times out of ten, a different file won.

CONFIG_FILE() = /home/zaeem/ansible-lab/ansible.cfg
DEFAULT_STDOUT_CALLBACK(/home/zaeem/ansible-lab/ansible.cfg) = yaml

forks is nowhere to be seen — it has silently reverted to the default of 5.

./ansible.cfg won, and because configs do not merge, forks = 99 from ~/.ansible.cfg was discarded entirely rather than blended in. If you expected 99, you would now be debugging a performance problem that has nothing to do with performance.

Two commands to commit to memory:

ansible-config dump --only-changed   # everything currently non-default, WITH its source
ansible-config list                  # every available setting, its default, and its env var

DEFAULT_FORKS(env: ANSIBLE_FORKS) = 50

Note the annotation: (env: ANSIBLE_FORKS). Ansible tells you exactly where each value came from — a config file path, an environment variable, or a default.

Environment variables beat the config file, which is precisely what makes them right for CI pipelines: you tune a run without editing a file that is checked into Git and shared by everyone.

Runtime behaviour: inventory path, roles path, remote user, forks, privilege escalation defaults, SSH options, output callback, timeouts.

Search order: ANSIBLE_CONFIG env var → ./ansible.cfg → ~/.ansible.cfg → /etc/ansible/ansible.cfg.

The detail that separates candidates: first match wins, they do not merge, and world-writable directories are skipped entirely.

ansible --version shows the config file actually in use — usually the whole answer, because a different file won precedence.

Then ansible-config dump --only-changed, which lists every non-default value and annotates its source, so you can see whether it came from a file, an env var, or a default.

Also confirm the directory is not world-writable, and remember an ANSIBLE_* environment variable overrides the file.

It controls whether SSH verifies the target's host key against known_hosts. Disabling it stops "host key verification failed" on freshly built machines.

Acceptable for ephemeral hosts — CI runners, short-lived test VMs, containers.

Not acceptable for long-lived production hosts, because you are switching off MITM protection. The correct fix there is to pre-seed known_hosts with ssh-keyscan, or use signed host certificates.

Raise forks from the default 5 to 25–50. Enable pipelining, noting the sudoers caveat. Keep ControlPersist multiplexing on. Disable gather_facts in plays that never reference an ansible_* variable, or narrow it with gather_subset. Enable fact caching so facts survive between runs. Use async with poll: 0 for genuinely long operations.

And the answer that lands best: profile before guessing — callbacks_enabled = profile_tasks tells you where the time actually goes.

web01 | SUCCESS => {"changed": false, "ping": "pong"}
web02 | SUCCESS => {"changed": false, "ping": "pong"}

web01 | SUCCESS => {"ansible_facts": {"ansible_distribution": "Ubuntu", "ansible_distribution_major_version": "22", "ansible_distribution_version": "22.04"}, "changed": false}

web01 | CHANGED | rc=0 | (stdout) /dev/root  39G  8.1G  31G  21% /

web01 | CHANGED => {"changed": true, "name": "nginx", "state": "started"}

Command 2 introduces setup — the module that gathers facts, meaning everything Ansible can discover about a host: OS, IP addresses, memory, CPU, mounted filesystems, and much more. Run it unfiltered once (ansible web01 -m setup) just to see the scale of it. Facts are the whole of Module 02.

Command 3 hides an important lesson. It reported CHANGED even though df changed absolutely nothing — because shell has no way to know what your command did, so it assumes the worst. That single observation is the doorway to the next topic.

web01 | CHANGED => {"changed": true, ...}      <-- htop is MISSING here, would be installed
web02 | SUCCESS => {"changed": false, ...}     <-- htop already present, nothing to do

Nothing was installed. --check works on ad-hoc commands too, which turns this into a genuinely useful audit: "which of my 200 hosts is missing the monitoring agent?" becomes one command with no playbook at all.

Notice the module reported changed: false for web02 without you telling it anything about the current state. The module checked for itself. That property has a name, and it is the next topic.

A single task run directly from the command line without writing a playbook.

Use them for one-off, throwaway work: connectivity checks, gathering a fact across the fleet, an emergency restart, a quick audit.

Move to a playbook the moment the operation should be repeatable, reviewed or version-controlled. "If I'd want to run it again next month, it belongs in a playbook."

command — so ansible all -a "uptime" works. Because it is command and not shell, pipes, redirects and globs will not work in that form.

command executes the binary directly with no shell, so pipes, redirects, &&, globs and environment-variable expansion do not work. It is safer, with no shell-injection surface.

shell passes the string through /bin/sh, so all of that works, at the cost of that safety.

The instinct to voice: prefer command over shell, and prefer a real module over both.

Quick and dirty: ansible all -m ansible.builtin.shell -a "systemctl is-active nginx" -o.

Structured: gather service_facts and read ansible_facts.services['nginx.service'].state — which is what you want when the result feeds a conditional rather than a human's eyes.

copy, first run — the file does not exist yet:

web01 | CHANGED => {"changed": true, "checksum": "f572d396...", "dest": "/tmp/good.txt", "size": 6}

copy, second run — nothing to do:

web01 | SUCCESS => {"changed": false, "checksum": "f572d396...", "dest": "/tmp/good.txt", "size": 6}

shell, first run:

web01 | CHANGED | rc=0 >>

shell, second run — identical file, still claims it changed:

web01 | CHANGED | rc=0 >>

Look at the checksum field in the copy output. That is the mechanism: copy hashed the destination file, compared it with the source, found them identical, and did nothing. The shell module has no such option — it ran your command blindly and reported changed because it genuinely cannot know.

Now project this forward. In Part D you will attach handlers to tasks. If that shell task had a handler attached, nginx would restart on every run of every playbook, indefinitely, for a file that never changes. That is the production cost of a non-idempotent task, and describing it concretely is worth far more in an interview than reciting the definition.

Answer A — lineinfile, right when you are editing a file you do not fully own:

ansible web01 -m ansible.builtin.lineinfile -b \
  -a 'path=/etc/sudoers.d/deploy line="deploy ALL=(ALL) NOPASSWD:ALL" create=yes mode=0440 validate="visudo -cf %s"'

Answer B — copy, better when you own the whole file:

ansible web01 -m ansible.builtin.copy -b \
  -a 'content="deploy ALL=(ALL) NOPASSWD:ALL\n" dest=/etc/sudoers.d/deploy mode=0440 validate="visudo -cf %s"'

Both report CHANGED once and SUCCESS forever after. Run either twice to confirm.

⚠️ validate="visudo -cf %s" is not decoration. A malformed sudoers file locks everyone out of sudo on that host — including you, including your recovery attempt. validate runs the checker against the temporary file before it is moved into place, and aborts the task if it fails, so the live file is never touched.

The %s is substituted with the temp file path. Use the same pattern for sshd (sshd -t -f %s) and nginx (nginx -t -c %s) — the three files most capable of ending your afternoon.

Running the same playbook multiple times produces the same end state — the first run may change things, subsequent runs report ok and change nothing.

It is what makes playbooks safe to re-run, and what makes changed a meaningful signal rather than noise.

They inspect current state before acting. apt queries whether the package is already installed at the requested version. copy compares checksums and transfers nothing when they match. service checks the current running and enabled state before touching systemd.

When no action is required the module returns changed: false.

Three ways: creates: / removes: so the task is skipped when a marker path exists; changed_when: / failed_when: so you define the semantics yourself; or a when: guard driven by a registered fact or stat result.