Ansible Automation Professional Standards & Competencies 2 — Questions and Answers
Question 1: Which practice best demonstrates professional competency when writing Ansible roles for a team environment?
- Embedding all variables directly in tasks for clarity
- Following a consistent directory structure and documenting defaults in defaults/main.yml (Correct answer)
- Keeping all logic in a single monolithic playbook to reduce files
- Avoiding tags so all tasks always run
Correct 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.
Question 2: A colleague's playbook uses 'shell' module for every task. What is the professional standard recommendation?
- Shell modules are always preferred for flexibility
- Use purpose-built Ansible modules whenever available, falling back to shell only when necessary (Correct answer)
- Replace all shell tasks with raw module instead
- Avoid all command execution modules entirely
Correct 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.
Question 3: What is the professional approach to handling secrets in Ansible playbooks committed to version control?
- Store secrets in group_vars as plaintext for easy access
- Use Ansible Vault to encrypt sensitive files before committing (Correct answer)
- Exclude all variable files from version control entirely
- Use environment variables only and never reference them in playbooks
Correct 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.
Question 4: According to Ansible best practices, how should playbook task names be written?
- Task names are optional and should be omitted to keep playbooks short
- Use vague names like 'run task' to avoid over-documenting
- Write descriptive, action-oriented names that clearly state what each task does (Correct answer)
- Use only the module name as the task name
Correct 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.
Question 5: What does the principle of idempotency require in a professionally written Ansible task?
- The task must complete in under one second
- Running the task multiple times produces the same result as running it once (Correct answer)
- The task must always report 'changed' to confirm it executed
- The task must not use any variables
Correct 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.
Question 6: Which competency is demonstrated by using 'ansible-lint' before committing a playbook?
- Performance optimization
- Code quality assurance and adherence to style standards (Correct answer)
- Inventory validation
- Vault password verification
Correct 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.
Question 7: A professional Ansible practitioner discovers that a playbook works but produces unnecessary 'changed' results on every run. What should they do?
- Accept it as normal Ansible behavior
- Refactor tasks to be truly idempotent, using appropriate modules and conditions (Correct answer)
- Add 'ignore_errors: true' to suppress the changed status
- Mark all tasks with 'changed_when: false'
Correct 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.
Ansible Automation Professional Standards & Competencies 2
Which practice best demonstrates professional competency when writing Ansible roles for a team environment?