Ansible Automation Communication & Stakeholder Relations 3 — Questions and Answers
Question 1: A compliance officer wants assurance that Ansible automation follows change management procedures. Which practice best demonstrates compliance?
- Running playbooks only during business hours
- Integrating Ansible jobs with a CMDB and ticketing system like ServiceNow (Correct answer)
- Keeping playbooks on a local laptop to avoid network exposure
- Hardcoding all configuration values to prevent accidental changes
Correct answer: Integrating Ansible jobs with a CMDB and ticketing system like ServiceNow
Integrating Ansible with ITSM tools like ServiceNow links automation runs to approved change tickets, satisfying change management requirements.
Question 2: During a sprint review, a developer asks why Ansible uses YAML for playbooks instead of a more traditional programming language. How do you respond?
- YAML is the only language Ansible supports for technical reasons
- YAML is human-readable and accessible to both engineers and non-technical stakeholders for review (Correct answer)
- YAML playbooks execute faster than scripted alternatives
- YAML prevents syntax errors automatically
Correct answer: YAML is human-readable and accessible to both engineers and non-technical stakeholders for review
YAML's plain-text, human-readable format makes playbooks reviewable by stakeholders with varying technical backgrounds.
Question 3: A team lead wants to notify specific stakeholders only when an Ansible job fails. Which Ansible Automation Platform feature supports this?
- Limit groups in inventory
- Notification templates configured to trigger on job failure events (Correct answer)
- Setting the serial parameter to 1 in playbooks
- Using the --extra-vars flag at runtime
Correct answer: Notification templates configured to trigger on job failure events
AAP notification templates can send alerts via email, Slack, or PagerDuty when specific job events like failures occur.
Question 4: A stakeholder questions why an Ansible playbook was run against production without a change window. Which governance feature would prevent this in the future?
- Adding a pause task at the beginning of every playbook
- Using AAP scheduling and workflow approvals to enforce change windows and human gates (Correct answer)
- Removing production from the inventory file until needed
- Encrypting the playbook so only admins can read it
Correct answer: Using AAP scheduling and workflow approvals to enforce change windows and human gates
AAP workflow templates with approval nodes ensure humans authorize automation before it runs against sensitive environments.
Question 5: A DevOps team wants to communicate automation status to stakeholders who don't have AAP access. Which integration approach is most practical?
- Email raw playbook YAML files after each run
- Configure AAP to post job results to a collaboration tool like Slack or Microsoft Teams (Correct answer)
- Grant all stakeholders full AAP admin access
- Create manual status reports in spreadsheets
Correct answer: Configure AAP to post job results to a collaboration tool like Slack or Microsoft Teams
AAP's notification integrations push job summaries to collaboration tools, giving stakeholders visibility without requiring direct platform access.
Question 6: An operations team is concerned about Ansible making too many simultaneous changes and causing outages. How do you address this in a playbook?
- Remove all hosts from inventory except one at a time
- Use the 'serial' keyword to limit how many hosts are updated simultaneously (Correct answer)
- Set max_fail_percentage to 0 in the play
- Disable parallelism globally in ansible.cfg
Correct answer: Use the 'serial' keyword to limit how many hosts are updated simultaneously
The 'serial' keyword controls how many hosts Ansible targets at once, enabling rolling updates that reduce risk of widespread outages.
Question 7: A business analyst wants to understand the difference between Ansible ad-hoc commands and playbooks when presenting automation options to leadership. What is the key distinction?
- Ad-hoc commands are more secure than playbooks
- Ad-hoc commands handle quick one-time tasks; playbooks define repeatable, documented automation workflows (Correct answer)
- Playbooks run faster than ad-hoc commands
- Ad-hoc commands require a GUI while playbooks use the command line
Correct answer: Ad-hoc commands handle quick one-time tasks; playbooks define repeatable, documented automation workflows
Ad-hoc commands are for immediate, one-off tasks while playbooks provide reusable, version-controlled automation suitable for recurring processes.
A compliance officer wants assurance that Ansible automation follows change management procedures.
Which practice best demonstrates compliance?