Ansible Automation Communication & Stakeholder Relations 4 — Questions and Answers
Question 1: A new stakeholder is confused about the difference between Ansible roles and regular playbooks. How do you best explain roles?
- Roles are playbooks that can only run on a single host
- Roles are reusable, self-contained units of automation that can be shared across multiple playbooks and projects (Correct answer)
- Roles replace the need for inventory files
- Roles are only available in the paid version of Ansible
Correct answer: Roles are reusable, self-contained units of automation that can be shared across multiple playbooks and projects
Ansible roles package tasks, variables, files, and handlers into a reusable structure that promotes consistency and code reuse across projects.
Question 2: A security stakeholder asks how Ansible communicates with managed nodes and whether that communication is encrypted. What is the standard answer?
- Ansible uses HTTP for speed with optional TLS upgrade
- Ansible connects to Linux nodes via SSH (encrypted by default) and Windows nodes via WinRM (Correct answer)
- Ansible requires a VPN for secure communication
- Ansible installs a persistent agent that handles its own encryption
Correct answer: Ansible connects to Linux nodes via SSH (encrypted by default) and Windows nodes via WinRM
Ansible uses SSH for Linux systems and WinRM for Windows, both of which provide encrypted communication channels by default.
Question 3: A stakeholder asks why some Ansible tasks show 'skipped' in the output. What is the correct explanation?
- Skipped tasks encountered network errors and will retry automatically
- Tasks were skipped because their 'when' condition evaluated to false for those hosts (Correct answer)
- Skipped means the task is queued but not yet executed
- Tasks are skipped when the playbook runs in check mode
Correct answer: Tasks were skipped because their 'when' condition evaluated to false for those hosts
The 'when' conditional directive causes Ansible to skip tasks on hosts where the specified condition is not met.
Question 4: After a major automation initiative, stakeholders request a metrics dashboard showing automation coverage and job success rates. Which tool provides this natively?
- The Ansible CLI verbose flag
- Ansible Automation Platform's Analytics and Reporting dashboards (Correct answer)
- A custom Python script parsing log files
- The managed nodes' built-in monitoring agents
Correct answer: Ansible Automation Platform's Analytics and Reporting dashboards
AAP's built-in Analytics feature provides dashboards showing job trends, host counts, automation savings, and success/failure rates over time.
Question 5: A project team wants to ensure stakeholders can trigger approved Ansible jobs without needing CLI access or playbook knowledge. What AAP feature enables this?
- Exposing SSH keys to stakeholders for direct access
- Survey forms on workflow and job templates that present a user-friendly interface for parameterized job execution (Correct answer)
- Sharing the ansible-playbook command in a wiki
- Granting stakeholders read-only inventory access
Correct answer: Survey forms on workflow and job templates that present a user-friendly interface for parameterized job execution
AAP survey forms let stakeholders launch complex automation by filling out simple forms without needing to understand the underlying playbook code.
Question 6: A team adopting Ansible asks how to communicate infrastructure state to remote teams without granting system access. What approach best serves this need?
- Email screenshots of Ansible output
- Publish Ansible facts and job reports to a shared dashboard or centralized CMDB (Correct answer)
- Create manual inventory spreadsheets weekly
- Run playbooks in check mode and share raw terminal output
Correct answer: Publish Ansible facts and job reports to a shared dashboard or centralized CMDB
Pushing Ansible facts and job summaries to a CMDB or dashboard provides stakeholders a live view of infrastructure state without requiring direct access.
Question 7: A change advisory board (CAB) requests that all Ansible playbooks affecting production be peer-reviewed before use. What process supports this requirement?
- Running playbooks in verbose mode before production use
- Requiring playbook changes to go through pull requests in Git with mandatory reviewer approvals (Correct answer)
- Having one senior engineer memorize all playbooks
- Using only built-in Ansible modules to avoid review overhead
Correct answer: Requiring playbook changes to go through pull requests in Git with mandatory reviewer approvals
Git pull request workflows with required approvals enforce peer review of playbook changes before they can be merged and deployed to production.
Ansible Automation Communication & Stakeholder Relations 4
A new stakeholder is confused about the difference between Ansible roles and regular playbooks.
How do you best explain roles?