Ansible Automation Case Studies & Practical Application 5 — Questions and Answers
Question 1: A newly onboarded team member runs a playbook and gets 'UNREACHABLE' for several hosts. The SSH keys are correctly distributed. What is the most likely next step to diagnose the issue?
- Re-run with --check to see if the hosts are reachable in dry-run mode
- Run with -vvv to get verbose SSH connection details (Correct answer)
- Delete and regenerate the inventory file
- Add retry_files_enabled = False to ansible.cfg
Correct answer: Run with -vvv to get verbose SSH connection details
The -vvv flag enables verbose output including the exact SSH command and error, making it the fastest way to diagnose connection failures.
Question 2: An organization runs Ansible playbooks nightly to enforce server compliance. After a manual change on a server, the next nightly run should detect and correct the drift. Which type of Ansible task design enables this?
- Tasks using the command module to check and apply changes in one step
- Idempotent tasks using declarative Ansible modules that enforce desired state (Correct answer)
- Tasks that first delete all config and recreate it from scratch every run
- Tasks guarded by when: manual_change_detected conditions
Correct answer: Idempotent tasks using declarative Ansible modules that enforce desired state
Declarative Ansible modules compare current state to desired state and apply only the changes needed, correcting configuration drift automatically.
Question 3: A playbook uses delegate_to to run a task on localhost while iterating over remote hosts. What is a common use case for this pattern?
- Running tasks faster by offloading them to the control node
- Registering a remote host into a load balancer from the control node during deployment (Correct answer)
- Bypassing SSH authentication for privileged tasks
- Collecting facts from all hosts simultaneously
Correct answer: Registering a remote host into a load balancer from the control node during deployment
delegate_to: localhost is commonly used to call an API or CLI tool on the control node (e.g., deregistering a host from a load balancer) as part of a per-host deployment loop.
Question 4: A playbook creates an EC2 instance and then immediately tries to SSH into it. The connection fails because the instance isn't ready yet. What is the correct Ansible approach to handle this?
- Add a pause: seconds: 60 task after the EC2 creation task
- Use the wait_for module to poll port 22 until the instance is reachable (Correct answer)
- Set retry: 10 on the next task
- Use async and poll to create the instance and wait simultaneously
Correct answer: Use the wait_for module to poll port 22 until the instance is reachable
The wait_for module polls a host and port until connectivity is confirmed, providing a reliable way to wait for instance readiness.
Question 5: A development team wants to test Ansible roles against multiple OS versions (Ubuntu 20.04, 22.04, RHEL 8, RHEL 9) in isolation before promoting to production. Which tool is purpose-built for this?
- Ansible-lint with multi-OS configuration
- Molecule, which spins up container or VM instances per scenario (Correct answer)
- Running the playbook against a staging inventory with all OS types
- Using Vagrant manually to test each OS one at a time
Correct answer: Molecule, which spins up container or VM instances per scenario
Molecule is the standard Ansible role testing framework, supporting multiple driver backends to test roles against different platforms automatically.
Question 6: A playbook task takes 10 minutes to complete on each of 50 hosts, and they must all run simultaneously rather than waiting for each other. Which Ansible approach achieves parallel async execution?
- Set strategy: free so hosts don't wait for each other between tasks
- Use async with a poll value and then use async_status to check completion (Correct answer)
- Set forks: 50 so all hosts run simultaneously and wait for each task
- Use throttle: 50 on the long-running task
Correct answer: Use async with a poll value and then use async_status to check completion
async fires the task without waiting for completion, and async_status is used afterward to poll until all async tasks finish, enabling true parallel long-running operations.
Question 7: A company enforces that every Ansible change must be peer-reviewed before running in production. Which practice best integrates this requirement into an automated workflow?
- Require verbal approval from a senior engineer before each ansible-playbook run
- Store playbooks in Git and use pull request reviews, then trigger AWX/Tower jobs from merged branches only (Correct answer)
- Run playbooks in --check mode in production after every commit
- Use Ansible Vault to lock playbooks so only seniors can decrypt and run them
Correct answer: Store playbooks in Git and use pull request reviews, then trigger AWX/Tower jobs from merged branches only
Git-based PR reviews combined with AWX/Tower job templates that only trigger on merged branches enforce peer review as a gate before production execution.
Ansible Automation Case Studies & Practical Application 5
A newly onboarded team member runs a playbook and gets 'UNREACHABLE' for several hosts.
The SSH keys are correctly distributed.
What is the most likely next step to diagnose the issue?