Ansible Automation Risk Assessment & Management 4 — Questions and Answers
Question 1: Which Ansible feature allows marking specific tasks to run only during a change window, reducing unintended changes outside that window?
- Handlers
- Tags (Correct answer)
- Conditionals with `when`
- Async tasks
Correct answer: Tags
Tags let operators selectively run or skip specific tasks with `--tags` or `--skip-tags`, enabling controlled execution during defined change windows.
Question 2: What risk does using `shell` or `command` modules instead of purpose-built modules introduce?
- Tasks become non-idempotent and may produce unintended repeated changes (Correct answer)
- Ansible cannot log output
- Vault encryption is bypassed
- Inventory parsing fails
Correct answer: Tasks become non-idempotent and may produce unintended repeated changes
Shell/command modules bypass Ansible's idempotency guarantees, so tasks may re-run destructive operations every time instead of only when needed.
Question 3: An Ansible playbook modifies firewall rules on 200 servers using `serial: 1`. What risk does this mitigate compared to running all hosts simultaneously?
- Prevents SSH key rotation
- Limits simultaneous outages to one host if the firewall rule locks out management access (Correct answer)
- Speeds up playbook execution
- Avoids the need for `become`
Correct answer: Limits simultaneous outages to one host if the firewall rule locks out management access
Running one host at a time means a bad firewall rule only locks out one server at a time, leaving the rest accessible for remediation.
Question 4: Which Ansible Vault best practice reduces the risk of accidentally committing unencrypted secrets to version control?
- Store vault files in `/tmp`
- Use a `.gitignore` rule and pre-commit hooks to block unencrypted vault files (Correct answer)
- Use `no_log` instead of Vault
- Embed secrets in role defaults
Correct answer: Use a `.gitignore` rule and pre-commit hooks to block unencrypted vault files
Pre-commit hooks can detect and block unencrypted files from being committed, while `.gitignore` prevents accidental staging of plaintext secrets.
Question 5: What is the risk of using a single shared Ansible service account with broad sudo rights across all managed nodes?
- Playbooks cannot use loops
- Compromise of that account grants root-level access to every managed host (Correct answer)
- Facts cannot be gathered
- Roles cannot be downloaded from Galaxy
Correct answer: Compromise of that account grants root-level access to every managed host
A shared privileged account is a single point of failure; compromising it gives an attacker root access to the entire managed infrastructure.
Question 6: A playbook uses `delegate_to: localhost` to run a task on the control node. What risk should be assessed?
- The task will always fail silently
- Sensitive data or side effects may impact the control node rather than isolated target hosts (Correct answer)
- Ansible cannot gather remote facts
- The task skips handlers
Correct answer: Sensitive data or side effects may impact the control node rather than isolated target hosts
Tasks delegated to localhost execute on the control node itself, so a destructive or misconfigured task can damage the Ansible control infrastructure.
Question 7: Which metric best indicates that an Ansible deployment introduced unintended configuration drift across managed nodes?
- Number of skipped tasks
- Discrepancies revealed by a subsequent `--check` run showing unexpected changes (Correct answer)
- Total playbook runtime
- Number of handlers notified
Correct answer: Discrepancies revealed by a subsequent `--check` run showing unexpected changes
A follow-up `--check` run against supposedly stable hosts revealing pending changes indicates drift from the desired state caused by the prior deployment.
Which Ansible feature allows marking specific tasks to run only during a change window, reducing unintended changes outside that window?