What are ad-hoc commands in Ansible and when do you use them?
Learn what Ansible ad-hoc commands are, their syntax, and when to use them over playbooks for fast one-off tasks like pings, restarts, and installs.
Expected Interview Answer
Ad-hoc commands are one-off Ansible tasks run directly from the command line with the ansible command, executing a single module against hosts without writing a playbook.
They use the syntax ansible <pattern> -m <module> -a "<arguments>" and are ideal for quick, throwaway operations such as pinging hosts, restarting a service, copying a file, or checking uptime. Because they run one module at a time and are not saved, they are best for immediate, non-repeatable actions; anything you need to reuse, version, or orchestrate belongs in a playbook instead.
- Fast one-liners with no file to author
- Great for quick checks and diagnostics
- Uses the same modules and inventory as playbooks
- Idempotent when the underlying module is idempotent
- Ideal for ad-hoc fleet-wide operations like restarts or package installs
AI Mentor Explanation
An ad-hoc command is like a captain shouting a single quick instruction to the field during play — 'everyone move square' — done instantly with no written plan. A playbook is the pre-match strategy sheet worked out in the dressing room. You use the shout for a one-off adjustment, not for the whole innings.
Step-by-Step Explanation
Step 1
Pick a host pattern
Choose which hosts to target from your inventory, e.g. all, a group like webservers, or a single host.
Step 2
Choose a module
Select the module with -m, such as ping, command, service, copy, or yum/apt.
Step 3
Supply arguments
Pass module arguments with -a, for example -a "name=nginx state=restarted".
Step 4
Add options as needed
Use -b for privilege escalation (become), -i for a custom inventory, or --limit to narrow the run.
Step 5
Run and read the results
Execute the command and inspect the per-host output — ok, changed, or unreachable/failed.
What Interviewer Expects
- Correct ansible <pattern> -m <module> -a syntax
- Knowing when ad-hoc beats a playbook and vice versa
- Awareness that ad-hoc uses the same modules and inventory
- Understanding of become (-b) for privileged tasks
- Recognizing idempotency depends on the module used
Common Mistakes
- Confusing the command and shell modules with the idempotent service/package modules
- Using ad-hoc commands for complex multi-step workflows that should be playbooks
- Forgetting -b when the task needs root privileges
- Assuming every ad-hoc command is idempotent regardless of module
- Not quoting module arguments passed to -a correctly
Best Answer (HR Friendly)
“Ad-hoc commands are quick one-line instructions you type to make Ansible do a single job across your servers right away, like restarting a service or checking they are online. You use them for fast, one-off tasks, and save proper playbooks for anything you want to repeat or share.”
Code Example
# Ping all hosts to check connectivity
ansible all -m ping
# Restart nginx on the webservers group (with privilege escalation)
ansible webservers -m service -a "name=nginx state=restarted" -b
# Install the latest git package on all hosts
ansible all -m apt -a "name=git state=latest" -b
# Copy a file to a single host
ansible db01 -m copy -a "src=/etc/motd dest=/etc/motd"
# Run an arbitrary command and gather uptime
ansible all -m command -a "uptime"Follow-up Questions
- How does an ad-hoc command differ from a playbook?
- Which modules make ad-hoc commands idempotent and which do not?
- What is the difference between the command and shell modules?
- How do you escalate privileges in an ad-hoc command?
- How would you target only a subset of a group in an ad-hoc run?
MCQ Practice
1. Which flag specifies the module to run in an ad-hoc command?
-m selects the module; -a passes its arguments, -i sets inventory, and -b enables privilege escalation.
2. When is an ad-hoc command the better choice over a playbook?
Ad-hoc commands shine for quick, throwaway single-module actions; anything repeatable or multi-step belongs in a playbook.
3. Why might an ad-hoc command using the shell module NOT be idempotent?
The command/shell modules run raw commands, so they may alter state on every execution unless you guard them; state-aware modules like service are idempotent.
Flash Cards
Ad-hoc command syntax — ansible <host-pattern> -m <module> -a "<args>" — run a single module without a playbook.
When to use ad-hoc — Quick, one-off, non-repeatable tasks: pings, restarts, quick installs, diagnostics.
Privilege escalation flag — -b (become) runs the task as a privileged user such as root.
Idempotency in ad-hoc — Depends on the module: service/package/copy are idempotent; command/shell may not be.