EX294 Implement advanced Ansible automation Practice Question
A playbook uses a variable named `db_port` that must be defined by the user at runtime, but should fall back to 5432 if the user does not provide it. Which approach ensures this behavior without failing the play when the variable is undefined?
⚠ Common exam trap
The trap here is assuming that defining a variable in group_vars or using vars_prompt with a default is equivalent to a runtime fallback filter.
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
✓
Use the `default` filter: `{{ db_port | default(5432) }}`.
The `default` filter is the correct mechanism because it supplies a fallback only when the variable is undefined, allowing user-provided values to take precedence. It avoids interactive prompts and precedence conflicts, and it works in any templated context. The other options either force a value, require interaction, or fail to provide a value at all.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Use the `default` filter: `{{ db_port | default(5432) }}`.
Why this is correct
The `default` filter returns the specified fallback value when the variable is undefined, which directly satisfies the requirement. It does not error on undefined variables, so the play continues. Using it in a template or module argument such as `port: "{{ db_port | default(5432) }}"` provides a safe default. This is the idiomatic Ansible way to handle optional variables with fallback values.
- ✗
Define `db_port` in `group_vars/all.yml` with a value of 5432.
Why it's wrong here
Setting a default in `group_vars/all.yml` makes the variable always defined, so the user cannot easily override it without higher precedence. It also does not handle the case where the user provides the variable via extra vars or inventory, because group_vars may override or conflict. This approach lacks the dynamic fallback behavior and can lead to unexpected precedence issues.
- ✗
Reference `db_port` directly and set `ignore_errors: true` on the task.
Why it's wrong here
`ignore_errors` only suppresses task failure after execution; it does not supply a value for an undefined variable. The templating engine will still fail with an undefined variable error before the task runs. Ignoring errors can mask real problems and does not provide the fallback value, so the play may behave unpredictably.
- ✗
Use `vars_prompt` to ask for `db_port` with a `default` keyword set to 5432.
Why it's wrong here
`vars_prompt` always prompts the user interactively, which is unsuitable for automated runs and does not provide a silent fallback when the user simply omits input. It also fails in non-interactive contexts such as CI pipelines. While it supports a `default` value, it still requires user interaction, which is not the desired behavior.
About these practice questions
Courseiva writes every EX294 question from scratch — 392 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Red Hat exam blueprint
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.