Ansible Automation Communication & Stakeholder Relations 5 — Questions and Answers
Question 1: A manager asks why the Ansible project needs an ansible.cfg file. What is the clearest non-technical explanation?
- It stores the encrypted passwords for all managed nodes
- It defines default settings and behaviors for the project so teams don't have to repeat options on every command (Correct answer)
- It replaces the need for an inventory file in small environments
- It is required by law for compliance with NIST standards
Correct answer: It defines default settings and behaviors for the project so teams don't have to repeat options on every command
ansible.cfg centralizes project configuration defaults like inventory location, remote user, and connection settings, simplifying team workflows.
Question 2: Stakeholders want to know how Ansible Automation Platform's Role-Based Access Control (RBAC) benefits their organization. What is the key value proposition?
- RBAC allows Ansible to run faster by limiting which hosts are targeted
- RBAC ensures users can only access and run the automation relevant to their role, reducing security risk (Correct answer)
- RBAC replaces the need for SSH key management
- RBAC automatically generates compliance reports
Correct answer: RBAC ensures users can only access and run the automation relevant to their role, reducing security risk
RBAC in AAP restricts access to inventories, job templates, and credentials based on job function, enforcing least-privilege principles.
Question 3: A stakeholder is concerned that automating server configuration will reduce team flexibility. How do you best address this concern?
- Agree that automation reduces flexibility and propose a hybrid manual approach
- Explain that Ansible playbooks are easily modified and version-controlled, making changes faster and more consistent than manual processes (Correct answer)
- Commit to never changing the playbooks once deployed
- Propose limiting Ansible to only development environments
Correct answer: Explain that Ansible playbooks are easily modified and version-controlled, making changes faster and more consistent than manual processes
Version-controlled playbooks can be updated quickly and consistently, and changes propagate uniformly across all systems faster than manual intervention.
Question 4: During an incident review, the team realizes an Ansible playbook caused an unintended configuration change. What practice would have caught this before production?
- Running the playbook with --limit localhost first
- Testing playbooks in a staging environment and using --check mode before promoting to production (Correct answer)
- Adding more verbose logging to the playbook
- Removing the failed task from the playbook after the incident
Correct answer: Testing playbooks in a staging environment and using --check mode before promoting to production
Staging environment testing combined with --check dry-run mode validates playbook behavior before changes reach production systems.
Question 5: A stakeholder wants to understand what 'handlers' in Ansible are and why they matter for reliability. What is the best explanation?
- Handlers are error messages that appear when a task fails
- Handlers are tasks that only run when notified by another task, preventing unnecessary service restarts (Correct answer)
- Handlers are special tasks that always run at the beginning of a playbook
- Handlers are Ansible modules that communicate with external APIs
Correct answer: Handlers are tasks that only run when notified by another task, preventing unnecessary service restarts
Handlers run only when notified by a changed task, ensuring services like web servers restart only when their configuration actually changed.
Question 6: A cross-department team wants to share Ansible roles without duplicating code across projects. What is the recommended approach for distributing shared roles?
- Copy role directories manually between projects via email or shared drives
- Publish roles to Ansible Galaxy or a private Automation Hub and reference them with requirements.yml (Correct answer)
- Embed all shared logic into a single master playbook
- Store shared roles on a network share mapped to each control node
Correct answer: Publish roles to Ansible Galaxy or a private Automation Hub and reference them with requirements.yml
Ansible Galaxy and private Automation Hub provide centralized role repositories that teams can reference via requirements.yml for consistent shared content.
Question 7: An IT director asks how automation with Ansible reduces human error compared to manual runbooks. What is the most compelling argument?
- Ansible never makes mistakes because it uses AI to verify each step
- Automation executes the same tested code every time, eliminating variability from human interpretation and manual execution differences (Correct answer)
- Ansible slows down processes, allowing more time for humans to catch mistakes
- Manual runbooks are inherently more reliable because humans can adapt to unexpected situations
Correct answer: Automation executes the same tested code every time, eliminating variability from human interpretation and manual execution differences
Automated playbooks remove human variability by executing identical, pre-tested logic consistently across every run and every target system.
Ansible Automation Communication & Stakeholder Relations 5
A manager asks why the Ansible project needs an ansible.cfg file.
What is the clearest non-technical explanation?