Ansible Automation Communication & Stakeholder Relations 2 — Questions and Answers
Question 1: A stakeholder asks why Ansible playbooks sometimes run tasks in a different order than expected. What is the most accurate explanation to give?
- Ansible randomizes task order for security
- Ansible executes tasks sequentially in the order they appear in the playbook (Correct answer)
- Ansible runs tasks in parallel by default to maximize speed
- Task order depends on the inventory file structure
Correct answer: Ansible executes tasks sequentially in the order they appear in the playbook
Ansible runs tasks sequentially from top to bottom within a playbook, ensuring predictable execution order.
Question 2: A manager wants a non-technical summary of what 'idempotency' means in Ansible. Which explanation is most appropriate?
- Ansible encrypts all data during transmission
- Running the same playbook multiple times produces the same result without unintended changes (Correct answer)
- Ansible automatically rollbacks failed changes
- Playbooks are version-controlled and auditable
Correct answer: Running the same playbook multiple times produces the same result without unintended changes
Idempotency means re-running a playbook only makes changes when needed, keeping systems in the desired state safely.
Question 3: During a post-implementation review, stakeholders ask how to verify that Ansible made only the approved changes. Which feature best supports this?
- Ansible Tower survey forms
- The --check flag combined with verbose output for dry-run validation (Correct answer)
- Using only ad-hoc commands instead of playbooks
- Disabling the changed status in plays
Correct answer: The --check flag combined with verbose output for dry-run validation
The --check (dry-run) mode combined with -v verbose output shows exactly what Ansible would change without applying changes.
Question 4: A cross-functional team wants to know who ran a specific Ansible automation job last week. Where is the best place to find this audit trail?
- The /etc/ansible/hosts file
- Ansible Automation Platform (AAP) job history and audit logs (Correct answer)
- The playbook's YAML comments
- The managed node's cron logs
Correct answer: Ansible Automation Platform (AAP) job history and audit logs
Ansible Automation Platform maintains comprehensive job history including who launched jobs, when, and with what parameters.
Question 5: A security team requests that secrets used in Ansible playbooks never be stored in plaintext. How should you communicate the solution?
- Store secrets in environment variables on the control node only
- Use Ansible Vault to encrypt sensitive data at rest within the repository (Correct answer)
- Avoid using secrets in playbooks entirely
- Store secrets in a separate unversioned text file
Correct answer: Use Ansible Vault to encrypt sensitive data at rest within the repository
Ansible Vault encrypts sensitive variables and files so they can safely be stored alongside playbooks in version control.
Question 6: A project manager asks how teams can collaborate on Ansible content without overwriting each other's work. What is the recommended approach?
- Assign one person as the sole playbook owner
- Store Ansible content in a version control system like Git with branching strategies (Correct answer)
- Email updated playbook files between team members
- Use separate Ansible control nodes for each team member
Correct answer: Store Ansible content in a version control system like Git with branching strategies
Git version control with branching and pull requests enables collaborative Ansible development with change tracking and conflict resolution.
Question 7: An executive asks what the 'changed' vs 'ok' status in Ansible output means during a status report. What is the correct explanation?
- 'changed' means an error occurred; 'ok' means success
- 'changed' means the task modified the system; 'ok' means the system was already in the desired state (Correct answer)
- 'ok' means the task is still running; 'changed' means it finished
- 'changed' means a new host was added; 'ok' means existing hosts were skipped
Correct answer: 'changed' means the task modified the system; 'ok' means the system was already in the desired state
'changed' indicates Ansible made a modification, while 'ok' means the system was already correct and no action was needed.
Ansible Automation Communication & Stakeholder Relations 2
A stakeholder asks why Ansible playbooks sometimes run tasks in a different order than expected.
What is the most accurate explanation to give?