Ansible Automation Professional Standards & Competencies 3 — Questions and Answers
Question 1: What is the recommended professional approach for organizing Ansible inventory in a multi-environment setup?
- Use a single flat hosts file for all environments
- Separate inventory directories per environment (dev, staging, prod) with consistent group structures (Correct answer)
- Hard-code environment names inside playbooks
- Use only dynamic inventory regardless of environment size
Correct answer: Separate inventory directories per environment (dev, staging, prod) with consistent group structures
Separate inventory directories prevent cross-environment accidents and allow environment-specific variables to be clearly scoped.
Question 2: Which competency is reflected when an engineer writes a molecule test for a new Ansible role?
- Deployment automation
- Role testing and quality assurance (Correct answer)
- Inventory management
- Vault secret handling
Correct answer: Role testing and quality assurance
Molecule is the standard testing framework for Ansible roles, validating role behavior in isolated environments before deployment.
Question 3: When should an Ansible professional use 'block' with 'rescue' and 'always' sections?
- Only when running playbooks in check mode
- When grouping tasks that may fail and require cleanup or error-handling logic (Correct answer)
- To improve playbook execution speed
- To replace handlers in a role
Correct answer: When grouping tasks that may fail and require cleanup or error-handling logic
Block/rescue/always provides structured error handling similar to try/catch/finally, enabling graceful failure management.
Question 4: A professional decides to use 'include_tasks' instead of 'import_tasks'. What is the key difference driving this decision?
- include_tasks is statically loaded at parse time; import_tasks is dynamic
- include_tasks is dynamic and allows conditional inclusion at runtime; import_tasks is static (Correct answer)
- import_tasks supports loops while include_tasks does not
- include_tasks is faster for large playbooks
Correct answer: include_tasks is dynamic and allows conditional inclusion at runtime; import_tasks is static
include_tasks is processed dynamically at runtime, enabling conditional and looped task inclusion, while import_tasks is statically loaded at parse time.
Question 5: What professional standard should guide the use of 'become: true' in Ansible tasks?
- Apply become at the play level to all tasks for simplicity
- Apply become only to specific tasks that require elevated privileges, following least-privilege principles (Correct answer)
- Never use become; use root SSH keys instead
- Apply become in every role's defaults to prevent permission errors
Correct answer: Apply become only to specific tasks that require elevated privileges, following least-privilege principles
Least-privilege principle dictates that privilege escalation should be scoped as narrowly as possible to reduce security risk.
Question 6: Which approach reflects professional competency in managing Ansible Galaxy role dependencies?
- Download roles manually and commit them to the project repository
- Define role dependencies in requirements.yml and install them via 'ansible-galaxy install -r requirements.yml' (Correct answer)
- Copy role source code directly into the playbook directory
- Use git submodules for all Galaxy role dependencies
Correct answer: Define role dependencies in requirements.yml and install them via 'ansible-galaxy install -r requirements.yml'
requirements.yml with ansible-galaxy install is the standard, reproducible method for managing external role dependencies.
Question 7: What does a professional Ansible engineer do when a task needs to behave differently on RHEL vs. Ubuntu hosts?
- Write separate playbooks for each OS
- Use ansible_os_family or ansible_distribution variables with 'when' conditionals or OS-specific task files (Correct answer)
- Require all hosts to use the same OS before running automation
- Use the raw module to avoid OS differences
Correct answer: Use ansible_os_family or ansible_distribution variables with 'when' conditionals or OS-specific task files
Ansible's gathered facts expose OS information that can drive conditional logic, enabling a single role to handle multiple distributions.
What is the recommended professional approach for organizing Ansible inventory in a multi-environment setup?