Ansible Automation Case Studies & Practical Application 3 — Questions and Answers
Question 1: A company's CI/CD pipeline must apply Ansible playbooks automatically on every code merge. Credentials must not be stored in the pipeline config. What is the best approach?
- Embed SSH keys directly in the Jenkinsfile
- Use Ansible Tower/AWX with machine credentials stored in its credential store (Correct answer)
- Pass passwords via pipeline environment variables in plain text
- Generate a new SSH key pair for every pipeline run
Correct answer: Use Ansible Tower/AWX with machine credentials stored in its credential store
Ansible Tower/AWX provides a secure credential store that injects credentials at runtime without exposing them to the pipeline configuration.
Question 2: An Ansible role is being reused across projects, but each project needs slightly different default values. Where should defaults be placed so they can be easily overridden?
- In the role's vars/main.yml file
- In the role's defaults/main.yml file (Correct answer)
- In the playbook's vars section
- In the inventory host_vars directory
Correct answer: In the role's defaults/main.yml file
defaults/main.yml has the lowest variable precedence in Ansible, making it easy for playbooks or inventory variables to override role defaults.
Question 3: A playbook needs to iterate over a list of users and create a home directory for each. Which Ansible construct is most appropriate?
- Using with_items or loop with the user module (Correct answer)
- Running the playbook once per user with different -e flags
- Writing a separate task for each user
- Using the command module with a for loop in bash
Correct answer: Using with_items or loop with the user module
loop (or legacy with_items) iterates the user module over each element in the list, creating all home directories in a single task definition.
Question 4: After a failed playbook run that partially configured servers, an engineer re-runs it and some tasks fail because they attempt to recreate already-existing resources. What Ansible design principle would have prevented this?
- Using become: true on all tasks
- Writing idempotent tasks using Ansible modules instead of raw shell commands (Correct answer)
- Adding ignore_errors: true to all tasks
- Using tags to skip already-completed tasks
Correct answer: Writing idempotent tasks using Ansible modules instead of raw shell commands
Idempotent tasks check current state before making changes, so re-running a playbook produces the same result without failing on already-applied changes.
Question 5: A team wants to verify that their Ansible roles meet quality standards before merging to main. Which tool is specifically designed to lint Ansible playbooks and roles?
- yamllint
- ansible-lint (Correct answer)
- pylint
- shellcheck
Correct answer: ansible-lint
ansible-lint checks playbooks and roles against a set of Ansible-specific best practice rules beyond basic YAML syntax.
Question 6: A playbook uses a loop to create 10 EC2 instances, but the output floods the terminal making debugging difficult. How can you suppress the verbose per-item output?
- Set no_log: true on the task
- Add loop_control with label to display only a short identifier per iteration (Correct answer)
- Use register and print only the last result
- Set verbosity: 0 globally in ansible.cfg
Correct answer: Add loop_control with label to display only a short identifier per iteration
loop_control with a label field lets you define a concise per-item display string, reducing output clutter without hiding all output.
Question 7: An engineer needs a playbook to configure servers differently based on whether the host is running RHEL or Ubuntu. Which variable provides the OS family for this conditional?
- ansible_distribution_version
- ansible_os_family (Correct answer)
- ansible_kernel
- ansible_architecture
Correct answer: ansible_os_family
ansible_os_family returns values like 'RedHat' or 'Debian', enabling tasks to branch based on the operating system family.
A company's CI/CD pipeline must apply Ansible playbooks automatically on every code merge.
Credentials must not be stored in the pipeline config.
What is the best approach?