Ansible Automation Ansible Playbook Structure and Variables 1 — Questions and Answers

Question 1: Which YAML key is used at the top level of an Ansible playbook to define which hosts the play targets?

hosts (Correct answer)
targets
machines
inventory

Correct answer: hosts

The 'hosts' key at the top level of a play specifies which hosts or groups from inventory the play will run against.

In an Ansible playbook, each play begins with a 'hosts' directive that specifies the target hosts or groups from the inventory. For example, 'hosts: webservers' targets the 'webservers' inventory group. You can also use patterns like 'hosts: all', 'hosts: *.example.com', or comma-separated groups. This is a mandatory key in every play definition.

Question 2: What is the correct way to define a variable inline within a playbook using the 'vars' block?

vars:\n my_var: value (Correct answer)
variables:\n my_var: value
set_vars:\n my_var: value
define:\n my_var: value

Correct answer: vars:\n my_var: value

The 'vars' block is the standard way to define play-level variables directly within a playbook.

Variables in an Ansible playbook can be defined using the 'vars' block at the play level. For example: vars: http_port: 80 app_name: myapp These variables are then accessible in tasks using Jinja2 syntax like '{{ http_port }}'. The 'vars' block sits alongside other play-level keys like 'hosts', 'become', and 'tasks'.

Question 3: In Ansible variable precedence, which variable type has the highest priority and overrides all others?

Extra vars passed with -e on the command line (Correct answer)
Role defaults
Host vars
Group vars

Correct answer: Extra vars passed with -e on the command line

Extra variables passed via '-e' or '--extra-vars' on the command line have the highest precedence in Ansible's variable hierarchy.

Ansible has a defined variable precedence order with 22 levels. Extra variables passed with '-e' or '--extra-vars' at the command line sit at the very top and override everything else, including role vars, play vars, and host/group vars. For example: 'ansible-playbook site.yml -e "env=production"'. Role defaults have the lowest precedence, making them easy to override.

Question 4: What Ansible module is commonly used to include a variable file into a playbook at runtime?

include_vars (Correct answer)
vars_files
import_vars
load_vars

Correct answer: include_vars

'include_vars' dynamically loads variables from a file during task execution, allowing conditional variable loading.

The 'include_vars' module allows you to load variables from a file or directory at task execution time. This is different from the play-level 'vars_files' key (which loads at play parse time). 'include_vars' supports dynamic filenames using variables, making it useful for loading environment-specific variable files: e.g., 'include_vars: file={{ env }}.yml'. It supports conditional loading via 'when' clauses.

Question 5: What does the 'gather_facts: false' setting in a playbook do?

Skips the automatic collection of system information from managed hosts (Correct answer)
Disables variable interpolation
Prevents task output from being displayed
Stops Ansible from connecting to remote hosts

Correct answer: Skips the automatic collection of system information from managed hosts

Setting 'gather_facts: false' disables the implicit 'setup' module call that collects host facts, speeding up playbooks that don't need system information.

By default, Ansible runs the 'setup' module at the start of every play to collect facts (system information) from managed hosts, such as OS type, network interfaces, memory, and more. These facts are accessible as variables. Setting 'gather_facts: false' skips this step, reducing playbook execution time—useful for simple plays that don't need host information or when targeting many hosts where fact gathering adds significant overhead.

Question 6: Which Jinja2 filter would you use to set a default value for a variable that might be undefined in an Ansible template?

{{ my_var | default('fallback') }} (Correct answer)
{{ my_var | fallback('fallback') }}
{{ my_var | ifnone('fallback') }}
{{ my_var | or('fallback') }}

Correct answer: {{ my_var | default('fallback') }}

The 'default' Jinja2 filter provides a fallback value when the variable is undefined or empty.

Ansible supports Jinja2 filters extensively. The 'default' filter is used to provide a fallback value: '{{ my_var | default("fallback") }}'. If 'my_var' is undefined, the filter returns 'fallback'. You can also use 'default(value, boolean=true)' to trigger the default for both undefined and falsy values (empty string, 0, false). This is essential for writing robust, reusable roles and playbooks.

Ansible Automation Ansible Playbook Structure and Variables 1

Which YAML key is used at the top level of an Ansible playbook to define which hosts the play targets?