EX294 Practice Test 36 — 15 Questions

Question 1

A company has deployed Ansible Automation Platform with a single automation controller node. The operations team uses a workflow that includes three job templates: A, B, and C, each requiring different credentials. Recently, the workflow started failing intermittently with errors such as 'Timeout' and 'Connection refused' on certain hosts. The inventory is dynamic from a cloud provider. The administrator checks that the credentials are valid and the hosts are online. The job execution history shows that the failures occur only when the workflow attempts to run job template B on a subset of hosts that are located in a different subnet. Job templates A and C run fine on all hosts. What is the most likely cause and the best course of action?

Accepted Answer

The credential used by job template B is associated with an incorrect SSH key for those hosts; create a new credential for that subnet and update the job template.. Option B is correct because the intermittent failures on a specific subnet, despite valid credentials and online hosts, strongly indicate that the SSH key or credential used by job template B is not accepted by those hosts. Since job templates A and C work fine on all hosts, the issue is credential-specific, not network-wide. Creating a new credential with the correct SSH key for that subnet and updating job template B resolves the authentication failure.

Answer

The hosts in the problematic subnet are not reachable due to a firewall; add those hosts to a separate inventory and use a different cloud credential.

Answer

The automation controller does not have network access to the problematic subnet; install a second automation controller node in that subnet and configure clustering.

Answer

The job template B requires a sudo escalation that is not configured on those hosts; update the playbook to use become_method: su.

Question 2

An organization uses ansible-builder to create an execution environment (EE) for network automation. The EE includes a custom collection 'acme.network' that requires the 'netaddr' Python library. The ansible-builder definition file (execution-environment.yml) lists 'netaddr' in the requirements.txt under dependencies.python. After building the EE and pushing it to the local registry, a user runs ansible-navigator with the EE and executes a playbook that uses a module from 'acme.network'. The playbook fails with an error that 'netaddr' is not installed. The user checks the running container and confirms that 'netaddr' is installed via pip list. What is the most likely cause?

Accepted Answer

The Python environment in the EE has multiple versions and netaddr is installed in the wrong one.. Option D is correct because execution environments built with ansible-builder can contain multiple Python interpreters (e.g., system Python and a virtual environment). The 'netaddr' library might be installed in the system Python but the Ansible controller process inside the EE runs from a different Python environment (often a virtual environment under /usr/share/ansible). When the playbook executes, it imports from the wrong Python, causing the 'not installed' error despite pip list showing the package.

Answer

The base image for the EE does not include the required system packages for 'netaddr'.

Answer

The collection 'acme.network' is not installed in the EE.

Answer

The ansible-navigator command is using a different EE than the one built.

Question 3

You are responsible for maintaining a team of 10 Ansible developers. They all rely on a shared collection stored in a private Git repository. Recently, multiple developers reported that their playbooks are failing because they have different versions of the collection installed locally. You decide to standardize the environment by creating a consistent Ansible execution environment. You have a base image of Red Hat Enterprise Linux 8.6, and you need to include the collection from the Git repository. Additionally, the execution environment should be rebuilt automatically whenever the collection is updated. Which approach should you take?

Accepted Answer

Write an execution-environment.yml that specifies the base image and uses the 'git' option under 'dependencies' to pull the latest collection from the Git repo, then configure a webhook to rebuild the image on each push.. Option B is correct because it uses an execution-environment.yml file with the 'git' option under 'dependencies' to pull the collection directly from the private Git repository during the image build process. This ensures that every build includes the latest version of the collection, and by configuring a webhook (e.g., from GitLab or GitHub) to trigger a rebuild on each push, the environment is automatically standardized across all developers. This approach directly addresses the version inconsistency problem by creating a consistent, version-controlled execution environment.

Answer

Use ansible-navigator to run the playbooks directly from the Git repository without building an execution environment.

Answer

Create a requirements.yml file for the developers to install the collection manually on their local machines.

Answer

Build the execution environment once using ansible-builder and distribute the resulting container image to all developers manually.

Question 4

Your team maintains a collection that includes custom modules and plugins. You have been tasked with creating a content collection that adheres to the Red Hat Ansible Content Collection requirements. You have created the directory structure and written the collection code. Now you need to package the collection for distribution to your internal automation hub. You run 'ansible-galaxy collection build' and it completes successfully, generating a tarball. However, when you try to publish it to your private automation hub using 'ansible-galaxy collection publish', you get an authentication error. You have verified that your automation hub server URL and API token are correct. What is the most likely cause of the error?

Accepted Answer

The 'namespace' or 'name' in galaxy.yml does not match the namespace you are allowed to publish to on the automation hub.. The authentication error despite correct server URL and API token indicates that the issue is not with credentials or connectivity, but with authorization. Ansible Automation Hub enforces namespace-based access control: the `namespace` field in `galaxy.yml` must match a namespace you are permitted to publish to. If the namespace does not match, the hub rejects the upload with an authentication/authorization error, even though the token itself is valid.

Answer

The automation hub server is not reachable from your network.

Answer

The collection tarball is corrupted and needs to be rebuilt.

Answer

The collection contains a module that violates a content policy enforced by the hub.

Question 5

Your organization is migrating from manually maintained control nodes to using execution environments. You have created an execution environment that includes all necessary collections and Python dependencies. You want to ensure that developers use this execution environment when running playbooks. You have configured ansible-navigator on their workstations. However, some developers report that when they run a playbook, it uses the local installation of Ansible instead of the execution environment. What should you check first?

Accepted Answer

Ensure that the developers are using the 'ansible-navigator run' command instead of 'ansible-playbook'.. The correct answer is B because `ansible-navigator` is the CLI tool designed to run Ansible inside an execution environment. If developers run `ansible-playbook` directly, it uses the locally installed Ansible, bypassing the execution environment entirely. The question states that `ansible-navigator` is configured on their workstations, but the developers must use the `ansible-navigator run` subcommand to invoke playbooks within the containerized environment.

Answer

Confirm that the developers have installed ansible-builder locally.

Answer

Verify that the ansible-navigator configuration file points to the correct execution environment image.

Answer

Check that the execution environment container is running on the developers' machines.

Question 6

Your security team requires that all containers used in production must be scanned for vulnerabilities and must not contain any unnecessary packages to reduce attack surface. You are building an execution environment based on the 'ee-minimal-rhel8' image from Red Hat. You need to add a custom Python library named 'my_lib' that is available on a private PyPI server. You also need to install a collection from a private Git repository. The execution environment must be as small as possible. Which approach to building the execution environment satisfies the security and size requirements?

Accepted Answer

Use a multi-stage build in the execution-environment.yml by specifying 'additional_build_steps' to first install build dependencies, then install the library and collection, and finally remove build dependencies.. Option A is correct because a multi-stage build in the execution-environment.yml using 'additional_build_steps' allows you to install build dependencies (e.g., gcc, python3-devel) needed to compile 'my_lib', install the library from the private PyPI server, install the collection from the private Git repository, and then remove all build dependencies in a subsequent stage. This results in a final image that contains only the runtime artifacts, minimizing the attack surface and image size, satisfying the security and size requirements.

Answer

Use the 'dependencies' key for the Python library and the 'git' option for the collection, which automatically handles minimization.

Answer

Build a custom base image that already includes the library and collection, then reference it as the base image.

Answer

Add the library and collection installation commands to the 'additional_build_steps' section without any cleanup steps.

Question 7

An enterprise is running Ansible Automation Platform with automation mesh across three data centers. Each data center has a control node and multiple execution nodes. The mesh topology is set up with `node_type: control` for control nodes and `node_type: execution` for execution nodes. The nodes in DC2 can reach nodes in DC1 and DC3, but DC1 and DC3 cannot directly reach each other. The admin notices that jobs that require execution on DC3 are being scheduled on DC1 or DC2, causing slow performance. The admin checks the mesh node list and sees all nodes are healthy. What should the admin do to ensure jobs are executed geographically closest to the target nodes?

Accepted Answer

Configure `node_policy` to set `topology=dc3` on execution nodes in DC3 so the controller can route jobs based on proximity.. Option D is correct because `node_policy` with `topology` allows administrators to define geographic or logical proximity hints for execution nodes. By setting `topology=dc3` on DC3 nodes, the automation controller can intelligently route jobs to the nearest available execution node, reducing latency without requiring direct network connectivity between DC1 and DC3.

Answer

Establish a direct VPN link between DC1 and DC3 to reduce latency.

Answer

Change the `node_type` of DC3 execution nodes to `control` to make them preferred.

Answer

Create host labels to tag nodes by data center and assign job templates accordingly.

Question 8

A company manages a large infrastructure of 10,000 servers using Ansible. The Ansible control node runs on a powerful machine with 32 cores and 64GB RAM. Recently, a playbook that processes server facts and generates a compliance report has become extremely slow, taking over 6 hours to complete. The playbook uses several `set_fact` tasks with complex jinja2 filters including `selectattr`, `map`, `json_query`, and `combine`. The inventory is stored in a dynamic inventory script that returns JSON. The team suspects that the filter operations are causing performance bottlenecks, especially when creating large data structures. A junior engineer suggests splitting the playbook into multiple plays and using `delegate_to` to distribute processing across managed nodes. Another suggests using the `ansible.builtin` module instead of filters. The senior architect recommends converting the heavy filter logic into a custom action plugin. What is the most effective approach to significantly reduce the execution time while maintaining functionality?

Accepted Answer

Convert the heavy filter logic into a custom Python action plugin that runs on the control node and performs data transformation efficiently.. Option C is correct because custom action plugins execute Python code directly on the control node, bypassing the Jinja2 templating engine entirely. This eliminates the overhead of parsing complex filters like `json_query` and `combine` for every host, which is the primary bottleneck when processing large data structures across 10,000 servers. Action plugins also have full access to Ansible's internal APIs, allowing efficient in-memory data transformations without the serialization/deserialization costs of `set_fact`.

Answer

Distribute the processing across managed nodes using `delegate_to` and loop over hosts.

Answer

Use `ansible.builtin` modules to replace filter operations; for example, use `add_host` and `group_by` to structure data.

Answer

Use `with_items` and `with_nested` loops instead of filters, as loops are faster.

Question 9

An administrator is writing a playbook to manage multiple web servers. The playbook uses a variable "server_facts" which is a list of dictionaries with keys "hostname", "ip", and "status". The administrator needs to extract a list of all hostnames where status is "online". The administrator writes:

- name: Get online hosts
  set_fact:
    online_hosts: "{{ server_facts | selectattr('status', '==', 'online') | map(attribute='hostname') | list }}"

However, when running the playbook, the "selectattr" filter fails with an error: "Invalid data passed to filter". The administrator checks the structure of "server_facts" and confirms it is a list of dicts with the expected keys. What is the most likely cause of the error?

Accepted Answer

The "status" key exists but its value is not consistently a string; some entries have integer 0/1 instead of "online"/"offline".. The `selectattr` filter in Ansible uses Jinja2's `selectattr` which relies on Python's `attrgetter` and comparison operators. If the `status` key exists but its value is not consistently a string (e.g., some entries have integer 0/1 instead of 'online'/'offline'), the equality comparison `'==', 'online'` will fail because an integer cannot be compared to a string in this context, causing an 'Invalid data passed to filter' error. The administrator confirmed the structure is correct, so the issue is likely a type mismatch in the values.

Answer

The "map" filter cannot be chained with "selectattr" directly.

Answer

The "list" filter is unnecessary and causes the error.

Answer

The "selectattr" filter requires Python 3.8 or later.

Question 10

An Ansible playbook is used to generate configuration files for network devices. The variables are defined in a vars file like:
---
interfaces:
  - name: GigabitEthernet1
    ip: 192.168.1.1/24
  - name: GigabitEthernet2
    ip: 10.0.0.1/24

The playbook uses a Jinja2 template to render the config. The template iterates over interfaces and writes "ip address" lines. However, the designer wants to support an additional field "secondary_ips" which is a list of IP addresses (e.g., ["192.168.2.1/24", "192.168.3.1/24"]). In the template, they want to generate multiple "ip address" lines for each interface, one for the primary IP and one for each secondary IP. The following template fragment is used:
{% for iface in interfaces %}
interface {{ iface.name }}
 ip address {{ iface.ip }}
{% for sec in iface.secondary_ips|default([]) %}
 ip address {{ sec }}
{% endfor %}
{% endfor %}

This works when secondary_ips is defined. However, some interfaces have secondary_ips defined as a string (e.g., "192.168.2.1/24") instead of a list. The playbook fails because the inner loop tries to iterate over a string. The engineer wants to normalize the data in the playbook before passing to the template, so that secondary_ips is always a list. Which of the following set_fact tasks will correctly transform the interfaces list to ensure secondary_ips is always a list (even if missing or a string)?

Accepted Answer

- set_fact:
    interfaces: "{{ interfaces | map('combine', {'secondary_ips': (item.secondary_ips is undefined or item.secondary_ips is none) | ternary([], (item.secondary_ips is string) | ternary(item.secondary_ips | split(','), item.secondary_ips))}) }}"
  loop: "{{ interfaces }}". Option D correctly uses the `ternary` filter to handle three cases: when `secondary_ips` is undefined or None (returns an empty list), when it is a string (splits it into a list), and when it is already a list (returns it unchanged). This ensures the template always receives a list for iteration, preventing the 'iteration over string' error.

Answer

- set_fact:
    interfaces: "{{ interfaces | map('combine', {'secondary_ips': item.secondary_ips | default([]) | split(',') if item.secondary_ips is defined and item.secondary_ips is string else item.secondary_ips | default([])}) }}"
  loop: "{{ interfaces }}"

Answer

- set_fact:
    interfaces: "{{ interfaces | map('combine', {'secondary_ips': [item.secondary_ips | default('')] | flatten }) }}"
  loop: "{{ interfaces }}"

Answer

- set_fact:
    interfaces: "{{ interfaces | map('combine', {'secondary_ips': item.secondary_ips | default([]) | string | split(',') | list}) }}"
  loop: "{{ interfaces }}"

Question 11

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?

Accepted Answer

chain: "{{ (item.dport in [80,443]) | ternary('INPUT', 'FORWARD') }}". Option B is correct because 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`.

Answer

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

Answer

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

Answer

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

Question 12

Your team manages a large Ansible Tower environment with multiple organizations. Each organization has its own projects, inventories, and job templates. You need to create a set of cloud credentials (AWS access key) that can be used by any job template in any organization, but you want to restrict modification of the credential to only a few administrators. What is the best way to achieve this while maintaining flexibility?

Accepted Answer

Create a single credential in the global 'Default' organization and use Tower's RBAC to grant read access to all users and admin access to a few.. Option D is correct because Ansible Tower's RBAC allows you to create a single credential in the global 'Default' organization and then assign read permissions to all users (allowing them to use the credential in job templates) while restricting admin (write/modify) access to a few administrators. This approach maintains flexibility by making the credential available across all organizations without duplication or manual synchronization.

Answer

Store the access key in an external secrets management vault and reference it via an encrypted file in the project.

Answer

Create a separate credential in each organization and synchronize the keys manually.

Answer

Create a custom credential type that all users create their own instance of.

Question 13

As an Ansible Tower administrator, you are tasked with setting up a job template that interacts with multiple cloud providers. The job template uses a custom credential type that includes two fields: 'api_token' (type password) and 'region' (type text). During a test run, the job fails with an error that the 'region' variable is not defined in the playbook. The playbook references {{ region }} and {{ api_token }}. You verified that the credential is assigned to the job template and the values are populated. What is the most likely issue?

Accepted Answer

The playbook uses the variable names without the credential-specific prefix.. Option A is correct because in Ansible Tower/AWX, when a custom credential type is used, the variables defined in the credential's injector configuration are automatically prefixed with the credential name (or a custom namespace) when injected into the job environment. If the injector does not explicitly map the fields to the exact variable names used in the playbook (e.g., `region` and `api_token`), the playbook will fail with an undefined variable error. The most likely issue is that the credential's injector configuration does not set the variables as `{{ region }}` and `{{ api_token }}` without a prefix, or the playbook is expecting the variables without the credential-specific namespace that Tower injects by default.

Answer

The credential is assigned to the project instead of the job template.

Answer

The 'api_token' field is encrypted but the 'region' field is not, causing a parsing error.

Answer

The 'region' field is defined as 'password' type, so it is hidden.

Question 14

You are managing a fleet of 50 RHEL 8 servers that host a critical web application. Your Ansible control node runs RHEL 8 with Ansible 2.9. The application requires a specific package 'app-pkg' that is only available from a private YUM repository. The repository is configured on each server via a role 'repo_config'. Recently, after a security update, the repository GPG key was changed. Now, when you run the playbook to install 'app-pkg' on all servers, it fails on some servers with the error: "GPG check FAILED: key ID mismatch". On other servers, the installation succeeds. All servers have the same OS version and are configured identically via the same role. The playbook uses the 'yum' module with 'state: present'. You verify that the GPG key file on the control node is the correct new key and that the role copies it to the servers. What is the most likely cause and the best course of action?

Accepted Answer

Add a task before installing the package to clean the yum cache using the 'command' module: 'yum clean all'. This ensures the new GPG key is used.. Option A is correct because the 'GPG check FAILED: key ID mismatch' error indicates that the yum cache on some servers still holds the old GPG key metadata. Running 'yum clean all' before installing the package forces yum to refresh its metadata and re-import the new GPG key from the repository, resolving the mismatch. Since the role copies the new key file, the issue is not the key file itself but stale cached metadata.

Answer

The repository URL might be incorrect on some servers. Use the 'uri' module to test connectivity to the repository.

Answer

The role is not copying the new GPG key to all servers. Re-run the role with 'force: yes' to ensure the key is overwritten.

Answer

Add 'disable_gpg_check: yes' to the task to bypass the GPG check temporarily.

Question 15

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?

Accepted Answer

The execution environment used by the job template has no route to the controller's IP address on port 22.. Option B is correct because the execution environment may not have network access to reach the control node, causing connection timeout on delegate_to. Option A is wrong because the play is starting, indicating connection success. Option C is wrong because the manual run succeeded, so playbook is fine. Option D is wrong because SSH is not used for delegate_to localhost.

Answer

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

Answer

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

Answer

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