Professional Standards & Competencies Flashcards

Which practice best demonstrates professional competency when writing Ansible roles for a team environment?

Answer: Following a consistent directory structure and documenting defaults in defaults/main.yml

Using Ansible's standard role directory structure and documenting defaults promotes maintainability and team collaboration.

A colleague's playbook uses 'shell' module for every task. What is the professional standard recommendation?

Answer: Use purpose-built Ansible modules whenever available, falling back to shell only when necessary

Ansible's purpose-built modules are idempotent, handle errors consistently, and follow best practices compared to raw shell commands.

What is the professional approach to handling secrets in Ansible playbooks committed to version control?

Answer: Use Ansible Vault to encrypt sensitive files before committing

Ansible Vault encrypts sensitive data so secrets can be safely stored in version control alongside playbooks.

According to Ansible best practices, how should playbook task names be written?

Answer: Write descriptive, action-oriented names that clearly state what each task does

Descriptive task names improve readability, make play output understandable, and serve as inline documentation.

What does the principle of idempotency require in a professionally written Ansible task?

Answer: Running the task multiple times produces the same result as running it once

Idempotency ensures that repeated playbook runs do not cause unintended changes when the system is already in the desired state.

Which competency is demonstrated by using 'ansible-lint' before committing a playbook?

Answer: Code quality assurance and adherence to style standards

ansible-lint checks playbooks against a set of rules and best practices to catch style issues and potential bugs early.

A professional Ansible practitioner discovers that a playbook works but produces unnecessary 'changed' results on every run. What should they do?

Answer: Refactor tasks to be truly idempotent, using appropriate modules and conditions

Unnecessary changed results obscure real changes and indicate tasks are not properly idempotent, which should be fixed by refactoring.