Ansible Quick Reference

Analogy categoryAnalogies

Core CLI Commands

The two commands you'll type most often are ansible for one-off ad-hoc commands against an inventory, and ansible-playbook for running a full YAML playbook. Ad-hoc commands are ideal for quick checks like 'is this service running on every host' without writing a file, while playbooks are for anything you want to be repeatable, version-controlled, and reviewed. Both commands accept -i to specify an inventory file, -l to limit execution to a subset of hosts, and -u to set the remote SSH user, and both respect the same ansible.cfg configuration file for defaults.

🏏

Cricket analogy: Ad-hoc commands are like a quick single run taken to keep the strike rotating, while a full playbook run is like executing a pre-planned batting strategy for the entire innings — both matter, but one is a one-off decision and the other is a rehearsed plan.

bash

# Ad-hoc: ping every host to check connectivity
ansible all -i inventory.ini -m ping

# Ad-hoc: check uptime on webservers group only
ansible webservers -i inventory.ini -m command -a "uptime"

# Run a full playbook
ansible-playbook -i inventory.ini site.yml

# Limit to one host, dry-run, show diffs
ansible-playbook -i inventory.ini site.yml -l web01 --check --diff

# Run only tasks tagged 'deploy'
ansible-playbook -i inventory.ini site.yml --tags deploy

# Prompt for vault password
ansible-playbook -i inventory.ini site.yml --ask-vault-pass

Playbook Keywords and Common Modules

Every playbook is built from a small set of recurring keywords: hosts (target group), become (privilege escalation), vars (inline variables), tasks (the list of actions), and handlers (notified, deferred actions). On the module side, a handful cover the vast majority of real work: apt/yum/package for package management, service/systemd for process control, copy/template for file management, file for permissions and directories, user/group for account management, git for source checkout, and uri/get_url for HTTP interactions. Knowing these by name (rather than reaching for shell every time) is what separates idiomatic Ansible from a script wrapped in YAML.

🏏

Cricket analogy: Knowing core modules by name is like a captain knowing exactly which specialist bowler to bring on for a given situation — a death-overs specialist here, a spinner there — rather than throwing the ball to whoever's nearest, the way a captain like Eoin Morgan meticulously matched bowlers to match-ups.

yaml

- hosts: webservers
  become: true
  vars:
    app_port: 8080
  tasks:
    - name: Install package
      ansible.builtin.package:
        name: nginx
        state: present

    - name: Copy static file
      ansible.builtin.copy:
        src: files/index.html
        dest: /var/www/html/index.html

    - name: Render templated config
      ansible.builtin.template:
        src: app.conf.j2
        dest: /etc/app/app.conf
      notify: Restart nginx

    - name: Ensure service is running
      ansible.builtin.service:
        name: nginx
        state: started
        enabled: true

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

Use ansible-doc <module_name> (e.g. ansible-doc ansible.builtin.template) to pull up the exact parameter list and examples for any module directly in your terminal, without needing to search online docs.

Variables, Facts, and Loops

Variables can be set at many levels — inline in a play with vars, per-host or per-group in host_vars/group_vars, or passed at runtime with -e key=value on the command line, and Ansible resolves precedence in a well-defined order where command-line -e wins over nearly everything else. ansible_facts (gathered automatically at the start of a play via the setup module, unless gather_facts: false) exposes system details like OS family, IP addresses, and memory, referenced with {{ ansible_facts.os_family }} or the older {{ ansible_os_family }} shorthand. Looping over a list of items is done with the loop keyword (the modern replacement for the older with_items), letting one task install a whole list of packages or create multiple users without duplicating the task block.

🏏

Cricket analogy: Variable precedence is like team selection rules where a direct instruction from the captain on the field overrides the pre-match team meeting plan, which itself overrides the standing selection policy — the most immediate, specific input always wins.

bash

# Override a variable at runtime (highest precedence)
ansible-playbook site.yml -e "app_port=9090"

# Check facts for a host
ansible web01 -m setup -a "filter=ansible_os_family"

yaml

- name: Install a list of packages
  ansible.builtin.package:
    name: "{{ item }}"
    state: present
  loop:
    - nginx
    - git
    - curl

with_items still works but is considered legacy syntax; new playbooks should use loop (or loop_control for more advanced looping needs like custom loop variable names) for consistency with current Ansible documentation and community examples.

ansible runs ad-hoc one-off commands; ansible-playbook runs full, repeatable YAML playbooks.
Common flags: -i (inventory), -l (limit hosts), -e (extra vars), --check --diff (dry run), --tags (subset of tasks).
Core modules to know by name: package, service, copy, template, file, user, git, uri — prefer these over shell/command.
ansible-doc <module> gives instant offline reference for any module's parameters and examples.
Variable precedence flows from defaults up through group_vars/host_vars/play vars to command-line -e, which wins.
ansible_facts (via the automatic setup module) exposes system details like OS family and network interfaces.
Use loop (not the legacy with_items) to iterate a task over a list of items.

Practice what you learned

1. What is the main difference between the `ansible` and `ansible-playbook` commands?

2. Which flag performs a dry run and shows exactly what would change without applying it?

3. What command gives instant offline documentation for a specific module's parameters?

4. In Ansible's variable precedence, which of these typically wins over the others?

5. What is the modern, preferred keyword for iterating a task over a list of items?

Was this page helpful?

Ansible Interview Questions

Related Study Notes in DevOps

Browse all study notes

DevOps

Nginx Study Notes

DevOps · 30 topics

DevOps

Advanced Kubernetes Study Notes

Kubernetes · 30 topics

DevOps

Advanced Bash Scripting Study Notes

Bash · 30 topics

DevOps

Apache Kafka Study Notes

Kafka · 30 topics

DevOps

Docker & Kubernetes Study Notes

YAML · 40 topics

DevOps

CI/CD Tools & Pipelines Study Notes

YAML · 37 topics

Topics covered

#DevOps#AnsibleStudyNotes#AnsibleQuickReference#Ansible#Quick#Reference#Core#StudyNotes#SkillVeris#ExamPrep

Core CLI Commands

Playbook Keywords and Common Modules

Variables, Facts, and Loops

Practice what you learned

You May Also Like

Related Reading

Related Study Notes in DevOps

Topics covered