Ansible Automation Risk Assessment & Management 3 — Questions and Answers
Question 1: What risk arises when Ansible variables are defined in multiple locations with overlapping names?
- Playbooks will fail to parse
- Unexpected variable precedence may override intended values (Correct answer)
- Ansible Vault encryption breaks
- Inventory becomes unsortable
Correct answer: Unexpected variable precedence may override intended values
Ansible's 22-level variable precedence means a lower-priority definition can silently be overridden by a higher-priority one, causing unintended behavior.
Question 2: Which practice reduces the risk of accidental production changes when maintaining separate dev and prod inventories?
- Using the same playbook for all environments
- Requiring explicit `--limit` to target production hosts (Correct answer)
- Storing all inventories in one file
- Disabling host key checking globally
Correct answer: Requiring explicit `--limit` to target production hosts
Requiring `--limit production` or a separate production inventory file adds a deliberate step that prevents accidental targeting of production systems.
Question 3: An organization stores all Ansible playbooks in a public GitHub repository. What is the primary risk?
- Playbooks may become unreadable
- Hardcoded secrets or infrastructure details may be exposed publicly (Correct answer)
- Git versioning conflicts with Ansible Tower
- Roles cannot be imported from Git
Correct answer: Hardcoded secrets or infrastructure details may be exposed publicly
Public repositories expose any hardcoded credentials, internal hostnames, or topology details embedded in playbooks to anyone on the internet.
Question 4: What is the risk of disabling SSH host key checking (`ANSIBLE_HOST_KEY_CHECKING=False`) in production?
- Slower playbook execution
- Vulnerability to man-in-the-middle attacks (Correct answer)
- Ansible cannot gather facts
- Privilege escalation is disabled
Correct answer: Vulnerability to man-in-the-middle attacks
Disabling host key checking removes verification of remote host identity, making connections susceptible to MITM attacks.
Question 5: A team uses `become: yes` globally in ansible.cfg without task-level restrictions. What is the risk?
- All tasks fail if sudo is unavailable
- Every task runs as root even when unnecessary, expanding the attack surface (Correct answer)
- Ansible cannot connect via SSH
- Playbooks require manual approval
Correct answer: Every task runs as root even when unnecessary, expanding the attack surface
Global privilege escalation means every task runs as root, unnecessarily increasing the impact of any exploited vulnerability or misconfigured task.
Question 6: Which Ansible construct is most appropriate for enforcing a rollback if a deployment task fails?
- when clause
- block/rescue/always (Correct answer)
- tags
- loop
Correct answer: block/rescue/always
The `block/rescue/always` structure allows defining tasks that execute only on failure (rescue) or unconditionally (always), enabling structured rollback logic.
Question 7: What risk does an excessively high `forks` value in ansible.cfg introduce?
- Playbooks ignore variable files
- Control node resource exhaustion and overwhelming target hosts simultaneously (Correct answer)
- SSH keys are not used for authentication
- Ansible skips handlers
Correct answer: Control node resource exhaustion and overwhelming target hosts simultaneously
A very high `forks` value spawns many parallel processes, which can exhaust control node CPU/memory and flood target hosts with simultaneous connections.
Ansible Automation Risk Assessment & Management 3
What risk arises when Ansible variables are defined in multiple locations with overlapping names?