Communication & Stakeholder Relations Flashcards

A stakeholder asks why Ansible playbooks sometimes run tasks in a different order than expected. What is the most accurate explanation to give?

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.

A manager wants a non-technical summary of what 'idempotency' means in Ansible. Which explanation is most appropriate?

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.

During a post-implementation review, stakeholders ask how to verify that Ansible made only the approved changes. Which feature best supports this?

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.

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?

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.

A security team requests that secrets used in Ansible playbooks never be stored in plaintext. How should you communicate the solution?

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.

A project manager asks how teams can collaborate on Ansible content without overwriting each other's work. What is the recommended approach?

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.

An executive asks what the 'changed' vs 'ok' status in Ansible output means during a status report. What is the correct explanation?

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.