Ansible Role Defaults Precedence: Lowest Priority Variables
Which TWO statements about Ansible role defaults are true?
Quick Answer
Role defaults having the lowest priority of all Ansible variables is correct because of what defaults/main.yml is designed to do: provide a fallback value that lets a role run out of the box, while still being trivially overridden by anyone using the role. Ansible's variable precedence system is built in layers, and defaults sit at the very bottom of that stack specifically so that any other variable source, such as group_vars, host_vars, playbook vars, or extra vars passed on the command line, can override them without any special syntax or effort. This is what makes roles reusable: the role author bakes in sensible starting values without locking consumers of the role into them. If defaults carried higher precedence, roles would become rigid and hard to customize, which would defeat their purpose as shareable, general-purpose building blocks. Whenever an exam question asks you to reason about which variable value wins in a conflict, it helps to remember that variable sources are essentially ranked by how likely they are to represent an intentional, specific override - defaults are the least specific and most easily overridden, while something like extra vars on the command line sits at the opposite end, so defaults will lose to virtually every other variable source.
⚠ Common exam trap
The EX294 exam often tests the distinction between role defaults and role vars, where candidates mistakenly think defaults have higher priority or cannot be overridden, but in reality defaults are the lowest priority and designed to be overridden by any other variable source.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Defaults are loaded from the defaults/main.yml file.
Option B is correct because Ansible automatically loads role default variables from the defaults/main.yml file inside the role's directory structure, making it the standard location for defining fallback values. Option E is correct because defaults have the lowest precedence in Ansible's variable priority hierarchy, meaning nearly any other variable source (inventory vars, play vars, host vars, extra vars, etc.) will override them. Option A is incorrect because defaults are always loaded, not conditionally based on whether other vars exist; they simply get overridden when higher-priority variables are present. Option C is incorrect because defaults have lower priority than playbook vars, not higher. Option D is incorrect because defaults are specifically designed to be easily overridden by higher-precedence variable sources.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Defaults are only loaded if no vars are defined.
Why it's wrong here
Role defaults are always loaded and then overridden by any higher-precedence variable, so they apply even when vars exist. They are the lowest-precedence variables, intended as fallback values; a role that must refuse overriding would place values in vars/main.yml instead.
- ✓
Defaults are loaded from the defaults/main.yml file.
Why this is correct
Defaults are loaded from `defaults/main.yml` within a role's directory structure, giving them the lowest precedence of any role variable. This satisfies the scenario's requirement by ensuring these values are easily overridden by inventory variables, playbook vars, or `--extra-vars`, making roles reusable across environments without editing role files.
- ✗
Defaults have higher priority than variables defined in the playbook.
Why it's wrong here
Defaults rank below every other variable source, including playbook vars, so playbook definitions win. They exist to provide low-precedence fallback values that callers can replace; if higher priority than playbook vars were required, the role would use vars/main.yml instead.
- ✗
Defaults cannot be overridden.
Why it's wrong here
Defaults sit at the bottom of Ansible's variable precedence, so inventory, playbook, host and extra vars all override them freely. Their purpose is exactly to supply overridable fallback values; a role needing fixed, non-overridable values would define them in vars/main.yml.
- ✓
Defaults have the lowest priority of all variables.
Why this is correct
Role defaults sit at the bottom of Ansible's variable precedence hierarchy, below inventory variables, play vars, host facts, and role vars. This ensures a role ships sensible fallback values that any other variable source can override without editing the role itself.
Go deeper
Related to this question
About these practice questions
One of 392 original EX294 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
Same concept, more angles
1 more way this is tested on EX294
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. Which TWO of the following statements about Ansible roles are correct?
medium- A.Role names must be prefixed with 'ansible-role-' when published to Ansible Galaxy.
- ✓ B.Variables in 'defaults/main.yml' have the lowest precedence and can be overridden by inventory variables.
- ✓ C.Role dependencies are defined in the 'meta/main.yml' file.
- D.The 'include_role' module can only be used for static imports.
- E.A role's tasks are executed before any 'pre_tasks' defined in the playbook.
Why B: Option B is correct because variables defined in a role's defaults/main.yml have the lowest precedence in Ansible's variable hierarchy, meaning they can be overridden by inventory variables (host_vars, group_vars), play vars, and virtually any other variable source. Option C is correct because role dependencies are declared in the meta/main.yml file under the 'dependencies' key, which Ansible reads to automatically pull in and execute dependent roles before the current role. Option A is incorrect because the 'ansible-role-' prefix is only a naming convention recommended for Galaxy, not a mandatory requirement. Option D is incorrect because include_role performs dynamic inclusion at runtime, whereas import_role is used for static imports. Option E is incorrect because pre_tasks in a playbook always run before the roles section, not after.
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This EX294 practice question is part of Courseiva's free Red Hat certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the EX294 exam.