EX294 Transform data with filters and plugins Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  {{ my_var | mandatory }}

  Why it's wrong here

  mandatory raises an error when the variable is undefined rather than supplying a fallback, so it cannot prevent the failure. It is tempting because it is a genuine Jinja2 filter for enforcing that a variable must be defined, and would be correct when you want the play to fail loudly instead of silently using a default.

• ✓

  {{ my_var | default('fallback') }}

  Why this is correct

  The default filter substitutes 'fallback' when my_var is undefined, preventing the undefined-variable error. It resolves the stem's problem because group_vars/all.yml evidently is not being loaded for this host, so the variable never reaches the template.

• ✗

  {{ my_var | ternary('yes', 'no') }}

  Why it's wrong here

  The ternary filter selects between two values based on a condition; it does not supply a fallback when the variable is undefined, so the undefined error persists. It is tempting because ternary is genuinely used for conditional value selection, and would be correct when my_var is defined and you must choose between two outputs.

• ✗

  {{ my_var | dflt('fallback') }}

  Why it's wrong here

  dflt is not a valid Ansible filter; the correct name is default (or its alias d), so this expression raises a template error rather than substituting a fallback. It is tempting because the abbreviation resembles the real filter, which would be correct when my_var may be undefined and a fallback value is required.

Go deeper

Related to this question