Red Hat Certified Engineer EX294 EX294 Questions 151–225 | Page 3/7

151

MCQmedium

An engineer runs the playbook as shown: ```yaml - hosts: all tasks: - block: - name: configure firewall command: /bin/false - name: enable service service: name=httpd enabled=yes - name: start service service: name=httpd state=started - hosts: all tasks: - name: next task debug: msg="Continuing to next play" ``` What is the expected result?

A.Only the 'configure firewall' task is executed; the rest are skipped.

B.The 'configure firewall' task is executed, the 'enable service' task is skipped, and the playbook continues to the next play.

C.All tasks are executed and the playbook completes successfully.

D.The 'configure firewall' and 'enable service' tasks are executed; the 'start service' task is skipped.

AnswerB

Answered 'y' for configure firewall, 'n' for enable service (skipped), and 'c' for start service (continue to next play).

Why this answer

The playbook includes a block containing only the 'configure firewall' task. When this task fails and no rescue block is defined, the play fails immediately. The playbook then moves to the next play, skipping any remaining tasks in the current play, including the 'enable service' task.

Thus, 'configure firewall' is executed, 'enable service' is skipped, and the playbook continues to the next play.

Exam trap

The EX294 exam often tests the misconception that the `always` block is mandatory or that tasks after a rescue block will still execute, but in reality, the play moves to the next play after the rescue, skipping subsequent tasks in the same play.

How to eliminate wrong answers

Option A is wrong because the 'configure firewall' task is executed, but the rescue block ensures the 'enable service' task runs after the failure, not skipped entirely. Option C is wrong because the 'configure firewall' task fails, so not all tasks are executed; the 'start service' task is skipped due to the play moving to the next play. Option D is wrong because the 'start service' task is not executed; it is skipped because the rescue block does not include it, and the playbook continues to the next play after the rescue.

Full explanation →

152

MCQmedium

A team uses Ansible to update a database cluster with one primary and two replicas. The goal is zero downtime. Which update order is the safest?

A.Update replicas first, then the primary.

B.Update in random order.

C.Update all nodes simultaneously.

D.Update the primary first, then replicas.

AnswerA

Correct. Replicas are updated first, then the primary after confirmation.

Why this answer

Updating replicas first ensures that if the update introduces a regression, it affects only the read-only replicas, which can be quickly rolled back without impacting write availability. Once replicas are confirmed healthy, the primary is updated and a controlled failover (e.g., using `patronictl switchover` or `repmgr standby switchover`) promotes a replica to primary, minimizing downtime to seconds. This order aligns with the principle of reducing blast radius and maintaining quorum in a cluster.

Exam trap

The trap here is that candidates assume updating the primary first is safer because it is the 'source of truth,' but in a clustered environment with zero-downtime requirements, updating replicas first is the standard practice to preserve write availability and allow safe rollback.

How to eliminate wrong answers

Option B is wrong because updating in random order risks updating the primary first, causing a write outage if the update fails, and may break replication consistency if replicas are updated before the primary without a controlled failover. Option C is wrong because updating all nodes simultaneously can cause a complete cluster outage if the update introduces a bug, and it violates the zero-downtime requirement by potentially losing quorum or causing split-brain scenarios. Option D is wrong because updating the primary first forces a failover to a replica that still runs the old version, which may be incompatible with the updated primary's data format or replication protocol, leading to replication lag or cluster instability.

Full explanation →

153

MCQeasy

A playbook uses the 'block' feature to group tasks and includes a 'rescue' section. If a task inside the block fails, what happens?

A.The rescue tasks run, and then the entire playbook fails.

B.The rescue tasks run, and the play continues with the next task after the block.

C.The rescue tasks are ignored and the play fails immediately.

D.The block is re-executed after rescue.

AnswerB

Correct: This is the standard behavior of block/rescue in Ansible.

Why this answer

In Ansible, when a task inside a `block` fails, the `rescue` section is executed to handle the failure. After the rescue tasks complete successfully, the play continues with the next task after the block, not from the beginning of the block. This behavior allows for error recovery without terminating the entire play.

Exam trap

The trap here is that candidates often confuse `rescue` with a retry mechanism, thinking it re-executes the block, or they assume that any failure in the block immediately fails the entire play, ignoring the rescue capability.

How to eliminate wrong answers

Option A is wrong because after the rescue tasks run, the play does not fail; it continues with the next task after the block, unless the rescue tasks themselves fail. Option C is wrong because the rescue tasks are not ignored; they are specifically designed to run when a task in the block fails, and the play does not fail immediately unless the rescue tasks also fail. Option D is wrong because the block is not re-executed after rescue; the rescue section runs once, and then execution proceeds to the task after the block.

Full explanation →

154

MCQeasy

A user wants to run a playbook that uses a module from 'myorg.mycollection'. The playbook is located in /home/user/projects. Which of the following is true about the collection discovery?

A.The user must set the ANSIBLE_COLLECTIONS_PATH environment variable.

B.The collection is not installed, so the playbook will fail.

C.Ansible will look only in /usr/share/ansible/collections.

D.Ansible will automatically find the collection in the default search path.

AnswerD

Ansible searches ~/.ansible/collections by default.

Why this answer

Ansible automatically searches for collections in the default search path, which includes the collections directory adjacent to the playbook. Since the playbook is located in /home/user/projects, Ansible will look in /home/user/projects/collections/ansible_collections/myorg/mycollection, among other default paths, without requiring any environment variable or manual configuration.

Exam trap

The trap here is that candidates often assume a collection must be installed system-wide or require an environment variable, but Ansible's default search path automatically includes the playbook-adjacent collections directory, making local collection discovery seamless.

How to eliminate wrong answers

Option A is wrong because the ANSIBLE_COLLECTIONS_PATH environment variable is not required; it is only used to override or extend the default search path, not a mandatory setting. Option B is wrong because the question does not state whether the collection is installed or not; the focus is on discovery, not installation status, and a playbook can succeed if the collection is present in a default path. Option C is wrong because Ansible does not look only in /usr/share/ansible/collections; it also checks the playbook-adjacent collections directory and the user-level ~/.ansible/collections path.

Full explanation →

155

MCQhard

A team uses a single Ansible Tower inventory called 'Production' containing hosts for multiple environments (dev, stage, prod). They want to apply different variables to hosts based on environment. Which inventory structure meets this requirement with minimal administrative overhead?

A.Create groups within the inventory for each environment (e.g., 'dev', 'stage', 'prod') and assign variables at the group level.

B.Assign variables directly to each host using the 'Host Variables' field in the inventory.

C.Add tags to each host and use the tags to filter variables in the job template.

D.Create separate inventories for each environment and link them to the same project.

AnswerA

Groups with group_vars is the standard approach.

Why this answer

Ansible Tower (now Red Hat Ansible Automation Platform) supports group-based variable inheritance within a single inventory. By creating groups for each environment (dev, stage, prod) and assigning variables at the group level, you can apply environment-specific variables to all hosts in that group with minimal administrative overhead. This leverages Tower's built-in group variable mechanism without requiring per-host edits or multiple inventory objects.

Exam trap

The trap here is that candidates often confuse tags (which are for job template filtering and RBAC) with group variables (which are for host-level data), leading them to select option C despite tags having no role in variable assignment.

How to eliminate wrong answers

Option B is wrong because assigning variables directly to each host via the 'Host Variables' field creates significant administrative overhead when managing many hosts, as each host must be individually configured, and it does not scale well for environment-wide changes. Option C is wrong because tags in Ansible Tower are used for job template filtering and access control, not for variable assignment; variables cannot be conditionally applied based on tags within an inventory. Option D is wrong because creating separate inventories for each environment increases administrative overhead by requiring multiple inventory objects to be maintained and linked to the same project, and it does not leverage the single-inventory structure specified in the question.

Full explanation →

156

MCQhard

During a playbook run, the task 'debug: msg={{ ansible_facts.distribution }}' outputs 'CentOS' for a host. However, the host's inventory variable 'distribution' is set to 'RedHat'. The administrator expected the inventory variable to override the fact. What is the most likely cause of this behavior?

A.The 'gather_facts' directive is set to 'no' in the playbook

B.The host variable is defined in a group_var that is overridden by a host_var

C.The ansible_facts dictionary is used, which contains discovered facts that take precedence over inventory variables

D.The playbook uses the variable 'distribution' instead of 'ansible_facts.distribution'

AnswerC

Facts from the system have higher precedence than inventory variables unless using registered variables or setting fact precedence explicitly.

Why this answer

In Ansible, facts discovered by the `setup` module (stored in `ansible_facts`) take precedence over inventory variables when accessed via the `ansible_facts` dictionary. The `debug` task explicitly references `ansible_facts.distribution`, which retrieves the discovered fact value ('CentOS'), not the inventory variable `distribution`. Inventory variables are stored separately and do not override facts within the `ansible_facts` namespace.

Exam trap

The trap here is that candidates confuse the variable precedence hierarchy with the explicit namespace access; they assume inventory variables always override facts, but the `ansible_facts` dictionary is a separate, immutable collection of discovered data that is not overridden by inventory variables.

How to eliminate wrong answers

Option A is wrong because setting `gather_facts: no` would prevent fact discovery entirely, causing the `ansible_facts.distribution` variable to be undefined or raise an error, not output 'CentOS'. Option B is wrong because host_vars always override group_vars in Ansible's variable precedence, but the issue here is not about precedence between inventory variable sources; it's about the explicit use of the `ansible_facts` dictionary, which bypasses inventory variables entirely. Option D is wrong because the playbook uses `ansible_facts.distribution`, not `distribution`; if it used `distribution`, the inventory variable 'RedHat' would have been output, not 'CentOS'.

Full explanation →

157

MCQmedium

Refer to the exhibit. When the playbook runs on target1, which value will nginx_port have in the role?

A.443 (from playbook vars)

B.8080 (from vars/main.yml)

C.9090 (from host vars)

D.80 (from defaults/main.yml)

AnswerC

Host vars have higher precedence than playbook and role vars.

Why this answer

Ansible variable precedence dictates that host variables (in this case, from host_vars) override role defaults, role vars, and playbook vars. Since nginx_port is defined in host_vars for target1 with value 9090, that value takes highest precedence among the listed sources, so the role will use 9090.

Exam trap

Red Hat often tests the misconception that role vars (vars/main.yml) or playbook vars always override host_vars, when in fact host_vars have higher precedence than both role vars and playbook vars.

How to eliminate wrong answers

Option A is wrong because playbook vars have lower precedence than host vars; even though the playbook sets nginx_port to 443, host_vars override it. Option B is wrong because vars/main.yml within a role have lower precedence than host vars; the role's internal variable file sets 8080, but host_vars take priority. Option D is wrong because defaults/main.yml have the lowest precedence in Ansible's variable precedence hierarchy; the default value of 80 is overridden by any higher-precedence definition, including host_vars.

Full explanation →

158

MCQeasy

An Ansible playbook needs to extract the first line from a multi-line string variable 'output' and store it in a new variable 'first_line'. Which filter should be used?

A.{{ output | lines | first }}

B.{{ output | split(' ') | first }}

C.{{ output | first }}

D.{{ output | head(1) }}

AnswerB

Correct: split into lines then take first.

Why this answer

The `split('\n')` filter splits the multi-line string into a list of lines, and the `first` filter extracts the first element. This is the standard Ansible approach to isolate the first line from a string variable.

Exam trap

The trap here is that candidates confuse the `first` filter's behavior on strings vs. lists, assuming it extracts the first line when it actually extracts the first character.

How to eliminate wrong answers

Option A is wrong because `lines` is not a valid Ansible filter; it would cause an undefined filter error. Option C is wrong because `first` applied directly to a string returns the first character, not the first line. Option D is wrong because `head(1)` is not a valid Ansible filter; it is a Jinja2 extension not available by default in Ansible.

Full explanation →

159

Multi-Selectmedium

Which TWO filters can be used to combine two lists into one? (Select exactly two.)

Select 2 answers

A.`zip`

B.`union`

C.`intersect`

D.`combine`

E.`flatten`

AnswersA, B

Correct. The `zip` filter takes two lists and returns a list of tuples, each tuple containing one element from each input list. This combines the two lists into a single list structure.

Why this answer

(`zip`) is correct because the `zip` filter in Ansible combines two lists by pairing elements from each list into a single list of tuples, effectively merging them into one list. Option B (`union`) is correct because it merges two lists into a single list containing all unique elements from both. Option C (`intersect`) is incorrect because it only returns elements common to both lists, not a combination of all elements.

Options D (`combine`) and E (`flatten`) are incorrect: `combine` works on dictionaries, not lists, and `flatten` reduces a nested list structure, it does not combine two lists.

Exam trap

The trap is that candidates might think any filter that operates on two lists and produces one output qualifies as 'combining'. However, `intersect` selects common elements rather than merging all elements. Also, `zip` produces a list of tuples, which some may not consider a true combination because it doesn't merge the elements.

But the question's wording 'combine two lists into one' includes `zip` as it does produce a single list from two inputs.

Full explanation →

160

MCQhard

A playbook uses the 'include_tasks' module to load platform-specific tasks. The playbook fails intermittently with 'Could not find or access file' error on some runs but works on others. Which of the following is the most likely cause?

A.The 'include_tasks' is used inside a block that has 'always' section.

B.The task file path is not absolute and Ansible's search order is inconsistent.

C.The 'include_tasks' is used with a loop and the loop variable shadows the included file's parameter.

D.The playbook uses 'any_errors_fatal: true' causing early exits.

AnswerC

Correct: Variable shadowing can cause the included file's expected variable to be overridden, leading to file lookup failures on some iterations.

Why this answer

When 'include_tasks' is used inside a loop, the loop variable (e.g., 'item') can override or shadow the parameters expected by the included task file. This causes the included file to receive unexpected variable values, leading to incorrect file path resolution and intermittent 'Could not find or access file' errors depending on the loop iteration.

Exam trap

Red Hat often tests the subtle interaction between loop variables and included task file parameters, where candidates mistakenly attribute the intermittent failure to path resolution or error handling rather than variable shadowing.

How to eliminate wrong answers

Option A is wrong because the 'always' section in a block does not affect file path resolution; it only ensures certain tasks run regardless of failure. Option B is wrong because Ansible's search order for relative paths in 'include_tasks' is deterministic (relative to the playbook or role directory), not inconsistent, so this would not cause intermittent failures. Option D is wrong because 'any_errors_fatal: true' stops execution on any failure but does not cause file-not-found errors; it would make failures consistent, not intermittent.

Full explanation →

161

Multi-Selecthard

Which THREE considerations are important when designing a credential strategy in Ansible Automation Platform? (Choose exactly three.)

Select 3 answers

A.All credentials must be stored within the AAP database for security

B.Playbooks should contain hardcoded credentials for simplicity

C.Credentials should be assigned to job templates rather than embedded in playbooks

D.Custom credential types allow integration with external secrets management systems

E.Credential access can be restricted using RBAC on organizations, teams, and users

AnswersC, D, E

Best practice is to manage credentials via AAP and assign them to templates.

Why this answer

Ansible Automation Platform (AAP) best practices dictate that credentials should be assigned to job templates, not embedded in playbooks. This decouples sensitive authentication data from automation logic, allowing credentials to be managed, rotated, and audited centrally through the AAP controller without exposing them in version-controlled playbook files.

Exam trap

The trap here is that candidates often assume all credentials must be stored inside the AAP database for security, but the platform is designed to delegate secret storage to external vaults, and the question tests awareness of that flexibility.

Full explanation →

162

MCQhard

An Ansible playbook uses delegation to run a task on localhost while targeting remote hosts. The task fails with 'connection refused' for the remote host. What is the most likely cause?

A.the remote host is not reachable from the control node

B.the task uses 'connection: local' incorrectly or omits it

C.the playbook lacks 'gather_facts: yes'

D.the delegate host lacks required Python libraries

AnswerB

Correct: when delegating, the connection should be set to local unless using 'delegate_to' with proper connection vars.

Why this answer

'delegate_to: localhost' runs the task locally, but the connection keyword 'ansible_connection' may still refer to remote if not set correctly. Option A is plausible but less common. Options C and D are incorrect.

Full explanation →

163

MCQhard

An administrator wants to define role dependencies. In which file should they place the dependencies declaration?

A.vars/main.yml

B.defaults/main.yml

C.tasks/main.yml

D.meta/main.yml

AnswerD

Role metadata, including dependencies, is defined in meta/main.yml.

Why this answer

Role dependencies in Ansible are declared in the `meta/main.yml` file using the `dependencies` key. This allows you to specify other roles that must be executed before the current role, ensuring prerequisite tasks are run automatically.

Exam trap

The trap here is that candidates often confuse `meta/main.yml` with `tasks/main.yml` or variable files, assuming dependencies are defined in the task list or variable defaults, but Ansible specifically reserves `meta/main.yml` for role metadata including dependencies, author info, and supported platforms.

How to eliminate wrong answers

Option A is wrong because `vars/main.yml` is used to define variables for the role, not dependencies. Option B is wrong because `defaults/main.yml` is used to set default variable values, which have the lowest precedence and are not for dependencies. Option C is wrong because `tasks/main.yml` contains the main list of tasks to execute in the role, not dependency declarations.

Full explanation →

164

MCQeasy

An administrator runs this playbook against a group of 10 web servers. The update fails on the third host (host3) due to a yum error. What is the most likely outcome?

A.Only the first batch (host1 and host2) are updated successfully; the remaining hosts are skipped.

B.All hosts are disabled in HAProxy and the playbook fails.

C.The playbook continues with the remaining hosts because the number of failures (1) is below the 25% threshold.

D.The playbook halts immediately after the failure on host3.

AnswerC

With `max_fail_percentage: 25`, up to 2 failures are allowed out of 10 hosts. One failure does not stop the playbook.

Why this answer

The playbook uses the `serial: 2` directive, which batches hosts in groups of two, and the `max_fail_percentage: 25` setting. With 10 hosts, 25% allows up to 2 failures (2.5 rounded down). Since only one failure occurred (on host3), the playbook continues processing the remaining batches after the failed batch completes.

Exam trap

The trap here is that candidates often confuse `max_fail_percentage` with `any_errors_fatal` or assume a single failure halts the entire playbook, not realizing that Ansible evaluates failures per batch against the total inventory percentage.

How to eliminate wrong answers

Option A is wrong because it assumes the playbook stops after the first batch, but `serial: 2` processes batches sequentially, and `max_fail_percentage: 25` allows failures up to the threshold before aborting; only the failed batch (host3 and host4) is affected, not all remaining hosts. Option B is wrong because HAProxy disabling is not part of the described playbook logic; the question focuses on yum update failure, not load balancer integration. Option D is wrong because `any_errors_fatal` is not set, so the playbook does not halt immediately; it continues with subsequent batches as long as the failure count is below the 25% threshold.

Full explanation →

165

MCQmedium

Refer to the exhibit. A playbook runs against the `web` group. What username will be used for host web2?

A.deploy

B.undetermined

C.admin

D.root

AnswerA

web2 inherits from group vars.

Why this answer

The playbook runs against the `web` group, and host `web2` inherits the `ansible_user` variable from the group-level inventory definition. In Ansible, the `ansible_user` variable determines the SSH username for the connection. Since the exhibit (not shown here but implied) sets `ansible_user: deploy` for the `web` group, all hosts in that group, including `web2`, will use `deploy` as the SSH username unless overridden at the host level.

Exam trap

The trap here is that candidates assume the default SSH user `root` is always used, forgetting that group-level `ansible_user` variables in the inventory explicitly override that default.

How to eliminate wrong answers

Option B is wrong because the username is not undetermined; Ansible resolves the `ansible_user` variable from the group-level inventory, providing a deterministic value. Option C is wrong because `admin` is not the configured `ansible_user` for the `web` group; it would only be used if explicitly set at the group or host level. Option D is wrong because `root` is the default SSH user only when no `ansible_user` is defined, but here the group-level variable overrides that default.

Full explanation →

166

MCQeasy

A junior admin is tasked with creating a playbook that sets a variable 'app_status' to 'starting' if a service file exists, otherwise sets it to 'stopped'. Which filter should be used to test if a file exists from Ansible facts?

A.path

B.exists

C.is_dir

D.file

AnswerD

Correct. The `file` test (e.g., `if mypath is file`) checks if the given path is a file, suitable for this task.

Why this answer

The `file` test in Jinja2 checks whether a path exists as a file, returning a boolean. It can be used directly in `when` conditions like `when: mypath is file`. Option B is incorrect because there is no built-in `exists` filter in Ansible; the `exists` attribute comes from the `stat` module result, not a filter.

The junior admin should use the `file` test or the `stat` module with its `exists` attribute.

Exam trap

Candidates may mistakenly think 'exists' is a filter since the `stat` module returns an `exists` attribute, but it is not a filter. The correct Jinja2 test is `file` (or `is file`).

How to eliminate wrong answers

Option A is wrong because `path` is not a filter; it is a parameter used in modules like `stat` or `file` to specify the target path, not a Jinja2 filter to test existence. Option C is wrong because `is_dir` is a filter that checks if a path is a directory, not if any file exists, so it would return false for a regular file. Option D is wrong because `file` is a module name or a type test (e.g., `is_file`), but there is no standalone `file` filter in Ansible for existence checks; the correct filter is `exists`.

Full explanation →

167

Multi-Selectmedium

Which three of the following are valid methods to pass variables to an Ansible playbook at runtime? (Choose three.)

Select 3 answers

A.Using '--extra-vars' command line option.

B.Using '--ask-vault-pass' and storing variables in encrypted files.

C.Using 'environment' directive in the playbook.

D.Using 'vars_prompt' in the playbook.

E.Using '-e @file' to load variables from a JSON file.

AnswersA, D, E

Correct: This directly passes variables or file paths.

Why this answer

The `--extra-vars` (or `-e`) command-line option allows you to pass variables directly to an Ansible playbook at runtime. This overrides any previously defined variables and can accept key=value pairs or load from JSON/YAML files, making it the primary method for runtime variable injection.

Exam trap

The trap here is confusing variable injection methods with authentication or environment configuration; candidates often mistake `--ask-vault-pass` or `environment` for runtime variable passing, when they serve entirely different purposes in Ansible's architecture.

Full explanation →

168

Multi-Selecteasy

An administrator wants to ensure that Ansible facts gathered from a host are consistent across multiple playbook runs. Which two actions can help achieve this? (Choose two.)

Select 2 answers

A.Use 'gather_facts: no' and manually run 'setup' module with specific filter.

B.Use 'tags' to only gather facts on selective runs.

C.Enable fact caching using 'ansible_cache' plugin with a persistent backend like Redis.

D.Disable fact caching and gather facts every time.

E.Set 'ANSIBLE_GATHERING=smart' and configure cache_timeout.

AnswersC, E

Correct: Caching stores facts between runs, ensuring consistency.

Why this answer

Enabling fact caching with a persistent backend like Redis stores gathered facts between playbook runs, ensuring consistency without re-gathering. Option E is correct because setting 'ANSIBLE_GATHERING=smart' with a configured cache_timeout allows Ansible to reuse cached facts within the timeout period, providing consistent data across runs.

Exam trap

Red Hat often tests the distinction between controlling when facts are gathered (tags, gather_facts: no) versus ensuring consistency across runs (caching), leading candidates to pick options that limit fact collection but do not persist data between executions.

Full explanation →

169

MCQhard

An organization uses Ansible Tower (AWX) for rolling updates. They have a job template that runs a playbook with serial: 5. The inventory contains 50 hosts. The update fails after the first batch due to a syntax error in a playbook. After fixing the error, the administrator wants to resume updating from where it left off without updating already successful hosts. Which approach achieves this?

A.Use the job template survey to input a list of hosts to skip, and pass it as --limit.

B.Create a new job template with a dynamic inventory subset excluding the first batch hosts.

C.Modify the playbook to check if a host has already been updated using a fact and skip it.

D.Rerun the entire playbook; Ansible will skip hosts that are already in the desired state.

AnswerA

Correct. A survey variable can be used in the extra variables or limit field to exclude specific hosts.

Why this answer

Ansible Tower's job template survey can collect a list of hosts to skip, which is then passed as the `--limit` option to the playbook. This allows the administrator to resume the rolling update from the next batch by excluding the first five already-successful hosts, avoiding re-running the playbook on them.

Exam trap

The trap here is that candidates assume Ansible's idempotency will automatically skip already-updated hosts, but in practice, idempotency depends on task design and does not prevent re-execution on successful hosts, which can cause unnecessary load or side effects in rolling updates.

How to eliminate wrong answers

Option B is wrong because creating a new job template with a dynamic inventory subset is cumbersome and error-prone; it requires manual inventory management and does not leverage Tower's built-in survey mechanism. Option C is wrong because modifying the playbook to check a fact for update status is unreliable and violates idempotency best practices; it adds complexity and may not accurately reflect the host state after a failed batch. Option D is wrong because rerunning the entire playbook with serial: 5 would re-execute on the first batch hosts, potentially causing unintended side effects or requiring them to be idempotent; Ansible does not automatically skip hosts based on desired state unless the tasks are idempotent, which is not guaranteed for all operations.

Full explanation →

170

MCQmedium

An Ansible Tower administrator notices that a job template fails intermittently with a 'Host unreachable' error for a specific group of servers. The inventory is static and the host entries have correct IPs. The credential used for SSH is a machine credential with a username and password, and it works for other hosts. Upon checking the job output, the error occurs during the 'Gathering Facts' step. The SSH service on these servers is running and reachable from the Tower node. What is the most likely cause?

A.The credential's SSH private key has a passphrase that is not stored in the credential.

B.The credential type should be 'network' instead of 'machine' for these servers.

C.The inventory group has hosts defined with incorrect hostnames in the ansible_host variable.

D.The SSH service on these servers is bound to a different port than the default 22.

AnswerA

If private key requires passphrase, it must be stored in credential.

Why this answer

The error occurs during the 'Gathering Facts' step, which uses SSH to connect to the managed hosts. If the SSH private key has a passphrase that is not stored in the credential, Ansible Tower cannot decrypt the key to authenticate, causing a 'Host unreachable' error even though the host is actually reachable. The credential works for other hosts only if those hosts are configured to accept password-based authentication, but the failing hosts may require key-based authentication, exposing the missing passphrase.

Exam trap

The trap here is that candidates confuse a network connectivity issue with an authentication failure, assuming 'Host unreachable' always means the host is down or the port is closed, rather than recognizing it can be caused by SSH key decryption failure during the authentication phase.

How to eliminate wrong answers

Option B is wrong because the credential type 'network' is used for network devices (e.g., switches, routers) that use protocols like SSH or SNMP, not for standard Linux servers; 'machine' is the correct type for SSH access to servers. Option C is wrong because the inventory is static and host entries have correct IPs, so the ansible_host variable is not the issue; the error occurs during fact gathering, not during hostname resolution. Option D is wrong because if the SSH service were bound to a different port, the error would consistently fail for all connection attempts, not intermittently, and the host would be unreachable from the start, not just during fact gathering.

Full explanation →

171

MCQeasy

Which command runs a playbook using an execution environment named 'my-ee'?

A.ansible-navigator run playbook.yml --execution-environment my-ee

B.ansible-playbook -i inventory playbook.yml -e 'ansible_python_interpreter=/usr/bin/python3' --ee my-ee

C.ansible-runner run --ee my-ee playbook.yml

D.ansible-navigator run playbook.yml --ee my-ee

AnswerA, D

Correct. This command uses the full flag `--execution-environment` to specify the execution environment 'my-ee'.

Why this answer

Both Option A and Option D are correct because `ansible-navigator run` supports both the full flag `--execution-environment` and its shorthand `--ee` to specify an execution environment. Option A uses the full flag, while Option D uses the shorthand; both are valid. Options B and C are incorrect because `ansible-playbook` does not support execution environments directly, and `ansible-runner` is a different tool typically used in automation controller environments, not directly for running playbooks with execution environments in the same manner.

Exam trap

Candidates may mistakenly think that only `--execution-environment` is valid, but `--ee` is an accepted shorthand. Additionally, they may confuse the commands `ansible-navigator`, `ansible-playbook`, and `ansible-runner`.

How to eliminate wrong answers

Option B is wrong because `ansible-playbook` does not support the `--ee` flag; execution environments are a feature of `ansible-navigator` and `ansible-runner`, not the legacy `ansible-playbook` command. Option C is wrong because `ansible-runner` requires a subcommand like `run` followed by the playbook path, but the syntax `ansible-runner run --ee my-ee playbook.yml` is incorrect; the correct syntax is `ansible-runner run --playbook playbook.yml --container-image my-ee` (or using `--container-option`), and `--ee` is not a valid flag for `ansible-runner`. Option D is wrong because while `ansible-navigator run` does accept `--ee` as a shorthand for `--execution-environment`, the option value must be provided after the flag (e.g., `--ee my-ee`), but the option is missing the value; the command as written would fail because `--ee` requires an argument.

Full explanation →

172

MCQeasy

A junior admin wants to remove a credential from Ansible Tower. Which role-based access control permission is required to delete a credential?

A.Read

B.Use

C.Execute

D.Admin

AnswerD

Admin role allows deletion of credentials.

Why this answer

In Ansible Tower, the Admin role is the only role that grants full management permissions, including the ability to delete credentials. Lower-level roles like Read, Use, and Execute only allow viewing or using credentials, not modifying or deleting them. This aligns with Tower's RBAC hierarchy where Admin is required for destructive actions on any resource.

Exam trap

The trap here is that candidates often confuse the 'Use' role with full management permissions, but 'Use' only allows credential consumption in job templates, not deletion or modification.

How to eliminate wrong answers

Option A is wrong because the Read role only allows viewing credentials, not deleting them. Option B is wrong because the Use role permits using a credential in a job template but does not grant deletion rights. Option C is wrong because the Execute role applies to job templates and projects, not to credential management, and does not include delete permissions.

Full explanation →

173

MCQmedium

A senior automation engineer is optimizing a playbook that processes large amounts of data. The playbook uses the "json_query" filter to filter and extract specific fields from a complex JSON structure returned by an API. The engineer notices that the playbook runs very slowly and consumes a lot of memory. They suspect the json_query filter is inefficient for this use case. The engineer wants to replace json_query with a combination of built-in Ansible filters to improve performance. The JSON structure is as follows: { "servers": [ {"name": "web01", "status": "active", "role": "web"}, {"name": "web02", "status": "active", "role": "web"}, {"name": "db01", "status": "active", "role": "db"} ] } The engineer needs to extract a list of server names where the status is "active" and the role is "web". The current code using json_query is: server_names: "{{ api_result | json_query(\"servers[?status=='active' && role=='web'].name\") }}" Which of the following alternatives uses only Ansible built-in filters (not json_query) and is likely to be more efficient?

A.server_names: "{{ api_result.servers | rejectattr('status', '==', 'active') | rejectattr('role', '==', 'web') | map(attribute='name') | list }}"

B.server_names: "{{ api_result.servers | selectattr('status', 'equalto', 'active') | selectattr('role', 'equalto', 'web') | map(attribute='name') | list }}"

C.server_names: "{{ api_result.servers | selectattr('status', 'is', 'active') | selectattr('role', 'is', 'web') | map(attribute='name') | list }}"

D.server_names: "{{ api_result.servers | selectattr('status', '==', 'active') | selectattr('role', '==', 'web') | map(attribute='name') | list }}"

AnswerD

Correctly filters active and web roles, then extracts names.

Why this answer

It uses selectattr with '==' twice to filter servers where status equals 'active' and role equals 'web', then map to extract names. This approach uses only built-in Ansible filters and avoids JMESPath parsing, making it more efficient for large datasets. Option A uses rejectattr, which would exclude items that match the condition, thus returning the opposite set.

Option B uses 'equalto', which is not a valid operator for selectattr. Option C uses 'is', which is also invalid.

Full explanation →

174

MCQhard

What is the most likely cause of the failure?

A.The inventory must be of type 'file' rather than 'scm'.

B.The source_path is incorrect because it should be a directory, not a file.

C.The source_project should reference the project ID, not name.

D.The update_cache_timeout should be a positive integer.

E.The credential type is incorrect; it should be a Source Control credential, not Machine.

AnswerE

A Machine credential is designed for SSH/WinRM, not for authenticating to a source control system. Using the appropriate credential type is essential.

Why this answer

The credential type must match the service. A Machine credential is used for SSH/WinRM access, not for source control authentication. When using an SCM project to source inventory, the credential should be a Source Control credential (e.g., for Git) to authenticate to the repository.

Option A is incorrect because inventory type 'scm' is valid for sourcing from a project; the failure is credential-related, not inventory type. Option B is incorrect because source_path can point to either a file or a directory within the project. Option C is incorrect because source_project can accept either the project name or ID.

Option D is incorrect because update_cache_timeout=0 is a valid value that disables caching.

Full explanation →

175

MCQhard

An Ansible Tower administrator notices that a job template using a dynamic inventory source from AWS EC2 is not updating when new instances are launched. The inventory source is set to update on launch. What is the most likely cause?

A.The inventory source cache timeout is set too high.

B.The AWS credential associated with the inventory source is invalid or expired.

C.The 'update on launch' option is disabled.

D.The inventory source is configured as a custom script.

AnswerB

Invalid credentials prevent successful inventory sync.

Why this answer

The most likely cause of a dynamic inventory source not updating is that the associated AWS credential is invalid or expired. When the 'update on launch' option is enabled, Ansible Tower attempts to refresh the inventory from the source before each job run. If the credential (e.g., AWS access key ID and secret access key) is no longer valid, the inventory update will fail silently or with an error, and the job will use stale cached data.

Exam trap

The trap here is that candidates often assume the 'update on launch' option is misconfigured or that cache settings are the problem, when in reality the credential validity is the root cause that prevents any update from succeeding.

How to eliminate wrong answers

Option A is wrong because a high cache timeout would cause the inventory to be updated less frequently, but the 'update on launch' option forces a fresh update regardless of the cache timeout setting. Option C is wrong because the question explicitly states that the inventory source is set to update on launch, so this option is factually incorrect. Option D is wrong because a custom script inventory source would not use the AWS EC2 dynamic inventory plugin; the question specifies a dynamic inventory source from AWS EC2, which uses the built-in ec2.py or ec2 plugin, not a custom script.

Full explanation →

176

Multi-Selecthard

A senior engineer needs to debug an Ansible playbook that uses lookups. Which TWO plugins can be used to retrieve data from a file on the control node? (Select exactly two.)

Select 2 answers

A.ini

B.password

C.csvfile

D.file

E.template

AnswersD, E

Reads a file content as a string.

Why this answer

The `file` lookup plugin reads the content of a file from the control node's filesystem and returns it as a string. This is the standard way to retrieve file data directly from the Ansible control node without transferring the file to the managed host.

Exam trap

The trap here is that candidates often confuse lookup plugins with modules, or assume that `ini`, `csvfile`, or `password` can retrieve raw file content, when in fact they are designed for structured data extraction or password generation, not general file reading.

Full explanation →

177

MCQhard

After rotating the Ansible Vault password in the automation controller, several job templates that use vault credentials start failing with 'decryption failed'. The vault credential has been updated with the new password. What is the most likely cause of the failure?

A.The automation controller needs a restart to apply the new vault credential.

B.The vault file in the project repository still uses the old vault password and needs to be re-encrypted with the new password.

C.The vault credential is not linked to the job template correctly.

D.The vault credential type requires the old password to be stored separately.

AnswerB

Vault files must be rekeyed when the password changes.

Why this answer

The vault file itself is encrypted with a specific password. When the vault password is rotated in the automation controller, the vault file stored in the project repository is still encrypted with the old password. The job template uses the vault credential to decrypt the file, but since the credential now holds the new password, decryption fails.

The vault file must be re-encrypted with the new password using `ansible-vault rekey` or by decrypting and re-encrypting it.

Exam trap

The trap here is that candidates assume updating the vault credential in the controller is sufficient, but they overlook that the vault file itself must be re-encrypted with the new password.

How to eliminate wrong answers

Option A is wrong because the automation controller does not require a restart to apply updated vault credentials; credential changes are applied dynamically to subsequent job runs. Option C is wrong because the vault credential is correctly linked to the job template (as stated in the scenario), and the failure is due to a password mismatch, not a linkage issue. Option D is wrong because the vault credential type does not require storing the old password separately; the credential simply stores the current password used for decryption.

Full explanation →

178

MCQmedium

An admin attempts to run this playbook as a job template in AAP. The job fails with 'ERROR! 'now' is not a valid attribute for a task'. What is the issue?

A.The template task is missing quotes around the file paths.

B.The playbook has an incorrect indentation in the tasks block.

C.The 'become' directive is placed incorrectly at the play level.

D.The 'now' attribute does not exist; it may be a typo for 'notify' or should be removed.

AnswerD

'now' is not a valid Ansible task attribute.

Why this answer

The error message 'ERROR! 'now' is not a valid attribute for a task' indicates that Ansible does not recognize 'now' as a valid task attribute. The 'now' keyword is not a standard Ansible directive; it is likely a typo for 'notify' (used with handlers) or should be removed entirely. Ansible validates task attributes against a strict schema, and any unknown attribute causes a parsing failure.

Exam trap

The trap here is that candidates may misread 'now' as a valid Jinja2 filter or confuse it with a module parameter, but Ansible strictly validates task attributes at parse time, not runtime.

How to eliminate wrong answers

Option A is wrong because missing quotes around file paths would cause a syntax error or a 'file not found' error, not an 'invalid attribute' error. Option B is wrong because incorrect indentation in the tasks block would produce a YAML parsing error (e.g., 'mapping values are not allowed here'), not an attribute validation error. Option C is wrong because placing 'become' at the play level is valid and would not generate an error about 'now'; it would either work or cause a privilege escalation error, not an attribute error.

Full explanation →

179

MCQmedium

A playbook uses a loop to create multiple users. The administrator notices that if one user creation fails, the entire playbook stops. Which directive should be used to continue executing remaining iterations?

A.max_fail_percentage

B.any_errors_fatal

C.ignore_errors

D.failed_when

AnswerC

ignore_errors tells Ansible to continue despite failures for that task, including within a loop.

Why this answer

`ignore_errors` is a directive that, when set to `yes` on a task, allows Ansible to continue executing subsequent iterations of a loop even if that specific task fails. This ensures that a failure in creating one user does not halt the entire playbook, as Ansible will record the failure but proceed with the remaining items in the loop.

Exam trap

The trap here is that candidates often confuse `ignore_errors` with `failed_when` or `any_errors_fatal`, thinking that custom failure conditions or global error handling will allow loop continuation, but only `ignore_errors` directly permits the playbook to proceed past a failed task within a loop.

How to eliminate wrong answers

Option A is wrong because `max_fail_percentage` is a directive used with the `serial` keyword to control how many hosts can fail before the playbook stops; it does not apply to individual task failures within a loop. Option B is wrong because `any_errors_fatal` causes the playbook to stop on any error from a task across all hosts, which would halt execution on the first failure, not continue iterations. Option D is wrong because `failed_when` defines custom failure conditions for a task but does not prevent the playbook from stopping; it only changes what constitutes a failure, and without `ignore_errors`, the playbook still halts on that failure.

Full explanation →

180

MCQmedium

An administrator needs to store a secret API token in Ansible Automation Controller so that it can be used in job templates without exposing the token in plain text. Which type of credential should be used?

A.Vault credential

B.Machine credential

C.Network credential

D.Cloud credential

AnswerA

Correct. Vault credential stores an encrypted password that can be used for secrets like API tokens.

Why this answer

A Vault credential in Ansible Automation Controller stores an encrypted password that can be used to decrypt Ansible Vault files. While originally designed for vault files, it can also be used to securely store any secret, such as an API token, by referencing it via the {{ vault_password }} variable in job templates. This ensures the token is never exposed in plain text.

Machine credentials are for SSH authentication, Network credentials for network devices, and Cloud credentials for cloud provider APIs—none are suitable for storing arbitrary API tokens.

Exam trap

Candidates often assume Machine credentials can store any secret due to the password field, but Machine credentials are intended for SSH host access and should not be repurposed for API tokens. Vault credentials provide proper encryption and are designed for secret storage.

How to eliminate wrong answers

Option A is wrong because a Vault credential is used to decrypt Ansible Vault-encrypted files, not to store arbitrary API tokens for use in job templates; it provides a vault password to unlock encrypted data. Option C is wrong because a Network credential is specifically for network device authentication (e.g., SSH keys for routers/switches) and is not intended for storing API tokens. Option D is wrong because a Cloud credential is designed to store cloud provider authentication (e.g., AWS access keys, Azure service principals) and is not a generic secret store for arbitrary API tokens.

Full explanation →

181

MCQmedium

An organization uses automation controller and has multiple teams. They want to create an inventory that automatically includes all hosts from a cloud provider that belong to the 'production' tag, and this inventory should be accessible only to the SRE team. What is the correct way to achieve this?

A.Create a smart inventory with a filter for tag 'production' and assign the SRE team the 'read' role on that inventory.

B.Create a static inventory file and restrict access via a custom script.

C.Use groups in the inventory and assign all production hosts to a group, then restrict access to that group.

D.Create a dynamic inventory plugin in each playbook and include a condition to check team membership.

AnswerA

Smart inventory automatically includes hosts based on filter; RBAC controls access.

Why this answer

A smart inventory in automation controller allows you to dynamically filter hosts from an existing source (like a cloud provider) based on criteria such as tags. By creating a smart inventory with a filter for the 'production' tag, you automatically include all matching hosts. Assigning the SRE team the 'read' role on that inventory restricts access to only that team, meeting both requirements without manual updates.

Exam trap

The trap here is that candidates confuse smart inventories with static groups or assume that playbook-level conditions can replace inventory-level RBAC, but automation controller enforces access control strictly at the inventory object level, not within playbook logic or group membership.

How to eliminate wrong answers

Option B is wrong because a static inventory file would require manual updates and cannot automatically include hosts from a cloud provider based on a tag; custom scripts do not integrate with automation controller's role-based access control (RBAC) for inventory-level permissions. Option C is wrong because groups within an inventory do not provide independent access control; RBAC in automation controller is applied at the inventory level, not at the group level, so restricting access to a group would not prevent users from seeing other hosts in the same inventory. Option D is wrong because dynamic inventory plugins are defined at the inventory level, not per playbook, and checking team membership in a playbook condition does not enforce access control at the inventory level; it would only skip tasks, not prevent the inventory from being visible or accessible.

Full explanation →

182

MCQeasy

An administrator wants to use a custom inventory script to dynamically generate hosts in Ansible Tower. Which of the following is a valid approach to manage credentials for accessing the script's API?

A.Define environment variables in the job template that references the inventory script, and use a credential type that injects those variables.

B.Attach the credential directly to the inventory script in the Ansible Tower UI.

C.Store the API token in a file within the project repository and source it in the script.

D.Embed the API token within the inventory script's JSON output.

AnswerA

This is the correct approach: use custom credential types to inject environment variables into job templates.

Why this answer

Ansible Tower (now Red Hat Ansible Automation Platform) allows custom credential types to inject environment variables into job runs. When a custom inventory script requires API authentication, you can define a credential type with injector configuration that sets environment variables (e.g., API_TOKEN, API_USER), then attach that credential to the job template. This keeps secrets out of scripts and repositories, following security best practices.

Exam trap

The trap here is that candidates may think credentials can be directly attached to inventory scripts (Option B) or that storing tokens in project files is acceptable, when in fact Tower's credential system is designed to inject secrets via environment variables or extra vars, not via direct script attachment or file storage.

How to eliminate wrong answers

Option B is wrong because Ansible Tower does not allow attaching credentials directly to an inventory script; credentials are attached to job templates, projects, or inventories, not to individual script files. Option C is wrong because storing API tokens in a file within the project repository violates security best practices and exposes secrets to version control, making them accessible to anyone with repository access. Option D is wrong because embedding the API token directly in the inventory script's JSON output would expose the token in plaintext in job logs and outputs, compromising security and violating the principle of least privilege.

Full explanation →

183

MCQmedium

Refer to the exhibit. The playbook uses serial: 1 (one host at a time). The update failed on web3.example.com. Based on the output, what is the most likely reason the play did not abort the rollout and how should the playbook be modified to stop on failure?

A.Add retries: 3 to the 'Update Apache config' task.

B.Set ignore_errors: yes on the 'Update Apache config' task.

C.Add max_fail_percentage: 0 to the play to abort on any failure.

D.Increase the serial value to update multiple hosts at once.

AnswerC

max_fail_percentage: 0 aborts the play if any host fails, preventing inconsistent state.

Why this answer

The play uses `serial: 1` to update one host at a time, but by default Ansible continues to the next host even if a task fails on the current host. Setting `max_fail_percentage: 0` at the play level tells Ansible to abort the entire play immediately if any host fails, which is the intended behavior for a rolling update where a single failure should stop the rollout.

Exam trap

Red Hat often tests the distinction between per-task error handling (`ignore_errors`, `retries`) and play-level failure thresholds (`max_fail_percentage`), and the trap here is that candidates mistakenly think retrying a task or ignoring errors will stop the rollout, when in fact only `max_fail_percentage` controls whether the play aborts across hosts.

How to eliminate wrong answers

Option A is wrong because adding `retries: 3` to the 'Update Apache config' task would cause Ansible to retry that task up to three times on the same host, but it does not change the default behavior of continuing to the next host after a failure; the play would still proceed to web4.example.com after exhausting retries on web3.example.com. Option B is wrong because `ignore_errors: yes` would cause Ansible to treat the failure as a success and continue the rollout, which is the opposite of what is needed to stop on failure. Option D is wrong because increasing the `serial` value would update more hosts concurrently, but it does not address the core issue of aborting on failure; in fact, it could make the problem worse by allowing multiple hosts to fail before the play stops.

Full explanation →

184

MCQeasy

You are a Red Hat Certified Engineer tasked with creating a content collection for your organization. The collection will contain roles and modules used by multiple teams. The requirements are: (1) The collection must follow the Ansible community structure. (2) It must include a module that manages network devices. (3) The collection must be versioned and published to Automation Hub. (4) You must provide a minimal working example for other developers. After initial development, you run 'ansible-galaxy collection build' and it fails with 'ERROR! Unknown file type in collection: .gitkeep'. The collection directory contains: - galaxy.yml - plugins/modules/network_config.py - roles/network/ - tests/ - .gitkeep (in tests/) What single action should you take to resolve the build error?

A.Add a 'namespace' field to galaxy.yml.

B.Create a .galaxy_ignore.yml file to exclude .gitkeep.

C.Remove the .gitkeep file from the collection.

D.Move the network_config.py module to a subdirectory named 'modules'.

AnswerC

Correct: ansible-galaxy collection build only accepts certain file types (e.g., .yml, .py, .rst). .gitkeep is unrecognized and must be removed.

Why this answer

The `ansible-galaxy collection build` command fails because it encounters a `.gitkeep` file inside the `tests/` directory, which is not a recognized file type for Ansible collections. The correct action is to remove the `.gitkeep` file, as Ansible collections only allow specific file types (e.g., `.yml`, `.yaml`, `.py`, `.rst`, `.md`, `.txt`, `.cfg`, `.json`, `.j2`, `.ps1`, `.psm1`, `.psd1`, `.csv`, `.env`, `.gitignore`, `.galaxy_ignore.yml`, and a few others). The `.gitkeep` file is not in this allowed list, causing the build to abort.

Exam trap

The trap here is that candidates may think they need to use `.galaxy_ignore.yml` to exclude the `.gitkeep` file, but the build process fails before ignoring rules are applied because the file type check occurs first.

How to eliminate wrong answers

Option A is wrong because the `namespace` field is already required in `galaxy.yml` for a valid collection, and its absence would cause a different error (e.g., 'ERROR! Missing required field: namespace'), not the 'Unknown file type' error. Option B is wrong because `.galaxy_ignore.yml` is used to exclude files from the built collection tarball, but it does not prevent the build from failing due to an unknown file type; the build process checks file types before applying ignore rules. Option D is wrong because the `network_config.py` module is already correctly placed in `plugins/modules/`; moving it to a subdirectory named `modules` would violate the required Ansible collection directory structure, causing a different error.

Full explanation →

185

MCQeasy

An admin wants to use custom Python modules in a job template without affecting the global controller environment. What should be used?

A.Install the modules globally on the controller.

B.Execution environment with custom collections.

C.Create a custom virtual environment and assign it to the job template.

D.Use a custom credential type that includes Python modules.

AnswerC

Custom virtualenvs provide isolated Python environments for specific jobs.

Why this answer

Custom Python modules must be isolated from the global controller environment to avoid conflicts. Ansible Tower/AWX allows you to create a custom virtual environment and assign it to a job template, ensuring that only the modules installed in that environment are used during job execution, leaving the global controller unaffected.

Exam trap

The trap here is that candidates confuse execution environments (which bundle Ansible collections and runtime) with Python virtual environments (which isolate Python packages), leading them to choose Option B instead of C.

How to eliminate wrong answers

Option A is wrong because installing modules globally on the controller would affect all job templates and potentially break existing automation due to dependency conflicts. Option B is wrong because execution environments with custom collections are used for Ansible content (roles, playbooks, collections), not for Python modules that are imported directly in custom scripts or modules. Option D is wrong because a custom credential type manages authentication credentials (e.g., SSH keys, API tokens) and cannot include or install Python modules.

Full explanation →

186

MCQeasy

An administrator wants to reuse a set of tasks that configure a firewall across multiple playbooks. Which Ansible feature should be used to achieve this?

A.Create a role for firewall configuration.

B.Add the tasks to the inventory file under a group.

C.Define the tasks in a vars file and include it.

D.Define the tasks as handlers and notify them.

AnswerA

Roles are the standard way to package reusable content.

Why this answer

A role is the correct Ansible feature for reusing a set of tasks across multiple playbooks. Roles provide a structured, self-contained directory layout for tasks, handlers, variables, templates, and files, allowing the firewall configuration logic to be packaged once and referenced in any playbook via the `roles:` directive or `import_role`/`include_role` modules.

Exam trap

The trap here is confusing roles with other reusable components like variables or handlers, leading candidates to think that storing tasks in a vars file or using handlers can achieve the same cross-playbook reuse.

How to eliminate wrong answers

Option B is wrong because the inventory file defines hosts and groups, not reusable task logic; adding tasks to an inventory file is syntactically invalid and would not execute them. Option C is wrong because vars files store variables, not tasks; including a vars file with `include_vars` cannot run tasks. Option D is wrong because handlers are special tasks triggered by notifiers only when a change occurs, not designed for general-purpose reuse across playbooks.

Full explanation →

187

MCQmedium

Refer to the exhibit. The playbook runs successfully. What will the debug task output?

A.Just the username 'jdoe'.

B.A dictionary with details about the user, such as uid, gid, and groups.

C.The entire playbook YAML structure.

D.The string 'true' if the user was created successfully.

AnswerB

The user module returns a dictionary with user attributes.

Why this answer

The debug task outputs the registered variable from the user module. By default, the user module returns a dictionary containing user account details such as uid, gid, groups, and home directory when the state is 'present'. Since the playbook runs successfully, the registered variable holds this dictionary, making option B correct.

Exam trap

Red Hat often tests the misconception that the debug task outputs a simple success message or a single value, when in fact it outputs the full return dictionary from the module.

How to eliminate wrong answers

Option A is wrong because the debug task does not output just the username; the user module returns a dictionary with multiple attributes, not a single string. Option C is wrong because the debug task outputs the contents of the registered variable, not the entire playbook YAML structure. Option D is wrong because the user module does not return a boolean string 'true'; it returns a dictionary on success, and the debug task will display that dictionary, not a success indicator.

Full explanation →

188

MCQhard

A company wants to implement a rolling update for a stateful application where hosts cannot be updated in parallel due to data consistency. They also need to ensure that if any host fails, the entire update is rolled back. Which strategy meets these requirements?

A.Use serial: 2 and any_errors_fatal: yes

B.Use serial: 1 and ignore_errors: yes

C.Use serial: 0 and max_fail_percentage: 0

D.Use serial: 1 and any_errors_fatal: yes

AnswerD

Correct. Single host updates and stop on error.

Why this answer

Setting `serial: 1` ensures hosts are updated one at a time, preventing parallel updates that could break data consistency for a stateful application. Adding `any_errors_fatal: yes` causes the entire playbook run to abort immediately if any host fails, which satisfies the requirement for a full rollback on failure.

Exam trap

The trap here is that candidates often confuse `serial: 1` with `serial: 0` or think `max_fail_percentage: 0` alone triggers a rollback, but `any_errors_fatal` is required to abort the entire playbook immediately on any failure, not just stop the current batch.

How to eliminate wrong answers

Option A is wrong because `serial: 2` allows two hosts to be updated in parallel, violating the requirement that hosts cannot be updated simultaneously due to data consistency. Option B is wrong because `ignore_errors: yes` causes Ansible to continue the update even if a host fails, which prevents the required rollback on failure. Option C is wrong because `serial: 0` is invalid (serial must be a positive integer or a percentage string), and `max_fail_percentage: 0` only stops the batch if 0% of hosts fail, which is effectively the same as `any_errors_fatal` but does not trigger a rollback of the entire update—it only halts further batches without reverting completed changes.

Full explanation →

189

MCQhard

A job template consistently fails with 'Authentication failed' for a managed host. The admin has verified that the username/password in the credential is correct and that the host is reachable. What is the most likely remaining cause?

A.The credential is not linked to the job template.

B.The SSH private key has not been added to the credential.

C.The username in the credential is misspelled.

D.The host is not reachable on the network.

AnswerA

A credential must be explicitly assigned to the job template; otherwise, authentication fails.

Why this answer

The most likely remaining cause is that the credential is not linked to the job template. Even if the credential contains correct authentication data, the job template will not use it unless the credential is explicitly associated. Without this link, Ansible Tower/AWX cannot authenticate to the managed host, resulting in an 'Authentication failed' error.

Exam trap

The trap here is that candidates assume a valid credential in the system is automatically used by all job templates, but in Ansible Tower/AWX, credentials must be explicitly assigned to each template to be utilized.

How to eliminate wrong answers

Option B is wrong because the question states the credential uses a username/password, not an SSH private key; if a private key were required, the credential type would be different. Option C is wrong because the admin has already verified that the username and password are correct, so a misspelling is ruled out. Option D is wrong because the admin has confirmed the host is reachable on the network, eliminating connectivity as the issue.

Full explanation →

190

MCQeasy

Which file is required to define the content of an Ansible execution environment when using ansible-builder?

A.Dockerfile

B.requirements.yml

C.ansible.cfg

D.execution-environment.yml

AnswerD

execution-environment.yml is the required file that defines the base image, collections, and dependencies.

Why this answer

The `execution-environment.yml` file is the required definition file for `ansible-builder` because it specifies the base image, custom dependencies (Python, system, or collections), and additional build instructions needed to construct a containerized Ansible execution environment. Without this file, `ansible-builder` has no manifest to process, as it is the sole input that defines the environment's content.

Exam trap

The trap here is that candidates confuse the generated `Dockerfile` (an output artifact) with the required input file, or they assume `requirements.yml` is the main definition because it is commonly used for collection installation in playbooks, but `ansible-builder` specifically requires `execution-environment.yml` as the blueprint.

How to eliminate wrong answers

Option A is wrong because a `Dockerfile` is not required; `ansible-builder` generates a `Dockerfile` automatically from the `execution-environment.yml` definition, so providing one manually would override the builder's logic and is not the required input. Option B is wrong because `requirements.yml` is an optional file used to list Ansible collections for installation, but it is not the primary definition file; it can be referenced within `execution-environment.yml` under the `dependencies` section. Option C is wrong because `ansible.cfg` is a configuration file for Ansible's runtime behavior (e.g., inventory, roles path, forks) and has no role in defining the content of an execution environment for `ansible-builder`.

Full explanation →

191

MCQmedium

When building an execution environment with ansible-builder, a developer notices that the build process fails with an error about missing dependencies. The developer wants to ensure all required Python packages are installed in the execution environment. Which file should be used to specify additional Python packages?

A.meta/runtime.yml

B.galaxy.yml

C.bindep.txt

D.requirements.txt

AnswerD

Standard file for Python dependencies in execution environments.

Why this answer

In Ansible Builder, the `requirements.txt` file is used to specify additional Python packages that should be installed in the execution environment. When building an execution environment, Ansible Builder reads this file and installs the listed packages via pip, ensuring all required Python dependencies are present.

Exam trap

The trap here is that candidates confuse `bindep.txt` (for system packages) with `requirements.txt` (for Python packages), as both are used in execution environment builds but serve different dependency types.

How to eliminate wrong answers

Option A is wrong because `meta/runtime.yml` is used to define runtime dependencies and compatibility for Ansible collections, not for specifying Python packages for an execution environment. Option B is wrong because `galaxy.yml` is a metadata file for Ansible collections, used to define collection name, version, and dependencies, not for listing Python packages. Option C is wrong because `bindep.txt` is used to specify system-level package dependencies (e.g., for apt or yum), not Python packages.

Full explanation →

192

Multi-Selectmedium

Which TWO filters are commonly used to manipulate JSON data in Ansible? (Select exactly two.)

Select 2 answers

A.flatten

B.from_json

C.json_query

D.regex_replace

E.to_json

AnswersB, C

Parses a JSON string into a data structure.

Why this answer

(from_json) is correct because it converts a JSON string into an Ansible data structure (dict or list), enabling further manipulation with filters like json_query. This is essential when parsing API responses or configuration files that return JSON-formatted strings.

Exam trap

The trap here is that candidates often confuse to_json and from_json, thinking both are used for manipulation, but to_json is for serialization (output) while from_json is for deserialization (input), and json_query is the actual manipulation filter for querying JSON data.

Full explanation →

193

Multi-Selectmedium

An administrator has a playbook with tasks tagged 'install', 'configure', and 'service'. There are no untagged tasks. They want to run only the tasks tagged 'install' and 'configure', skipping 'service'. Which three commands will achieve this? (Choose three.)

Select 3 answers

A.ansible-playbook site.yml --tags install,configure

B.ansible-playbook site.yml --tags configure --skip-tags install,service

C.ansible-playbook site.yml --skip-tags service

D.ansible-playbook site.yml --tags install --skip-tags service

E.ansible-playbook site.yml --tags install --tags configure

AnswersA, C, E

Runs tasks with either install or configure tag.

Why this answer

Options A, C, and E are correct. Option A uses a comma-separated list with `--tags` to run tasks tagged 'install' or 'configure'. Option C uses `--skip-tags service` to exclude the 'service' tag, running all other tags (install and configure).

Option E uses multiple `--tags` options, which Ansible combines with OR logic, effectively running tasks matching either 'install' or 'configure'. Options B and D are incorrect: B runs only 'configure' tasks (since it skips install and service), and D runs only 'install' tasks (since it specifies only that tag and skips service).

Exam trap

The trap is that candidates may think multiple `--tags` options only take the last value, but Ansible combines all `--tags` values. Additionally, `--skip-tags` can be used alone without `--tags` to exclude specific tags.

Full explanation →

194

MCQeasy

Refer to the exhibit. What is the purpose of the 'failed_when' condition?

A.It fails the task only if the return code is non-zero and the error does not indicate 'not installed'.

B.It ensures the task never fails regardless of return code.

C.It fails the task only if the package is installed.

D.It fails the task if the package is not installed.

AnswerA

Correct: This is exactly what the condition defines.

Why this answer

The 'failed_when' condition in Ansible allows you to define custom failure criteria for a task. In the exhibit, the condition 'failed_when: result.rc != 0 and "not installed" not in result.stderr' means the task will only be marked as failed if the return code is non-zero AND the error message does not contain the string 'not installed'. This is useful when a command returns a non-zero exit code for expected reasons (e.g., package not found), and you want to treat that as a non-failure.

Exam trap

The trap here is that candidates assume 'failed_when' always causes failure when the condition is true, but they overlook that the condition is a logical AND of two parts, and the second part ('not installed' not in stderr) is a negative check that prevents failure when the expected error message appears.

How to eliminate wrong answers

Option B is wrong because 'failed_when' does not ensure the task never fails; it only defines custom failure conditions, and if the condition evaluates to false, the task may still fail based on the default behavior (non-zero return code). Option C is wrong because the condition does not check whether the package is installed; it checks the return code and the presence of 'not installed' in stderr, not the package installation status itself. Option D is wrong because the condition does not fail the task if the package is not installed; it actually prevents failure when the error indicates 'not installed', so it would not fail in that case.

Full explanation →

195

Multi-Selectmedium

Which THREE statements about Ansible roles are correct? (Select exactly 3)

Select 3 answers

A.A role can directly include tasks from another role using the `include_tasks` module.

B.Roles can have dependencies on other roles defined in `meta/main.yml`.

C.Roles have a predefined directory structure that includes `tasks`, `handlers`, `defaults`, `vars`, `meta`, `templates`, and `files`.

D.Variables defined in `defaults/main.yml` override those in `vars/main.yml`.

E.Roles cannot include playbooks.

AnswersB, C, E

Correct. Roles can define dependencies on other roles in `meta/main.yml` using the `dependencies` keyword.

Why this answer

Ansible roles can declare dependencies on other roles in their `meta/main.yml` file using the `dependencies` keyword. Option C is correct because roles have a predefined directory structure that includes `tasks`, `handlers`, `defaults`, `vars`, `meta`, `templates`, and `files`. Option E is correct because roles are designed for tasks and handlers, not playbooks; you cannot directly include a playbook within a role.

Options A and D are incorrect: A is wrong because to include tasks from another role you use `include_role`, not `include_tasks`; D is wrong because variables in `vars/main.yml` override those in `defaults/main.yml`.

Exam trap

A common trap is confusing `include_role` with `include_tasks`—`include_tasks` includes a tasks file from within the same role, not from another role. Another trap is thinking `defaults` override `vars`, when in fact `vars` has higher precedence. Also, many candidates mistakenly believe roles can include playbooks, but roles only contain tasks, handlers, and other role components.

Full explanation →

196

MCQeasy

Refer to the exhibit. A playbook includes this vars file and runs `systemctl restart httpd`. The playbook fails because it cannot decrypt the vault. Which of the following is the most likely cause?

A.The vault ID is missing.

B.The variable db_password is not used in the playbook.

C.The vault password is not provided.

D.The vault file is corrupted.

AnswerC

Without a vault password, decryption fails.

Why this answer

The error 'cannot decrypt the vault' indicates that Ansible is unable to decrypt the vault-encrypted variable file. This occurs when the vault password is not provided via `--ask-vault-pass`, `--vault-password-file`, or the `ANSIBLE_VAULT_PASSWORD_FILE` environment variable. Without the correct password, Ansible cannot decrypt the vault, causing the playbook to fail.

Exam trap

Red Hat often tests the distinction between vault ID (which is optional) and vault password (which is mandatory), leading candidates to incorrectly select 'vault ID is missing' when the actual issue is the missing password.

How to eliminate wrong answers

Option A is wrong because a vault ID is optional; Ansible can decrypt vaults without an ID if the password matches, and the error message does not indicate a missing ID. Option B is wrong because whether `db_password` is used in the playbook is irrelevant to the decryption failure; the vault file is loaded regardless of variable usage. Option D is wrong because a corrupted vault file would typically produce a different error (e.g., 'Vault format error' or 'HMAC mismatch'), not a generic 'cannot decrypt' message.

Full explanation →

197

MCQmedium

Refer to the exhibit. The administrator wants to run a playbook that installs a package on all webservers. Which command will use the existing configuration and inventory correctly?

A.ansible-playbook -e 'ansible_python_interpreter=/usr/bin/python3' site.yml

B.ansible-playbook site.yml

C.ansible webservers -m package -a 'name=httpd state=present'

D.ansible-playbook -i inventory site.yml

AnswerB

ansible-playbook reads ansible.cfg automatically, using the defined inventory.

Why this answer

The ansible.cfg sets inventory=./inventory and roles_path=./roles. The playbook should be run with ansible-playbook, which reads the configuration automatically. The -i flag is not needed because inventory is defined in ansible.cfg.

Full explanation →

198

MCQhard

An administrator must parse an inventory file where hostnames are stored in YAML format under a list 'nodes'. The task needs to extract only hostnames that contain 'prod' in the name, then sort them in reverse order. Which combination of filters in a single Ansible expression achieves this?

A.nodes | select('match', '.*prod.*') | sort(reverse=True)

B.nodes | regex_search('prod') | sort(True)

C.nodes | map('regex_search', 'prod') | sort(reverse=True)

D.nodes | reject('match', '.*prod.*') | sort(reverse=True)

AnswerA

select filters list items that match the condition; sort with reverse=True sorts descending.

Why this answer

The `select` filter with the `match` test returns only list items that match the regex `'.*prod.*'`, i.e., hostnames containing 'prod'. The `sort(reverse=True)` then sorts the resulting list in descending alphabetical order, fulfilling both requirements in a single Ansible expression.

Exam trap

The trap here is that candidates often confuse `select` (which keeps matching items) with `reject` (which removes matching items), or mistakenly use `regex_search` or `map` thinking they will filter the list, when in fact those filters return substrings or transformed values, not the original list elements.

How to eliminate wrong answers

Option B is wrong because `regex_search` returns matched substrings, not the original hostnames, and `sort(True)` is invalid syntax (must be `sort(reverse=True)`). Option C is wrong because `map('regex_search', 'prod')` returns a list of matched substrings (or empty strings for non-matches), not the original hostnames, and would fail to filter properly. Option D is wrong because `reject('match', '.*prod.*')` excludes hostnames containing 'prod', which is the opposite of the required selection.

Full explanation →

199

MCQhard

Refer to the exhibit. After the playbook run fails on the 'Verify config' task, what happens to the 'restart service' handler?

A.The handler runs immediately after the failed task.

B.The handler is not executed because the playbook failed before the end of the play.

C.The handler runs on the next playbook run.

D.The handler is executed because it was notified before the failure.

AnswerB

By default, handlers run at the end of the play only if all tasks succeed. If a task fails, the play aborts and handlers are not run.

Why this answer

Handlers are notified but only run at the end of the play if notified. However, if a subsequent task fails, the playbook stops, and handlers are not executed unless the 'force_handlers' option is set.

Full explanation →

200

MCQmedium

Based on the exhibit, what is the purpose of the `galaxy` dependency entry?

A.Set the base container image.

B.Define which Ansible collections to install in the execution environment.

C.Specify Python packages to install via pip.

D.Configure environment variables for the container.

AnswerB

The `galaxy` key points to a requirements file for collections.

Why this answer

In the context of Ansible execution environments (EEs), the `galaxy` key within the `dependencies` section of the `execution-environment.yml` file specifies a list of Ansible collections to be installed from Ansible Galaxy or an Automation Hub. This allows the EE to include the necessary content collections required for playbook execution, ensuring all roles and modules are available inside the container.

Exam trap

Red Hat often tests the distinction between `galaxy` (for Ansible collections) and `python` (for pip packages) in the `dependencies` section, leading candidates to confuse the two or assume `galaxy` installs Python packages.

How to eliminate wrong answers

Option A is wrong because the base container image is defined by the `base_image` key in the `execution-environment.yml` file, not by the `galaxy` dependency entry. Option C is wrong because Python packages to install via pip are specified under the `python` key within `dependencies`, not under `galaxy`. Option D is wrong because environment variables for the container are configured using the `environment` key in the `execution-environment.yml` file, not through the `galaxy` dependency entry.

Full explanation →

201

Multi-Selectmedium

Which TWO statements about Ansible Execution Environments (EE) are true?

Select 2 answers

A.Execution environments are primarily used for developing new Ansible modules.

B.Execution environments use ansible-navigator as the default entrypoint.

C.Execution environments are container images built with ansible-builder.

D.Execution environments package Ansible Core, collections, and Python dependencies.

E.Execution environments can only be used with the ansible-navigator command-line tool.

AnswersC, D

Correct: ansible-builder is used to create EE images.

Why this answer

Execution environments are container images that package Ansible Core, collections, and Python dependencies, and they are built using the `ansible-builder` tool. The `ansible-builder` reads a definition file (e.g., `execution-environment.yml`) to construct a container image that includes all necessary components for running Ansible automation in a consistent, isolated environment.

Exam trap

The trap here is that candidates may confuse the purpose of execution environments (packaging and running automation) with module development, or assume that `ansible-navigator` is the only way to use them, when in fact they are container images that can be used with multiple Ansible tools.

Full explanation →

202

MCQhard

A security team requires that all automation controller job logs be forwarded to an external SIEM system. Which integration should be used?

A.Ansible Log Forwarder

B.Custom callback plugin

C.Automation controller's built-in logging aggregator

D.rsyslog configuration

AnswerC

Built-in aggregator forwards logs to external systems.

Why this answer

Automation controller (formerly Ansible Tower) includes a built-in logging aggregator that can forward job logs to external SIEM systems via supported protocols such as HTTPS, TCP, or UDP. This integration is configured directly in the controller's settings, requiring no additional scripts or system-level changes, making it the correct and supported method for centralized log forwarding.

Exam trap

The trap here is that candidates may confuse the built-in logging aggregator with system-level tools like rsyslog or assume a custom callback plugin is required, when in fact the controller provides a native, configuration-driven solution for this exact requirement.

How to eliminate wrong answers

Option A is wrong because 'Ansible Log Forwarder' is not a real component or integration in the automation controller; it is a fabricated term. Option B is wrong because custom callback plugins are used to extend Ansible's callback behavior during playbook execution, but they are not the standard or supported integration for forwarding job logs to an external SIEM; the controller's built-in logging aggregator is the intended mechanism. Option D is wrong because rsyslog configuration operates at the system level and would require manual setup to capture and forward logs, but it does not integrate with automation controller's job log structure or API, and it is not the recommended or supported method for this purpose.

Full explanation →

203

MCQeasy

Which directive in an Ansible playbook ensures that a task runs only on the first host in a batch, and results are applied to all hosts?

A.run_once

B.any_errors_fatal

C.throttle

D.delegate_to: localhost

AnswerA

run_once runs the task on the first host and applies results to all hosts.

Why this answer

Option A (run_once) is correct. The `run_once` directive ensures that a task is executed only once for the entire batch, typically on the first host, and the results are then applied to all hosts in the play. Option B (any_errors_fatal) is incorrect; it causes the play to abort if any task fails on any host, unrelated to running a task once.

Option C (throttle) is incorrect; it limits the number of hosts that execute the task concurrently but does not ensure single execution. Option D (delegate_to: localhost) is incorrect; it delegates execution to the localhost but still runs on every host in the batch unless combined with `run_once`.

Full explanation →

204

MCQeasy

An automation engineer wants to run a playbook only on hosts that belong to both the 'webservers' group and the 'production' group. Which inventory grouping method achieves this?

A.webservers:&production

B.webservers:production

C.webservers:!production

D.webservers+,production

AnswerA

Ampersand specifies intersection of hosts in both groups.

Why this answer

In Ansible, the '&' operator is used to intersect groups. 'webservers:&production' targets hosts that are in both the 'webservers' and 'production' groups. Option B is wrong because 'webservers:production' uses ':' which is a union operator, meaning hosts in either group. Option C is wrong because 'webservers:!production' uses '!' to exclude hosts in production.

Option D is wrong because 'webservers+,production' is not a valid inventory pattern; Ansible does not support '+' for group intersection.

Full explanation →

205

MCQeasy

A developer reports that a role's behavior is not as expected. They set a variable in the playbook's vars section, but the role still uses the value from its vars/main.yml. Which of the following explains this issue?

A.vars defined in the playbook have higher precedence than those in roles/vars/main.yml

B.vars defined in group_vars override both play and role vars

C.the playbook must use include_vars after the role to override

D.vars defined in roles/vars/main.yml have higher precedence than those in the playbook's vars section

AnswerD

Correct: role vars override play vars.

Why this answer

In Ansible, variable precedence is hierarchical, and role defaults (roles/role_name/defaults/main.yml) have the lowest precedence, while role vars (roles/role_name/vars/main.yml) have a higher precedence than playbook-level vars. Since the developer set the variable in the playbook's vars section, but the role still uses the value from its vars/main.yml, this indicates that vars defined in roles/vars/main.yml override those in the playbook's vars section, making option D correct.

Exam trap

The trap here is that candidates often confuse role defaults (defaults/main.yml) with role vars (vars/main.yml), assuming both are easily overridden by playbook vars. In Red Hat Ansible Automation Platform, role vars have higher precedence than playbook vars, making them effectively 'hardcoded' unless overridden by even higher precedence sources like extra vars or set_facts.

How to eliminate wrong answers

Option A is wrong because vars defined in the playbook have lower precedence than those in roles/vars/main.yml, not higher. Option B is wrong because group_vars have a lower precedence than both play vars and role vars, so they cannot override both; in fact, role vars override group_vars. Option C is wrong because include_vars is used to load variables from a file at runtime, but it does not change the inherent precedence; the role's vars/main.yml would still take precedence over playbook vars regardless of when include_vars is used.

Full explanation →

206

Multi-Selecthard

An organization needs to implement security best practices for Ansible automation. Which three measures should be taken? (Choose three.)

Select 3 answers

A.Use ansible-vault to encrypt sensitive variables

B.Store all secrets in plain text in repository

C.Regularly rotate Ansible Vault passwords

D.Disable SSH host key checking globally

E.Limit access to automation controller using RBAC

AnswersA, C, E

Encrypts secrets at rest.

Why this answer

`ansible-vault` is the built-in Ansible tool for encrypting sensitive data such as passwords, API keys, and secret variables. It uses AES-256 encryption to protect secrets at rest, ensuring they are not exposed in plain text within playbooks, inventory files, or version control systems. This is a fundamental security best practice for any Ansible automation environment.

Exam trap

The trap here is that candidates may think disabling SSH host key checking is acceptable for convenience in lab environments, but the exam expects you to recognize it as a security risk that should never be applied globally in production.

Full explanation →

207

Multi-Selectmedium

Which TWO options are valid techniques for rolling out updates to a subset of hosts before updating the rest? (Choose exactly two.)

Select 2 answers

A.Use serial: 3 to update hosts in batches of 3.

B.Use a canary group with a separate playbook run and manual verification before updating the full fleet.

C.Use inventory host variables to mark hosts for early update and use conditional tasks.

D.Use the --forks=1 option to update one host at a time.

E.Use the 'strategy: random' directive in the playbook.

AnswersA, B

Serial is the built-in rolling update mechanism.

Why this answer

The `serial: 3` directive in an Ansible playbook limits the number of hosts updated in each batch, allowing you to roll out changes to a subset of hosts before proceeding to the next batch. This is a native Ansible mechanism for controlling rolling updates by specifying the batch size, ensuring that only three hosts are updated at a time, with the play pausing between batches.

Exam trap

The trap here is that candidates often confuse `--forks=1` (which limits concurrency but does not create batches) with `serial: 1` (which creates batches of one host), or they assume that inventory variables alone can orchestrate rolling updates without additional playbook logic.

Full explanation →

208

MCQhard

An organization uses Automation Controller with multiple teams. They want to ensure that team members can only launch job templates that are explicitly assigned to their team. Which configuration approach should be used?

A.Assign each team to an organization and set organization-level permissions

B.Set 'allow simultaneous' to false on job templates

C.Use an Identity Provider (IdP) to restrict access

D.Create roles and assign them at the job template level using team roles

AnswerD

Team roles on job templates restrict launch access.

Why this answer

Automation Controller (formerly Ansible Tower) uses Role-Based Access Control (RBAC) where roles (e.g., Execute, Admin) can be assigned to teams at the job template level. This ensures that only members of a specific team can launch the job templates explicitly assigned to that team, without affecting other teams or requiring organization-wide permissions.

Exam trap

The trap here is confusing authentication (IdP) with authorization (RBAC), leading candidates to choose Option C, even though IdPs like LDAP or SAML only verify who the user is, not what they can do within Automation Controller.

How to eliminate wrong answers

Option A is wrong because setting organization-level permissions grants access to all teams within the organization, not restricting job template access to a specific team. Option B is wrong because 'allow simultaneous' controls whether multiple concurrent runs of the same job template are permitted, not who can launch it. Option C is wrong because an Identity Provider (IdP) handles authentication (verifying user identity), not authorization (controlling access to specific resources like job templates); RBAC within Automation Controller is required for fine-grained access control.

Full explanation →

209

MCQmedium

A sysadmin receives an error when running a job template: 'ERROR! the role 'common' was not found in the specified roles path'. The role exists in a source control repository referenced in the project. What is the most likely cause?

A.The inventory does not include the target hosts

B.The project's source control sync failed, so the roles directory is empty

C.The job template is configured with an incorrect schedule

D.The credential used does not have access to the source control repository

AnswerB

A failed sync means the roles were not downloaded, causing the 'not found' error.

Why this answer

The error indicates that Ansible cannot find the 'common' role in the specified roles path. Since the role exists in the source control repository referenced by the project, the most likely cause is that the project's source control sync failed, leaving the roles directory empty or incomplete. Without a successful sync, the role files are not present on the Ansible control node, causing the job template execution to fail.

Exam trap

The trap here is that candidates may confuse a credential failure (Option D) with a sync failure, but the error message specifically points to a missing role file, not an authentication issue, and the sync failure is the direct cause of the missing role.

How to eliminate wrong answers

Option A is wrong because the inventory not including target hosts would cause a different error, such as 'No hosts matched' or a failure to connect, not a missing role error. Option C is wrong because an incorrect schedule would prevent the job from running at the intended time but would not cause a missing role error during execution. Option D is wrong because if the credential lacked access to the source control repository, the project sync would fail with an authentication or authorization error, not a missing role error after a successful sync.

Full explanation →

210

Multi-Selectmedium

Which TWO options are valid methods for including collections in an execution environment?

Select 2 answers

A.Use ansible-galaxy collection install command in a pre-build script.

B.List collections under 'collections' in execution-environment.yml.

C.Use a 'galaxy.yml' file in the build context.

D.Add a requirements.yml file with collections.

E.Include collections in the base image directly.

AnswersB, D

This is the primary method; you can specify collections directly in execution-environment.yml.

Why this answer

The `execution-environment.yml` file is the primary configuration file for building an Ansible execution environment, and it supports a `collections` key where you can list collections to be included. This is the standard method for specifying collections that should be installed during the build process, ensuring they are available in the final execution environment.

Exam trap

The trap here is that candidates confuse the `galaxy.yml` file (used for defining a collection's metadata) with the `execution-environment.yml` file (used for specifying collections to include in an execution environment), or they mistakenly think runtime commands like `ansible-galaxy collection install` are valid build-time methods.

Full explanation →

211

MCQhard

An Ansible automation is used to manage firewall rules on a set of Linux servers. The playbook defines a variable "allow_rules" as: allow_rules: - proto: tcp dport: 80 comment: HTTP - proto: tcp dport: 443 comment: HTTPS The engineer needs to use the "iptables" module to create rules. The module expects "chain" to be specified, and the engineer wants to dynamically set the chain based on the port: ports 80 and 443 go to "INPUT" chain, while others go to "FORWARD". The engineer writes a loop: - name: Add iptables rules iptables: chain: "{{ item.dport | map('some_filter') }}" protocol: "{{ item.proto }}" destination_port: "{{ item.dport }}" comment: "{{ item.comment }}" loop: "{{ allow_rules }}" But this fails because the chain field expects a string, not a list. The engineer realizes the map filter returns a list. Which of the following modifications correctly sets the chain based on port number?

A.chain: "{{ item.dport | regex_replace('^(80|443)$', 'INPUT') | default('FORWARD', true) }}"

B.chain: "{{ (item.dport in [80,443]) | ternary('INPUT', 'FORWARD') }}"

C.chain: "{{ item.dport | select('in', [80,443]) | list | first | default('FORWARD') }}"

D.chain: "{{ item.dport | replace('80','INPUT') | replace('443','INPUT') | default('FORWARD') }}"

AnswerB

Ternary correctly returns 'INPUT' for ports in the list, else 'FORWARD'.

Why this answer

It uses the `ternary` filter to evaluate a condition (`item.dport in [80,443]`) and return 'INPUT' if true, or 'FORWARD' if false. This produces a single string, which is exactly what the `chain` parameter expects, avoiding the list output from `map`.

Exam trap

The trap here is that candidates often reach for `map` or `select` filters without realizing they produce lists, and then try to coerce them into strings with `first` or `join`, which can fail or produce unexpected results when the list is empty or contains non-string values.

How to eliminate wrong answers

Option A is wrong because `regex_replace` only replaces matched patterns within the string; it does not change the string to 'INPUT' for ports 80 or 443, and the `default` filter would only apply if the result is an undefined value, not a string that wasn't replaced. Option C is wrong because `select('in', [80,443])` returns a list of items that match the condition; even after `list | first`, if the list is empty (e.g., port 8080), `first` returns `None`, and `default('FORWARD')` would then apply, but for ports 80 or 443 it returns the port number itself (an integer), not 'INPUT'. Option D is wrong because `replace` performs simple substring replacement; it would change '80' to 'INPUT' even if the port is 8080 (e.g., '8080' becomes 'INPUT80'), and it does not handle the case where the port is not 80 or 443, leaving the original port number as the chain value.

Full explanation →

212

MCQhard

An organization uses multiple Ansible Automation Platform clusters in different geographies. Each cluster has its own set of credentials for different environments. An administrator needs to ensure that job templates launched in the EMEA cluster can only use EMEA-specific credentials, while the APAC cluster uses APAC-specific credentials, without duplicating job template definitions. What is the best approach?

A.Configure separate organizations for each cluster and assign credentials to each organization, then use the same job template within each organization

B.Create separate job templates for each cluster and assign the appropriate credentials

C.Use the same job template and rely on host tags in the inventory to filter which credentials are used

D.Use an external secrets management system and call it via lookup plugin in the playbook

AnswerA

Organizations provide credential isolation; templates can be duplicated per organization with same playbook but different credentials.

Why this answer

Ansible Automation Platform organizations provide a logical boundary for credentials, projects, and job templates. By creating separate organizations for the EMEA and APAC clusters, the administrator can assign EMEA-specific credentials to the EMEA organization and APAC-specific credentials to the APAC organization. The same job template can then be created within each organization, inheriting only the credentials assigned to that organization, thus avoiding duplication of the job template definition while enforcing credential isolation.

Exam trap

The trap here is that candidates may think host tags or inventory variables can control credential usage, but Ansible Automation Platform does not support credential filtering based on inventory metadata; credentials are strictly bound to organizations or job templates.

How to eliminate wrong answers

Option B is wrong because it requires creating separate job templates for each cluster, which duplicates job template definitions and contradicts the requirement to avoid duplication. Option C is wrong because host tags in inventory are used for targeting specific hosts or groups, not for filtering credentials; credentials are assigned at the job template or organization level, and tags cannot restrict which credentials a job template can use. Option D is wrong because using an external secrets management system with a lookup plugin retrieves secrets at runtime but does not enforce which credentials a job template can use; it bypasses the credential assignment mechanism and does not provide the required isolation between clusters.

Full explanation →

213

MCQmedium

A team has been using Ansible Automation Controller for six months. They have a job template that runs a playbook against a static inventory. Recently, the job template started hanging indefinitely after launching. The admin checks the job output and sees: `PLAY [all] ************************` with no further output. The playbook uses `delegate_to: localhost` for some tasks. The admin executed the same playbook manually with `ansible-playbook` on the control node and it completes successfully. The controller logs show no errors. What is the most likely cause of the hang in the controller?

A.The machine credential for the job template does not include the SSH key for the control node.

B.The execution environment used by the job template has no route to the controller's IP address on port 22.

C.The playbook has a syntax error that only manifests when run as a job template.

D.The inventory for the job template does not include the control node host.

AnswerB

Delegate_to localhost uses SSH to 127.0.0.1, but inside EE, 'localhost' may not be reachable.

Why this answer

In Ansible Automation Controller, tasks with delegate_to: localhost are executed on the controller node. The execution environment (container) typically connects to the controller's IP via SSH (port 22) to run these tasks. If the execution environment has no network route to the controller's IP on port 22, the connection times out, causing the job to hang.

The manual ansible-playbook run works because it runs directly on the control node, where localhost is local and no SSH is needed. Option A is wrong because the play begins, indicating initial SSH connections succeed. Option C is wrong because the manual run succeeded, ruling out syntax errors.

Option D is wrong because delegate_to localhost does not require the control node to be in the inventory.

Full explanation →

214

Multi-Selecthard

Which TWO statements about Ansible content collections are correct?

Select 2 answers

A.Collections can be installed only from Galaxy.

B.The collection name must be a single word without namespace.

C.Collections can be distributed via Automation Hub or Galaxy.

D.A collection can contain only roles and playbooks.

E.A collection must have a galaxy.yml file in its root directory.

AnswersC, E

Both are valid distribution platforms for collections.

Why this answer

Ansible content collections can be distributed via either Red Hat Automation Hub (for certified collections) or Ansible Galaxy (for community collections). This dual distribution model allows organizations to use curated, supported content from Automation Hub while also leveraging community-contributed collections from Galaxy.

Exam trap

Red Hat often tests the requirement for a `galaxy.yml` file in the collection root, as candidates may mistakenly think it is optional or confuse it with other configuration files like `meta/main.yml`.

Full explanation →

215

MCQhard

An Ansible playbook uses a vault-encrypted variable `db_password` from a vars file. The playbook fails with 'Decryption failed' error. Which of the following could be the cause?

A.The vault password is correct but the file is corrupted.

B.The vault password file path is incorrect in ansible.cfg.

C.The vault ID in the encrypted file does not match the provided vault ID.

D.The variable is not encrypted but marked as `!vault`.

AnswerC

A vault ID mismatch causes decryption failure.

Why this answer

Ansible Vault supports multiple vault IDs, and the vault ID used to encrypt the variable must match the vault ID provided at runtime (via `--vault-id` or `ansible.cfg`). If the encrypted file was created with vault ID 'prod' but the playbook is run with vault ID 'dev', Ansible will fail with 'Decryption failed' because it cannot find a matching password for that ID.

Exam trap

The trap here is that candidates often assume 'Decryption failed' always means a wrong password, but Ansible's vault ID mismatch is a distinct and common cause that is explicitly tested in the exam.

How to eliminate wrong answers

Option A is wrong because a corrupted file would typically produce a different error (e.g., 'Vault format error' or 'unexpected EOF'), not a generic 'Decryption failed' message. Option B is wrong because an incorrect vault password file path in ansible.cfg would cause Ansible to fail earlier with a file-not-found error, not a decryption failure. Option D is wrong because if a variable is not encrypted but marked as `!vault`, Ansible would treat it as an invalid vault string and raise a parsing error, not a decryption failure.

Full explanation →

216

MCQhard

A collection version is already published on Automation Hub. The developer needs to update the collection with a new feature. What must be done to the version number before publishing again?

A.No change needed; Automation Hub overwrites.

B.Increment the patch or minor version number.

C.Increment the major version number.

D.Change the version to a pre-release identifier.

AnswerB

Automation Hub requires a unique version; incrementing patch or minor is appropriate for a new feature.

Why this answer

Automation Hub enforces immutable collection versions; once a version is published, it cannot be overwritten or deleted. To publish a new feature, you must increment the patch (e.g., 1.0.0 → 1.0.1) or minor (e.g., 1.0.0 → 1.1.0) version number in the galaxy.yml file, following semantic versioning (semver) as required by Ansible collections.

Exam trap

The trap here is that candidates assume Automation Hub behaves like a mutable artifact repository (e.g., overwriting on re-upload), but Red Hat enforces immutability to ensure version integrity and reproducibility across environments.

How to eliminate wrong answers

Option A is wrong because Automation Hub does not allow overwriting an existing version; collections are immutable once published, and attempting to publish the same version will result in an error. Option C is wrong because incrementing the major version (e.g., 1.0.0 → 2.0.0) is only required when introducing breaking changes, not for a new feature that is backward-compatible. Option D is wrong because pre-release identifiers (e.g., 1.0.0-alpha.1) are used for testing or development versions and are not intended for publishing a stable new feature to Automation Hub.

Full explanation →

217

MCQhard

An organization uses a proprietary API service that requires token-based authentication with a base64-encoded payload including username, password, and tenant ID. The administrator wants to create a custom credential type in automation controller so that users can input these three values separately, and the playbook receives the final token. Which input configuration fields should be defined?

A.Three separate text fields (username, password, tenant ID) with a custom injector template that concatenates and base64-encodes them.

B.One text field for the token, and inject it as an environment variable.

C.Two fields: username and password, and use a lookup plugin to fetch tenant ID.

D.Create a single multiline text field where users paste the base64 string.

AnswerA

Allows separate inputs and injector creates the final token.

Why this answer

Automation controller custom credential types allow defining multiple input fields (username, password, tenant ID) and a custom injector template that can concatenate and base64-encode these values into a single token. The injector template uses Jinja2 syntax to combine the inputs and apply the `b64encode` filter, so the playbook receives the final base64-encoded token as a single credential variable.

Exam trap

The trap here is that candidates may think a single text field for the token (Option B) is sufficient, overlooking the requirement for separate input fields and automated encoding, or they may confuse custom credential types with simple credential fields that only store static values.

How to eliminate wrong answers

Option B is wrong because it defines only one text field for the token, which defeats the requirement for users to input three separate values; the administrator wants the playbook to receive the final token, but the credential type must accept the three raw inputs and generate the token internally. Option C is wrong because it omits the tenant ID field and relies on a lookup plugin to fetch it, which is not part of the custom credential type definition and would require external dependencies or inventory sources, violating the requirement for users to input all three values directly. Option D is wrong because a single multiline text field where users paste the base64 string shifts the burden of encoding to the user, rather than having automation controller generate the token from separate inputs, which is the core goal of the custom credential type.

Full explanation →

218

MCQmedium

An inventory is sourced from an external dynamic inventory plugin. The plugin returns hosts with groups including 'webservers' and 'dbservers'. An administrator wants to add a custom variable to all hosts in the 'webservers' group without modifying the plugin script. How can this be achieved?

A.Modify the dynamic inventory plugin script to add the variable

B.Add the variable to the host_vars file for each host

C.Create a group_vars file named 'webservers' in the project directory and define the variable

D.Use the 'add_host' module in a playbook to set the variable

AnswerC

Group_vars files automatically apply to hosts in the matching group from any inventory source.

Why this answer

Ansible's group_vars mechanism allows you to define variables for all hosts in a group by creating a YAML file named after the group (e.g., 'webservers') in the group_vars directory. This approach does not require modifying the dynamic inventory plugin script, which is external and should remain untouched. The variable will be automatically applied to all hosts in the 'webservers' group during playbook execution.

Exam trap

The trap here is that candidates may think modifying the plugin script (Option A) is acceptable, but the EX294 exam emphasizes immutability of external sources and using Ansible's built-in variable precedence and group_vars instead.

How to eliminate wrong answers

Option A is wrong because modifying the dynamic inventory plugin script violates the requirement to not modify the plugin, and it is not a best practice—external plugins should be treated as immutable. Option B is wrong because adding the variable to host_vars files for each host would be repetitive and inefficient, and it does not leverage group-level inheritance; it also requires knowing all hostnames in advance. Option D is wrong because the 'add_host' module is used to dynamically add hosts to the in-memory inventory during playbook runtime, not to set persistent variables for existing group members; it would not apply the variable to all hosts in the 'webservers' group automatically.

Full explanation →

219

MCQhard

An Ansible Tower/AWX job template uses a custom inventory script that dynamically queries an API. The script returns JSON including groups and hosts. Recently, the API started returning HTTP 500 errors intermittently, causing inventory sync failures. Which Ansible approach can make the inventory source more resilient?

A.Configure the inventory script to use the Ansible cache plugin with a timeout and fallback to cached data.

B.Wrap the inventory script invocation in a Jinja2 template with error handling.

C.Use the setup module to gather facts and store them locally as a fallback inventory.

D.Modify the inventory script to retry on failure and write results to a static file.

AnswerA

Cache can serve stale data if API fails.

Why this answer

The Ansible cache plugin can store the results of a dynamic inventory script and serve them when the API is unavailable. By configuring a timeout and fallback to cached data, the job template avoids failures during transient HTTP 500 errors, ensuring inventory sync resilience without modifying the script itself.

Exam trap

The trap here is that candidates may think modifying the script (Option D) is the only way to handle API failures, overlooking Ansible Tower/AWX's built-in caching mechanism that provides a cleaner, more maintainable solution without altering the script's code.

How to eliminate wrong answers

Option B is wrong because Jinja2 templates are used for data transformation and rendering, not for error handling or retry logic in inventory scripts; they cannot catch HTTP errors or implement fallback mechanisms. Option C is wrong because the setup module gathers facts from existing hosts, not from an API, and storing facts locally does not provide a fallback inventory source for dynamic inventory scripts that query an external API. Option D is wrong because modifying the inventory script to retry and write to a static file is a valid workaround but is not an Ansible approach; it bypasses Ansible's built-in caching and inventory management features, and the static file would not be automatically refreshed or integrated with Ansible's inventory lifecycle.

Full explanation →

220

MCQmedium

The playbook above fails with 'template source file not found' for the copy task. Which change should be made to fix it?

A.Use the 'template' module instead of 'copy' for .j2 files.

B.Add 'delegate_to: localhost' to copy the file from the control node.

C.Set 'backup: no' because backup creates additional files.

D.Set 'gather_facts: yes' to allow Ansible to locate the template.

AnswerA

Template module processes Jinja2 templates.

Why this answer

The 'copy' module does not render Jinja2 templates; it simply copies files as is. When using a .j2 file with the copy module, Ansible expects the source file to exist literally, but it looks for the template in the wrong location, causing the 'template source file not found' error. The 'template' module is designed to process .j2 files, applying variables and Jinja2 logic, and then copying the result to the remote host.

Therefore, replacing 'copy' with 'template' resolves the issue.

Full explanation →

221

MCQeasy

Refer to the exhibit. After running the playbook, the 'content' field contains an HTML page. The team wants to extract the text inside the <h1> tags using Ansible filters. Which of the following tasks correctly extracts the content of the <h1> element?

A.set_fact: heading="{{ result.content | regex_replace('.*<h1>(.*)</h1>.*', '\1') }}"

B.set_fact: heading="{{ result.content | regex_replace('<h1>(.*)</h1>', '\1') }}"

C.set_fact: heading="{{ result.content | regex_search('<h1>(.*)</h1>') }}"

D.set_fact: heading="{{ result.content | regex_findall('<h1>(.*)</h1>') | first }}"

AnswerA

Correct. The pattern `.*<h1>(.*)</h1>.*` matches the entire string and replaces it with the captured group, yielding only the heading content.

Why this answer

It uses `regex_replace` with a pattern that matches the entire string (`.*<h1>(.*)</h1>.*`) and replaces it with the captured group `\1`, effectively extracting only the heading text. Option B, while it uses `regex_replace`, only matches the `<h1>...</h1>` portion; if the page contains any content outside the `<h1>` tags, that content remains, so it does not reliably extract just the heading text. Options C and D return the full match including the tags, not just the inner text.

Exam trap

Candidates often assume any `regex_replace` that captures the inner text works, but only Option A's pattern ensures complete extraction by matching the entire input. Option B leaves surrounding content intact, making it unsuitable for extraction.

How to eliminate wrong answers

Option B is wrong because the pattern `'<h1>(.*)</h1>'` lacks the leading `.*` and trailing `.*`, so `regex_replace` will only replace the first occurrence of the literal `<h1>...</h1>` substring, leaving any surrounding content (like HTML before or after) intact, resulting in a string that still contains extraneous HTML. Option C is wrong because `regex_search` returns the first match of the entire pattern, including the `<h1>` and `</h1>` tags, not just the inner text; the result would be something like `<h1>Hello</h1>` instead of `Hello`. Option D is wrong because `regex_findall` returns a list of all matches (each match being the full pattern including tags), and using `| first` would give the first full match (e.g., `<h1>Hello</h1>`), not the captured group; to extract the inner text, one would need to use a capture group in the pattern and apply `regex_findall` with the `'\1'` replacement or use `regex_search` with a capture group.

Full explanation →

222

MCQhard

A playbook uses the 'win_chocolatey' module to install software on Windows hosts. The playbook is idempotent for most packages, but one package consistently fails with 'The package is already installed' error despite being reinstalled each run. Which approach ensures true idempotency?

A.Change state=present to state=latest to ensure the module only updates if needed.

B.Use the 'force' option in win_chocolatey to allow reinstalling, and ignore the error.

C.Add a 'when' condition to skip the package if it is already installed based on a registered variable from the win_chocolatey module's results.

D.Use a win_shell task with a check command to detect installation, and conditionally run the win_chocolatey task only when absent.

AnswerD

Manual check ensures idempotent execution.

Why this answer

The win_chocolatey module's 'state=present' does not guarantee idempotency for all packages; some packages may not report their installed state correctly to Chocolatey, causing the module to attempt installation every run and fail with 'already installed'. By using a win_shell task with a check command (e.g., `choco list --local-only`) to detect installation and conditionally running the win_chocolatey task only when absent, you bypass the module's flawed state detection and achieve true idempotency.

Exam trap

The EX294 exam often tests the misconception that Ansible modules are inherently idempotent for all edge cases, but the trap here is that some modules (like win_chocolatey) depend on external tools' state reporting, which can be unreliable, requiring a manual pre-check to guarantee idempotency.

How to eliminate wrong answers

Option A is wrong because 'state=latest' forces an upgrade check on every run, which can still trigger the same error if the package is already at the latest version and Chocolatey's state reporting is broken. Option B is wrong because using 'force' ignores the error but does not prevent the unnecessary reinstall attempt, violating idempotency and potentially causing side effects like overwriting configuration files. Option C is wrong because the win_chocolatey module does not reliably register a variable indicating 'already installed' for packages with broken state detection; the module may still fail before registering a useful result, making the 'when' condition ineffective.

Full explanation →

223

MCQmedium

An organization uses separate network hops that require different SSH usernames for different inventory groups. Which Ansible configuration approach ensures each group uses the correct SSH user without duplicating playbooks?

A.Create a group_vars directory with a file named after the group containing ansible_user.

B.Specify the SSH user in the inventory file for each host.

C.Set the ansible_user variable in ansible.cfg.

D.Define ansible_user in the playbook using vars.

AnswerA

Group vars allow per-group variable values.

Why this answer

Creating a group_vars directory with a file named after a group and setting ansible_user inside it is the best practice for assigning different SSH users per group without duplicating playbooks. Option B is incorrect because specifying the SSH user in the inventory file for each host is possible but less scalable and harder to maintain. Option C is incorrect because setting ansible_user in ansible.cfg applies globally to all hosts, not per group.

Option D is incorrect because defining ansible_user in the playbook using vars would require editing the playbook for each group, which leads to duplication and is not scalable.

Full explanation →

224

MCQeasy

What does the `| quote` filter do in an Ansible task?

A.It converts the string to uppercase.

B.It escapes shell metacharacters to prevent shell injection.

C.It returns the string wrapped in double quotes.

D.It encodes the string for use in URLs.

AnswerB

Correct; quote filter escapes characters for safe shell usage.

Why this answer

The `| quote` filter in Ansible is designed to escape shell metacharacters (e.g., spaces, semicolons, backticks, dollar signs) in a string, ensuring that the value is safely passed to a shell command without risk of shell injection. This is critical when using variables in `command` or `shell` modules where user-supplied data could otherwise break the command or introduce security vulnerabilities.

Exam trap

The trap here is that candidates often confuse `quote` with simply adding double quotes (option C), but the filter performs active escaping of dangerous characters, not just wrapping, which is a subtle but critical distinction for security in automation tasks.

How to eliminate wrong answers

Option A is wrong because `| quote` does not convert strings to uppercase; that is the function of the `| upper` filter. Option C is wrong because `| quote` does not simply wrap the string in double quotes; it escapes metacharacters according to shell rules, which may include quoting but is not limited to double quotes. Option D is wrong because `| quote` does not encode strings for URLs; URL encoding is performed by the `| urlencode` filter.

Full explanation →

225

Drag & Dropmedium

Drag and drop the steps to configure a basic NFS server to export a directory in the correct order.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

Why this order

To configure a basic NFS server to export a directory, the correct sequence is: install the NFS packages (e.g., nfs-utils), create the directory to be shared, edit /etc/exports to define the export, start and enable the NFS server service, and finally verify the export using 'showmount -e localhost'. This workflow ensures that all prerequisites are met before each step, avoiding errors such as missing directories or unapplied configuration.

Full explanation →

Red Hat Certified Engineer EX294 (EX294) — Questions 151–225