Red Hat Certified Engineer EX294 EX294 Questions 376–392 | Page 6/6

376

Multi-Selectmedium

An administrator is designing a rolling update playbook for a 20-node application cluster. The playbook must limit the blast radius of failures and allow the rollout to pause safely if too many hosts fail. Which two Ansible play-level keywords directly control how many hosts are updated at once and whether the play aborts based on failures? (Choose two.)

Select 2 answers

A.forks

B.serial

C.order

D.any_errors_fatal

E.max_fail_percentage

AnswersB, E

serial defines the number or percentage of hosts processed per batch during a rolling update. In this scenario it directly controls how many of the 20 nodes are updated at one time, limiting the blast radius and ensuring the play progresses in controlled groups rather than all at once.

Why this answer

serial controls how many hosts are processed in each rolling batch, directly limiting the blast radius. max_fail_percentage defines the failure threshold per batch that aborts the play, preventing the rollout from continuing when too many hosts fail. Together they provide the two controls the administrator needs for a safe rolling update.

Exam trap

The trap here is confusing parallelism controls like forks with rolling-update controls like serial and max_fail_percentage.

Full explanation →

377

MCQhard

An automation team uses Ansible Automation Platform to manage a large number of servers. They need to ensure that sensitive data such as passwords and API keys are not stored in plain text in playbooks or inventory files. They decide to use Ansible Vault to encrypt these secrets. Which of the following best describes how Ansible Vault integrates with playbook execution to protect secrets at runtime?

A.Ansible Vault decrypts secrets on the control node at runtime and passes the decrypted values to managed nodes as needed.

B.Ansible Vault stores secrets in an encrypted keyring on the control node and retrieves them only when explicitly requested by a task.

C.Ansible Vault decrypts secrets on the managed node and stores them in memory only during task execution.

D.Ansible Vault encrypts secrets on the control node and decrypts them on the managed node using a shared vault password.

AnswerA

Ansible Vault operates on the control node. When a playbook references a vault-encrypted file, Ansible decrypts it using the provided vault password. The decrypted variables are then available during playbook execution and are passed to managed nodes as part of task parameters when required. This ensures secrets are not stored in plain text in the repository while still allowing them to be used in automation.

Why this answer

Ansible Vault decrypts encrypted files on the control node when the playbook runs, using the vault password supplied via command line or configuration. The decrypted variables are then used in playbook execution and can be passed to managed nodes as needed. This keeps secrets encrypted at rest in source control while enabling their use in automation.

The other options incorrectly place decryption on managed nodes or describe non-existent keyring features.

Exam trap

The trap here is assuming that managed nodes perform decryption or that a shared vault password is used on managed nodes, when in fact decryption only happens on the control node.

Full explanation →

378

MCQhard

You are building an execution environment using ansible-builder with a definition that includes a base image and a list of collections. During the build, you need to run a custom shell command to install an additional system package that is not available via the standard package manager configuration. Which section of the execution-environment.yml file should you use to add this custom build step?

A.options

B.dependencies

C.additional_build_steps

D.build_arg_defaults

AnswerC

The additional_build_steps section in execution-environment.yml allows you to insert custom commands at various stages of the build process, such as before or after specific steps. You can define commands to run before assembling the final image, enabling installation of system packages or other customizations that are not covered by the standard dependencies.

Why this answer

The additional_build_steps section is designed to inject custom commands into the execution environment build process. It supports stages like prepend_base, append_base, prepend_galaxy, etc., allowing you to run shell commands before or after key build phases. This is the correct way to install system packages or perform other customizations that are not handled by the standard dependencies section.

Exam trap

The trap here is assuming that the dependencies section can handle arbitrary system package installation, when in fact it only supports package lists from repositories and cannot run custom commands.

Full explanation →

379

MCQmedium

A team uses execution environments (EE) for job templates. The admin builds a custom EE using `ansible-builder` with a `execution-environment.yml` file that includes a `base_image: registry.redhat.io/ansible-automation-platform-21/ee-minimal-rhel8:latest` and a custom Python requirement. However, the controller reports that the EE is not found when launching a job. What is the most likely issue?

A.The built EE image was not pushed to the container registry specified in the controller's execution environment configuration.

B.The base image is pointing to an incorrect registry path.

C.The custom Python requirement needs to be added to `requirements.txt` in the project.

D.The execution environment does not include a `Containerfile` for the build process.

AnswerA

Ansible-builder produces the EE image locally, but the controller resolves EEs from a configured container registry. Unless the image is pushed there, the controller cannot pull it, producing the 'not found' error despite a successful build.

Why this answer

After building a custom execution environment with `ansible-builder`, the resulting container image must be pushed to a container registry that the Automation Controller is configured to access. The controller does not automatically pull images from the local build cache; it references the image by its registry path. If the image is not present in the specified registry, the controller will report that the EE is not found when launching a job.

Exam trap

The trap here is that candidates assume building the image locally is sufficient, but the controller requires the image to be accessible via a registry pull, not from the local build cache.

How to eliminate wrong answers

Option B is wrong because `registry.redhat.io/ansible-automation-platform-21/ee-minimal-rhel8:latest` is a valid Red Hat registry path for the minimal execution environment; the issue is not about an incorrect registry path but about the image not being available in the registry the controller queries. Option C is wrong because custom Python requirements are defined in the `execution-environment.yml` file under the `python` key, not in a project's `requirements.txt`; the controller does not read project files for EE dependencies. Option D is wrong because `ansible-builder` automatically generates a `Containerfile` (or `Dockerfile`) during the build process based on the `execution-environment.yml`; the absence of a pre-existing `Containerfile` is not the issue.

Full explanation →

380

MCQeasy

An organization wants to deploy Ansible Automation Platform 2.x in a highly available configuration. Which component must be deployed in an active-active cluster to ensure controller failover?

A.PostgreSQL database

B.Automation controller

C.Private Automation Hub

D.Automation mesh

AnswerB

Automation controller nodes form an active-active cluster behind a load balancer, so any node can accept and execute jobs; if one fails, the remaining nodes continue running playbooks without manual intervention. This satisfies the stem's controller failover requirement, since the control plane itself must be redundant rather than relying on a single instance.

Why this answer

The automation controller is the component that provides the web UI, REST API, and job execution management in Ansible Automation Platform 2.x. For high availability, multiple controller nodes must be deployed in an active-active cluster behind a load balancer, ensuring that if one controller fails, another can immediately take over without service interruption.

Exam trap

The trap here is that candidates often confuse the automation mesh (which provides execution node redundancy) with the automation controller's active-active clustering, leading them to select mesh as the answer for controller failover.

How to eliminate wrong answers

Option A is wrong because PostgreSQL database is typically deployed as a separate highly available database cluster (e.g., using Patroni or streaming replication) and is not itself part of the active-active controller cluster; it supports the controller but does not provide controller failover. Option C is wrong because Private Automation Hub is a content distribution component for collections and execution environments, and it does not handle controller job scheduling or API requests; it can be made highly available independently but does not ensure controller failover. Option D is wrong because Automation mesh is a communication layer for distributing execution workloads across nodes and is not a controller component; it provides resilience for execution nodes but does not handle controller failover.

Full explanation →

381

Multi-Selectmedium

An Ansible playbook uses the "community.general" collection to manage firewall rules. The engineer wants to use a lookup plugin to fetch the current IPv4 address of a host to include in a dynamic inventory script. Which TWO of the following options correctly describe the usage of lookup plugins in Ansible?

Select 2 answers

A.Lookup plugins are always executed on the remote host.

B.Lookup plugins must be imported using the "lookup" keyword.

C.Lookup plugins are executed on the control node and return data to the Ansible controller.

D.The "file" lookup plugin reads the content of a file from the remote host.

E.Lookup plugins can be used in "vars" sections of a playbook.

AnswersC, E

Correct; they fetch data on the control node.

Why this answer

Lookup plugins in Ansible are designed to run on the control node (the machine where Ansible is executed), not on the remote host. They fetch data from external sources (e.g., files, databases, environment variables) and return that data to the Ansible controller for use in playbooks or inventory scripts. This aligns with the requirement to fetch the current IPv4 address of a host for a dynamic inventory script, as the lookup plugin can query local or network sources without needing to execute on the target host.

Exam trap

The trap here is that candidates often confuse lookup plugins (control node execution) with modules (remote host execution), or mistakenly think the 'lookup' keyword is a special Ansible keyword rather than a Jinja2 function, leading them to select options A or B.

Full explanation →

382

MCQhard

You are managing a large infrastructure of 500 Linux servers. The servers are divided into groups: 'web', 'app', and 'db'. Each group has specific configuration requirements. You have developed a set of Ansible roles to manage these configurations. Recently, you noticed that when you run the playbook against all servers, the 'web' role is applied to 'app' servers due to a variable misconfiguration. The playbook uses include_role with a variable that determines which role to apply. The variable is defined in group_vars/all.yml as 'server_role: web'. However, each group should have its own role: 'web' for web servers, 'app' for app servers, 'db' for db servers. The playbook includes the role based on '{{ server_role }}'. What is the best course of action to fix this issue without modifying the playbook structure?

A.Change the variable in group_vars/all.yml to a list and use 'include_role' with loop.

B.Add a 'when' condition to the include_role task to check the group name.

C.Define the server_role variable in group_vars/web.yml, group_vars/app.yml, and group_vars/db.yml with the appropriate values.

D.Define the server_role in host_vars for each server.

AnswerC

Defining `server_role` in each group's `group_vars` file exploits Ansible's variable precedence: group-specific variables override the `group_vars/all.yml` default, so each host resolves `{{ server_role }}` to its own group's role. This satisfies the constraint of fixing the misconfiguration without altering the playbook's `include_role` structure.

Why this answer

Ansible's variable precedence dictates that group_vars/<group_name>.yml files override group_vars/all.yml for hosts in that group. By defining `server_role` per group file (web, app, db), each server gets the correct role without modifying the playbook structure. This leverages Ansible's built-in group variable inheritance to resolve the misconfiguration cleanly.

Exam trap

The trap here is that candidates may think a `when` condition or modifying the playbook is necessary, but the question tests understanding of Ansible's variable precedence and the correct use of group_vars to override all.yml without altering the playbook structure.

How to eliminate wrong answers

Option A is wrong because changing `server_role` to a list and looping `include_role` would apply multiple roles to each server, not fix the single-role misassignment; it also unnecessarily complicates the playbook. Option B is wrong because adding a `when` condition requires modifying the playbook structure, which the question explicitly forbids, and it would not leverage Ansible's variable precedence. Option D is wrong because defining `server_role` in `host_vars` for each of 500 servers is impractical and violates the DRY principle; group_vars is the correct scope for group-specific variables.

Full explanation →

383

MCQmedium

A Red Hat Certified Engineer is managing an Ansible inventory that includes a mix of Linux and network devices. The network devices are running Cisco IOS and require the network_cli connection plugin. The engineer needs to specify the username and password for these devices in the inventory. Which inventory variables should be used to provide the credentials for the network devices?

A.ansible_winrm_user and ansible_winrm_password

B.ansible_user and ansible_password

C.ansible_ssh_user and ansible_ssh_pass

D.ansible_network_user and ansible_network_password

AnswerB

For network devices using the network_cli connection plugin, Ansible uses the standard ansible_user and ansible_password variables to authenticate. These can be set in the inventory file, group_vars, or host_vars. This allows the engineer to define credentials for the network devices without modifying the playbook.

Why this answer

The network_cli connection plugin relies on ansible_user and ansible_password for authentication. These variables are set in the inventory or group_vars and are used by the plugin to establish connections to network devices, ensuring proper credential management.

Exam trap

The trap here is assuming that network devices require special variables like ansible_network_user, when in fact they use the standard ansible_user and ansible_password.

Full explanation →

384

MCQhard

In OpenShift, a deployment must gradually shift traffic to new pods during a rolling update. Which default strategy achieves this?

A.Blue-green deployment

B.RollingUpdate

C.Canary deployment

D.Custom strategy

E.Recreate

AnswerB

RollingUpdate is the Deployment strategy that replaces pods incrementally, keeping a configurable maxUnavailable and maxSurge so traffic shifts gradually to new pods while old ones terminate. This satisfies the stem's requirement for a gradual traffic shift during update, unlike Recreate, which stops all pods first.

Why this answer

The RollingUpdate strategy is the default deployment strategy in OpenShift (and Kubernetes) that gradually replaces old pods with new ones while maintaining application availability. It achieves this by incrementally scaling down the old ReplicaSet and scaling up the new one, controlled by parameters like maxSurge and maxUnavailable, ensuring a smooth transition of traffic to new pods.

Exam trap

The trap here is that candidates often confuse the default OpenShift deployment strategy with advanced deployment patterns like blue-green or canary, which are not built-in defaults but require additional configuration, leading them to select those incorrect options.

How to eliminate wrong answers

Option A is wrong because blue-green deployment is not a default strategy in OpenShift; it requires manual configuration or additional tooling (e.g., Routes and Services) to switch traffic between two separate environments. Option C is wrong because canary deployment is not a built-in default strategy; it involves routing a small percentage of traffic to new pods via custom configurations or service mesh features like Istio, not a native OpenShift deployment strategy. Option D is wrong because 'Custom strategy' is not a valid default deployment strategy in OpenShift; the platform only supports RollingUpdate and Recreate as native strategies, with custom behavior achievable via parameters but not as a named default.

Option E is wrong because Recreate is an alternative strategy that terminates all old pods before creating new ones, causing downtime, and is not the default for gradual traffic shifting.

Full explanation →

385

Multi-Selecthard

An organization uses Ansible Automation Platform to manage a large infrastructure. They need to implement security best practices for managing secrets and credentials. Which TWO of the following actions should they take to enhance security? (Choose two.)

Select 2 answers

A.Disable logging for all playbook runs to prevent any possibility of secrets being logged.

B.Use Ansible Vault to encrypt sensitive variables and files before committing them to source control.

C.Store all secrets in plain text in the Git repository to simplify version control.

D.Share the vault password among all team members via email to ensure everyone can run playbooks.

E.Configure automation controller credentials to use external secret management systems like HashiCorp Vault or CyberArk.

AnswersB, E

Ansible Vault encrypts sensitive data at rest, allowing safe storage in source control. By encrypting variables and files, the organization ensures that secrets are not exposed in plain text. This is a recommended best practice for managing secrets in Ansible. It integrates seamlessly with playbook execution, decrypting only at runtime with the proper password.

Why this answer

Using Ansible Vault to encrypt sensitive data before committing to source control and integrating automation controller with external secret management systems are two key best practices. They ensure secrets are encrypted at rest and managed centrally with access controls. Storing secrets in plain text, disabling all logging, or sharing vault passwords insecurely are harmful practices that would weaken security.

These two actions align with the principle of least privilege and defense in depth.

Exam trap

The trap here is thinking that disabling all logging or sharing vault passwords insecurely might be acceptable shortcuts, when they actually undermine security.

Full explanation →

386

MCQmedium

An Ansible playbook sets 'serial: 20%' for rolling updates, but the inventory contains 5 hosts. How many hosts are updated simultaneously?

A.1

B.2

C.3

D.0

E.5

AnswerA

Serial accepts a percentage, which Ansible converts to a host count by rounding up fractional results. Twenty percent of five hosts equals one, so a single host is updated per batch, giving strictly sequential updates across the inventory.

Why this answer

When 'serial: 20%' is set in an Ansible playbook, the percentage is calculated based on the total number of hosts in the inventory. With 5 hosts, 20% of 5 equals 1.0, which is rounded down to 1. Therefore, only 1 host is updated at a time during the rolling update.

Exam trap

The trap here is that candidates often assume percentages are rounded up or that a fractional result like 1.0 would be treated as 2, but Ansible uses floor rounding (truncation) for serial batch sizes, and with exactly 1.0, the result is 1, not 2.

How to eliminate wrong answers

Option B is wrong because 2 would represent 40% of 5 hosts, not 20%. Option C is wrong because 3 would be 60% of the inventory, far exceeding the 20% specification. Option D is wrong because 0 would only occur if the percentage rounded down to zero (e.g., less than 1 host), but 20% of 5 is exactly 1.0, which rounds to 1.

Option E is wrong because 5 would represent 100% of the hosts, which would be a serial value of '100%' or 'serial: 5', not '20%'.

Full explanation →

387

MCQeasy

An Ansible playbook retrieves a JSON response from an API and stores it in the variable `api_response`. The JSON structure is a list of objects, each with keys `name`, `status`, and `id`. The team needs to create a list of names for objects where status is 'active'. Which filter should be used?

A.{{ api_response | json_query("status=active.name") }}

B.{{ api_response | flatten }}

C.{{ api_response | subelements('name') }}

D.{{ api_response | selectattr('status', 'equalto', 'active') | map(attribute='name') | list }}

AnswerD

selectattr filters the list to objects whose status equals active, then map extracts the name attribute from each match, and list materialises the result. This chains the exact predicates needed, unlike map alone or json_query alternatives.

Why this answer

It uses `selectattr` to filter the list of objects to only those where `status` equals 'active', then `map` to extract the `name` attribute from each filtered object, and finally `list` to convert the result into a list. This is the standard Ansible approach for filtering a list of dictionaries and extracting specific keys.

Exam trap

The trap here is that candidates often confuse `json_query` with `selectattr`/`map` and attempt to use JMESPath syntax incorrectly, or they pick `flatten` or `subelements` because they sound related to list manipulation, without understanding their specific purposes.

How to eliminate wrong answers

Option A is wrong because `json_query` uses JMESPath syntax, which requires a query like `[?status=='active'].name` — the given syntax `status=active.name` is invalid and would cause an error. Option B is wrong because `flatten` is used to reduce nested lists into a single flat list, not to filter or extract attributes from a list of objects. Option C is wrong because `subelements` is designed to iterate over sub-elements of a list of dictionaries (e.g., a list of users each with a list of groups), not to filter or map attributes from a flat list of objects.

Full explanation →

388

MCQmedium

An Ansible playbook runs tasks on a group of web servers. During a rolling update, the playbook should ensure that no more than 2 servers are taken out of service at the same time. Which play keyword should be used?

A.forks: 2

B.max_fail_percentage: 2

C.throttle: 2

D.serial: 2

AnswerD

The serial keyword controls how many hosts Ansible targets per batch, so serial: 2 limits the rolling update to two servers at a time. This satisfies the constraint that no more than two servers leave service simultaneously.

Why this answer

The `serial` keyword controls the batch size of hosts that Ansible executes a play against. Setting `serial: 2` ensures that only 2 web servers are processed at a time, which is exactly what is needed for a rolling update where no more than 2 servers should be taken out of service simultaneously.

Exam trap

The trap here is confusing `serial` (which controls batch size of hosts) with `forks` (which controls parallelism of task execution), leading candidates to pick `forks: 2` thinking it limits concurrency, when in fact it only limits the number of parallel task processes, not the number of hosts taken out of service simultaneously.

How to eliminate wrong answers

Option A is wrong because `forks: 2` sets the number of parallel processes Ansible uses to execute tasks across all hosts, but it does not limit the batch size of hosts that are taken out of service; with forks, all hosts can still be targeted in parallel up to the fork limit, which could take more than 2 servers out of service at once. Option B is wrong because `max_fail_percentage: 2` defines the maximum percentage of hosts that can fail before the playbook aborts, not the number of hosts processed concurrently. Option C is wrong because `throttle: 2` limits the number of concurrent task executions across a play or role, but it applies to individual tasks rather than controlling the batch size of hosts in a rolling update scenario.

Full explanation →

389

MCQhard

You are designing a rolling update for a stateful service where each node must be removed from a load balancer, updated, and re-added before the next node is touched. The update must never take more than one node offline at a time, and if the update fails on a node, the play must stop and leave the remaining nodes untouched. Which playbook configuration achieves this?

A.serial: 1 with ignore_errors: true on the update task so the play can continue to the next node.

B.serial: 1 with any_errors_fatal: true and tasks ordered to drain, update, and re-add within the same play.

C.serial: 2 with max_fail_percentage: 50 so that one failure in a batch is tolerated and the play continues.

D.serial: 1 with run_once: true on the drain and re-add tasks so they execute only once per batch.

AnswerB

serial: 1 processes one host per batch, guaranteeing that only one node is offline at a time. any_errors_fatal: true ensures that a failure on that node stops the entire play, leaving all remaining nodes untouched. Ordering drain, update, and re-add within the same play keeps the node out of rotation only during its own update.

Why this answer

Ensuring only one node is offline at a time and halting on failure requires a batch size of one and play-level fatal error handling. serial: 1 isolates each node, while any_errors_fatal: true stops the play immediately on any failure, leaving the remaining nodes untouched and still in rotation.

Exam trap

The trap here is thinking that ignore_errors or a failure percentage provides safety, when both allow the rollout to continue and risk taking additional nodes offline after a failure.

Full explanation →

390

MCQhard

An admin attempts to build an execution environment using the exhibited files. The build fails with an error about incompatible Python dependency. What is the most likely cause?

A.The Python requirements.txt tries to install a version of Ansible that conflicts with the version in the base image.

B.The execution-environment.yml file uses incorrect syntax for the 'dependencies' section.

C.The collections in requirements.yml are not fully qualified.

D.The base image 'ee-minimal-rhel8' is not a valid execution environment base image.

AnswerA

The base execution environment image already ships a pinned ansible-core version; requirements.txt requesting a different version forces pip to resolve an incompatible set, so the build aborts with a dependency conflict rather than installing cleanly.

Why this answer

The build fails because the Python `requirements.txt` file attempts to install a version of Ansible that conflicts with the version already present in the base image `ee-minimal-rhel8`. Execution environments are designed to include a specific Ansible version in the base image; adding a different version via pip creates a dependency conflict that breaks the build.

Exam trap

The trap here is that candidates often assume the error is due to syntax or invalid base images, but the question specifically mentions 'incompatible Python dependency,' which directly points to a version conflict in the pip requirements.

How to eliminate wrong answers

Option B is wrong because the `execution-environment.yml` file syntax for the 'dependencies' section is correct as shown in the exhibit (it uses a list of file references). Option C is wrong because collections in `requirements.yml` do not need to be fully qualified; they can be specified with just the collection name, and the build would still succeed. Option D is wrong because `ee-minimal-rhel8` is a valid Red Hat-provided execution environment base image, and the error message specifically points to a Python dependency conflict, not an invalid base image.

Full explanation →

391

Multi-Selecteasy

A systems administrator is securing Ansible automation. Which two practices help protect sensitive data in playbooks? (Choose two.)

Select 2 answers

A.Use ansible-vault to encrypt variable files.

B.Set the no_log flag on tasks that handle sensitive data.

C.Use the debug module with verbosity to output passwords.

D.Avoid using become: yes on tasks that access secrets.

E.Store credentials in plain text in the inventory.

AnswersA, B

Encrypting variable files with ansible-vault protects sensitive data at rest, satisfying the requirement to secure credentials within playbooks. Vault-encrypted files remain usable during execution once the vault password is supplied, so secrets are never stored in plaintext in the repository or on disk.

Why this answer

Option A is correct because ansible-vault encrypts sensitive files such as variable files (for example, vars.yml or group_vars files), so secrets like passwords and API keys are stored in ciphertext rather than readable plain text, and they can be decrypted at runtime with a vault password. Option B is correct because setting no_log: true on a task suppresses logging of that task's command output and arguments, preventing sensitive values such as passwords or tokens from being written into Ansible logs or console output. Option C is incorrect because using the debug module with increased verbosity would print sensitive values such as passwords to output, which is the opposite of protecting them.

Option D is incorrect because avoiding become: yes does not protect secrets; privilege escalation is unrelated to whether sensitive data is encrypted or hidden, and become is often legitimately needed for secure tasks. Option E is incorrect because storing credentials in plain text in the inventory exposes them directly and is a classic insecure practice, not a protection measure.

Exam trap

The trap here is that candidates often confuse `no_log` with encryption, thinking it protects data at rest, when it only prevents output from being displayed in logs, while `ansible-vault` provides actual file-level encryption.

Full explanation →

392

MCQeasy

A playbook uses `{{ my_var | default('fallback') }}`. What is the effect?

A.If `my_var` is defined but empty, the expression evaluates to 'fallback'.

B.If `my_var` is defined but equal to None, the expression evaluates to 'fallback'.

C.The filter raises an error because 'default' is not a valid filter.

D.If `my_var` is undefined, the expression evaluates to 'fallback'.

AnswerD

The Jinja2 default filter returns its argument only when the preceding variable is undefined; otherwise the variable's value passes through unchanged. So an undefined my_var yields 'fallback', while a defined my_var keeps its own value.

Why this answer

The `default` filter in Ansible (also known as `d()`) returns the specified fallback value only when the variable is undefined. If `my_var` is defined but empty or None, the filter returns the variable's value (empty string or None), not the fallback. This behavior is specific to the `default` filter's default mode; to also catch empty or None values, you must use `default('fallback', true)`.

Exam trap

The trap here is that candidates often confuse 'undefined' with 'falsy' (empty, None, 0), assuming the default filter replaces all falsy values, but Ansible's default filter only triggers on undefined variables unless the `true` parameter is explicitly added.

How to eliminate wrong answers

Option A is wrong because if `my_var` is defined but empty, the `default` filter without the `true` parameter returns the empty string, not 'fallback'. Option B is wrong because if `my_var` is defined and equal to None, the filter returns None (since None is a defined value), not 'fallback'. Option C is wrong because `default` is a valid Jinja2 filter that Ansible inherits; it does not raise an error.

Full explanation →

Red Hat Certified Engineer EX294 (EX294) — Questions 376–392