Ansible Automation Ansible Playbook Structure and Variables 2 — Questions and Answers
Question 1: In an Ansible playbook, what is the purpose of the 'become: true' directive?
- It enables privilege escalation so tasks run as a different user (e.g., root) (Correct answer)
- It makes the play mandatory and non-skippable
- It causes Ansible to become idempotent
- It enables connection to become persistent
Correct answer: It enables privilege escalation so tasks run as a different user (e.g., root)
'become: true' enables privilege escalation, typically via sudo, allowing tasks to run as root or another privileged user.
The 'become' directive in Ansible enables privilege escalation. When set to 'true', Ansible uses sudo (by default) or another escalation method (su, pbrun, etc.) to run tasks as a different user—typically root. You can specify 'become_user' to target a specific user. This is necessary for system-level operations like installing packages, modifying /etc files, or managing services. It can be set at the play, role, or task level.
Question 2: What is the difference between 'import_playbook' and 'include_playbook' in Ansible?
- import_playbook is static (processed at parse time) while include_playbook is dynamic (processed at runtime) (Correct answer)
- import_playbook supports variables but include_playbook does not
- include_playbook is faster than import_playbook
- They are identical with different names
Correct answer: import_playbook is static (processed at parse time) while include_playbook is dynamic (processed at runtime)
Static imports are processed when the playbook is parsed, enabling features like --list-tasks. Dynamic includes are processed during execution, enabling conditional logic.
'import_playbook' is processed statically at playbook parse time, meaning Ansible knows all tasks upfront—useful for '--list-tasks', '--list-tags', and '--check' mode. 'include_playbook' is processed dynamically at runtime, allowing the included playbook path to be determined by variables. However, dynamic includes have limitations: tags applied to them only affect the include statement itself, and 'when' conditions at the include level don't propagate to child tasks.
Question 3: How do you reference a variable named 'app_port' inside a task's module arguments in an Ansible playbook?
- {{ app_port }} (Correct answer)
- $(app_port)
- %app_port%
- ${app_port}
Correct answer: {{ app_port }}
Ansible uses Jinja2 templating syntax with double curly braces to reference variables within task arguments.
Ansible uses Jinja2 templating to reference variables. Within task arguments, variables are referenced using '{{ variable_name }}' syntax. For example: - name: Start application service: name: myapp port: "{{ app_port }}" When the entire argument value is a single variable reference, it must be quoted in YAML to avoid parsing issues. Complex expressions like '{{ app_port | int + 1 }}' are also supported.
Question 4: What keyword in a playbook task definition allows you to run a task only when a specific condition is true?
- when (Correct answer)
- condition
- if
- only_when
Correct answer: when
The 'when' keyword evaluates a Jinja2 expression and only runs the task if it evaluates to true.
The 'when' keyword in Ansible tasks provides conditional execution. It accepts Jinja2 expressions that evaluate to true or false. For example: - name: Install Apache yum: name: httpd state: present when: ansible_os_family == 'RedHat' Multiple conditions can be combined using lists (AND logic) or 'or' operators. The 'when' clause can reference facts, registered variables, or any defined variable.
Question 5: What is the purpose of 'vars_prompt' in an Ansible playbook?
- It prompts the user for variable values interactively at playbook runtime (Correct answer)
- It validates that required variables are defined before running
- It displays variable values to the user during execution
- It imports variables from a prompt file
Correct answer: It prompts the user for variable values interactively at playbook runtime
'vars_prompt' enables interactive playbook runs by asking the user to enter values for specified variables before task execution begins.
'vars_prompt' allows playbooks to interactively collect variable values from the operator at runtime. Example: vars_prompt: - name: db_password prompt: Enter the database password private: true Setting 'private: true' hides the input (like a password prompt). This is useful for sensitive values that shouldn't be stored in plaintext. For automated/non-interactive runs, Ansible Vault or extra-vars are preferred alternatives.
Question 6: In Ansible, what is a 'magic variable' and which one contains the hostname of the current managed host?
- Magic variables are special built-in variables set by Ansible; 'inventory_hostname' contains the current host's name (Correct answer)
- Magic variables are user-defined variables; 'ansible_host' contains the hostname
- Magic variables are role variables; 'role_hostname' contains the current host
- Magic variables are fact variables; 'ansible_fqdn' contains the hostname
Correct answer: Magic variables are special built-in variables set by Ansible; 'inventory_hostname' contains the current host's name
'inventory_hostname' is a magic variable that holds the name of the current host as defined in the inventory.
Magic variables are special variables that Ansible automatically sets, not gathered from managed hosts. 'inventory_hostname' contains the name of the current host as listed in the inventory file. Other important magic variables include: 'hostvars' (access variables of other hosts), 'groups' (all inventory groups), 'group_names' (groups the current host belongs to), and 'ansible_play_hosts' (active hosts in the current play). These are distinct from facts (collected from hosts via setup module).
Ansible Automation Ansible Playbook Structure and Variables 2
In an Ansible playbook, what is the purpose of the 'become: true' directive?