Red Hat Certified Engineer EX294 (EX294) — Questions 226–300

Ansible INI inventory files use square-bracketed group names followed by one host per line. The correct content defines the `app` group with app1 and app2 on separate lines, and the `db` group with db1. The other options use invalid syntax such as key-value pairs, non-standard keywords, or comma-separated hosts, which Ansible would not parse as intended.

The correct matches are: ansible_distribution -> OS distribution name, ansible_os_family -> OS family, ansible_architecture -> CPU architecture. Common confusions include mistaking memory units (MB vs GB) and hostname vs IP address.

`csvfile` is a built-in Ansible lookup plugin that reads data from CSV files, allowing playbooks to parse structured tabular data. It is documented in the official Ansible lookup plugin list and is commonly used for dynamic inventory or configuration values.

C is correct because the `serial: 1` directive in an Ansible playbook controls the number of hosts that are updated simultaneously. Setting `serial: 1` forces Ansible to execute the playbook on one host at a time, ensuring that the web application is updated sequentially across the 10 servers, which minimizes downtime by keeping the other 9 servers available during each individual update.

The correct files are `requirements.yml` for Ansible collections and roles, and `requirements.txt` for Python packages. These are referenced by the `execution-environment.yml` file and are used by `ansible-builder` to install the necessary dependencies into the execution environment.

Role dependencies declared in meta/main.yml cause the dependent role to execute before the current role. This ensures the 'common' role's package installation runs first whenever 'web' is applied, regardless of the playbook. It is the intended way to express that one role requires another, keeping the relationship self-contained within the role.

The `ansible-vault view` command decrypts the file in memory and displays its contents to stdout without modifying the encrypted file on disk. This is the correct choice because the administrator only needs to see the decrypted value of 'db_password' and does not want to change the file.

Automation controller includes external logging configuration that forwards activity stream data and job events to syslog, Splunk, Elastic, or other aggregators. Enabling it centralizes logs for search and SIEM correlation without custom plugins, host mounts, or API polling jobs.

In Ansible Automation Controller, credentials are scoped to organizations. By creating credentials within each organization and assigning organization-level access, the administrator ensures that credentials are only visible and usable by members of that organization. This leverages the built-in role-based access control (RBAC) that isolates resources by organization, preventing cross-organization credential access.

The most direct method to conditionally run tasks based on a fact is to use a when condition on the tasks. Since Ansible gathers facts by default, ansible_processor_vcpus is available, and the condition will evaluate correctly per host. This ensures that only hosts with more than 4 vCPUs execute the configuration, while others skip it.

The execution environment definition file (EE.yml) specifies dependencies via external files like requirements.txt for Python packages. To install the 'requests' library, the requirements.txt file must explicitly list 'requests' as a dependency. Without it, the build process will not include the library, regardless of other configuration options.

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.

The `podman_container` module is part of the `containers.podman` collection, which must be installed from Ansible Galaxy before it can be used in a playbook. The correct command is `ansible-galaxy collection install containers.podman`, which downloads and installs the collection into the local collections path, making all its modules and plugins available.

The `execution-environment.yml` file supports a `dependencies` key with a `python` subkey that points to a `requirements.txt` file. This is the standard method defined by the Ansible Builder specification for including custom Python packages in an execution environment, ensuring they are installed during the build process.

The 'run_once: true' directive ensures a task runs only on the first host in the batch and that the results are applied to all hosts. This is ideal for one-time operations. The other options either delegate to the control node, change batching, or affect error handling, none of which satisfy the specific requirement.

Ansible does not persist playbook progress between runs. When you rerun a playbook, it targets the entire inventory by default, so hosts from the first batch are processed again. To avoid re-updating already-successful hosts, you would need to use `--limit` with a list of remaining hosts or implement a custom serial strategy that records completed batches externally.

The manifest that describes a collection to Galaxy and to dependency resolution is `galaxy.yml`, which holds version, license, and the `dependencies` mapping. Runtime requirements live elsewhere, and consumer-side requirement files are unrelated to how the collection itself is described when packaged.

The serial keyword is the standard way to define rolling update batch size in an Ansible play. Setting serial: 2 causes the play to process two hosts at a time through the full task list, ensuring only two of the eight web servers are updated concurrently. This is the direct and correct control for the administrator's requirement.

`ansible-vault edit` decrypts the file to a temporary file, opens it in the default editor (e.g., vi), and upon saving, re-encrypts it transparently. This prevents the decrypted content from ever being written to the terminal history or logs, as the editing happens in a secure temporary location that is cleaned up after the editor closes.

The run_once keyword ensures the task is executed only on the first host in the play, regardless of how many hosts are targeted. When combined with delegate_to: localhost, the task runs once on the control node, generating a single report. Other keywords like serial, throttle, or any_errors_fatal affect batching, concurrency, or error handling, not single execution.

The 'ansible.builtin.include_role' module supports the 'vars' keyword to pass variables directly to the included role. This allows you to override or supply role variables at the point of inclusion, which is a common pattern for reusing roles with different configurations.

The error 'No matching manifest for linux/amd64 in the manifest list entries' indicates that the base image specified in the execution environment definition file does not have a container image manifest for the host's CPU architecture (linux/amd64). Ansible Builder pulls the base image from a registry, and if that image only supports other architectures (e.g., linux/arm64), the build fails. This is a common issue when using a base image built for a different platform.

The `run_once` directive ensures that a task is executed only on the first host in the play, and the results are applied to all hosts. This is ideal for actions that should not be repeated per host, such as creating a shared resource. Other options either still execute per host or only control concurrency.

`ansible-builder` is the official tool for building Ansible execution environments, which are container images that bundle Ansible, collections, and dependencies. It uses a definition file (execution-environment.yml) to specify collections and Python packages, then builds the container image. Option E is correct because a `requirements.yml` file is the standard way to list Ansible collections for inclusion in an execution environment, and `ansible-builder` reads this file during the build process.

The correct matches are: LVM for flexible disk management with VGs and LVs, RAID for combining disks for redundancy/performance, Stratis for pool-based snapshots and thin provisioning, and VDO for block-level deduplication/compression. Common confusions include swapping LVM with VDO and RAID with Stratis.

It allows you to set the variable `libapp_version` that the role expects without modifying the role itself. By defining `libapp_version` in the playbook's vars section or passing it as a role parameter, you override the role's default value (2.0) with the required version 1.2, ensuring the task uses the correct library version while preserving role integrity.

A lookup plugin is the correct choice because it is designed to retrieve data from external sources (like an API) and return it as a string or list for use in Ansible playbooks. This aligns with the requirement to fetch secrets from an external API, and lookup plugins can be used directly in variables or templates without modifying the host state.

Ansible collections have a defined structure where plugins, including modules, are stored under the plugins directory. Modules specifically go in plugins/modules. This structure allows Ansible to automatically discover and load the module when the collection is installed, making it available for use in playbooks via the collection's fully qualified name.

Ly 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.

Ansible Tower/AWX allows multiple credentials of different types to be assigned to a single job template. A machine credential handles SSH authentication for target hosts, while a source control credential manages authentication for the project repository (e.g., Git). This separation follows Ansible's modular credential design, where each credential type serves a distinct purpose and can be independently managed.

Include_tasks, because it dynamically loads and evaluates task files at runtime, allowing conditional logic and per-host variables to be resolved when the tasks are executed. This is essential for reusing a set of tasks that conditionally include other task files based on variables defined per host, as include_tasks processes the included file fresh each time it is encountered, respecting any host-specific variable context.

The ansible_user inventory variable sets the remote username for all connection types, including WinRM. For Windows hosts, ansible_user and ansible_password are used with the winrm connection plugin. Defining these in group_vars ensures credentials are applied consistently without modifying playbooks.

Automation controller stores credentials encrypted and injects them at run time, so keeping SSH keys in a machine credential and referencing that credential from the job template removes secrets from source control and from static inventories. Together these actions centralize secret storage and limit exposure to the moment of execution, which is the intended best practice.

The combine filter merges dictionaries, and its recursive parameter controls whether nested dictionaries are merged deeply or replaced. For nested overrides that must preserve base subkeys, recursive=True is required. Parameters like list_merge affect list handling only and do not enable recursive dictionary merging.

Ansible's 'when' clause allows conditional execution of tasks based on variables such as inventory hostname, group membership, or custom facts. By using a 'when' condition that checks the target host's identity (e.g., 'ansible_hostname' or 'inventory_hostname'), the administrator can ensure that the role's tasks run only on specific hosts, without modifying inventory structure or using separate variable files.

Ansible-vault encrypts sensitive data at rest using AES-256, and the encrypted file can be safely stored in a shared repository. The `include_vars` module then decrypts the file at runtime when the vault password is provided, allowing multiple roles to access the password without exposing it in plaintext.

In an execution-environment.yml file, custom RPM packages that are not part of the default base image must be listed under the 'dependencies' section with the 'system' key. This instructs ansible-builder to install those RPMs using the system package manager (e.g., dnf or yum) during the build process, ensuring the execution environment includes the required system-level libraries or tools.

Setting serial: 2 ensures that only 2 nodes are taken down at a time during the rolling update. With a quorum requirement of 3 out of 5 nodes, taking down 2 nodes leaves 3 online, maintaining quorum. This is the most efficient value that does not risk breaking quorum.

A vault password file is a plaintext file that contains the vault password on its first line. It is created using standard file redirection or an editor, not with ansible-vault commands. This file is then referenced with --vault-password-file during playbook runs to decrypt vault-encrypted content non-interactively.

For Windows targets, authentication over WinRM is governed by `ansible_winrm_transport`. With a username and password and no Kerberos infrastructure, setting it to `ntlm` forces NTLM authentication and resolves the connection failure. Connection type, SSH password, and become settings do not select the WinRM authentication protocol.

The yum module expects a list of strings or a comma-separated string. The variable 'packages' is a list, but when used with 'name: "{{ packages }}"', Jinja2 converts it to a string representation like "['httpd', 'mariadb-server', 'php']". The yum module does not accept that format; it needs a proper list or comma-separated string.

The error in the exhibit (typically 'Attempting to decrypt but no vault secrets found' or 'no vault password file') indicates Ansible cannot decrypt vault-encrypted content because the vault password file is missing, unreadable, or contains the wrong password. Ansible needs either --ask-vault-pass or --vault-password-file pointing to a valid file. If the file path is wrong or the password is incorrect, decryption fails before the play can run.

The `dict2items` filter is the correct choice because it converts a dictionary into a list of key-value pairs, each represented as a dictionary with `key` and `value` keys. This is the standard Ansible filter for iterating over both keys and values in a `loop` within a task, enabling access to `item.key` and `item.value`.

When TCP connectivity to PostgreSQL is confirmed but the installer fails on database operations, the problem is almost always authorization. PostgreSQL's host-based authentication rules in `pg_hba.conf` determine whether the `awx` user may connect from the controller's address with the configured authentication method. Adding an appropriate host entry, then reloading PostgreSQL, resolves the migration failure.

The most direct way to run a role only on a specific group is to target that group in the play's hosts directive. Roles run on all hosts in the play, so restricting the play's hosts restricts the role. Other options either do not filter hosts or misuse Ansible features.

A well-designed role separates low-precedence starting values from high-precedence internal constants. Defaults give callers an easy override path, while vars/main.yml protects values the role must control. Play vars, inventory host data, and mandatory extra variables all bind the role to a specific context and undermine reuse.

For a regular (non-root) user on an Ansible control node, the default location for installed collections is `~/.ansible/collections`. This is defined by Ansible's default collection search path, which includes the user's home directory under `~/.ansible/collections` for user-level installations. When a user runs `ansible-galaxy collection install` without specifying a custom path, the collection is placed in this directory by default.

Parsing the JSON string with from_json is required before any attribute-based filtering can occur. Once parsed, the nested list must be dereferenced through the 'services' key. Only then can selectattr compare each dictionary's 'state' value to 'running' and return the matching subset as a list.

The `vars_files` directive in a playbook allows you to specify external YAML or JSON files containing variables, which are then merged into the play's variable scope at runtime. This is a standard method for passing variables to a playbook, as it separates variable definitions from the playbook logic.

When using an external PostgreSQL database with AAP, the database must be prepared with specific extensions and the pg_hba.conf must allow the controller host to authenticate. Port reachability and correct credentials in the inventory are necessary but not sufficient. The other options either target the wrong host, introduce an unrelated change, or re-run the installer without fixing the underlying database configuration.

Defining a `requirements.yml` in the execution environment allows you to specify collections from both the private Automation Hub and external sources (e.g., Ansible Galaxy). When building the execution environment, `ansible-builder` processes this file and resolves dependencies from the listed sources, ensuring all required collections are bundled into the container image. This approach automates dependency management and avoids manual installation or repository bloat.

The 'include_tasks' module dynamically resolves the path to a task file using a variable. If that variable contains a Jinja2 template error (e.g., undefined variable, syntax mistake, or filter misuse), Ansible will fail with a 'template error' message during the variable expansion phase, before the task file is even loaded. This explains why the error occurs only on hosts where the variable's value or context triggers the template failure.

The `serial: 1` directive in an Ansible playbook controls the batch size of hosts that are updated simultaneously. Setting it to 1 ensures that only one host is updated at a time, which minimizes downtime by allowing the rest of the fleet to remain available while each server is sequentially updated.

In Ansible, role dependencies are defined in the `meta/main.yml` file using the `dependencies` key. This ensures that any listed roles are executed before the main role's tasks, providing a controlled execution order. The `meta/main.yml` file is specifically designed for metadata such as dependencies, author information, and supported platforms.

The `throttle` keyword limits the number of concurrent executions of a task across all hosts. By setting `throttle: 1` on the restart task, you ensure that only one host restarts the web service at a time, even within a batch of 2. This maintains the rolling update's goal of minimizing downtime while keeping the batch size efficient.

To publish a collection to Automation Hub, you first build it into a tarball using ansible-galaxy collection build, then publish that tarball using ansible-galaxy collection publish. These two commands form the standard build and publish workflow, ensuring the collection is packaged correctly and uploaded to the repository.

The `progressDeadlineSeconds` parameter specifies the maximum duration (in seconds) that a deployment can make no progress before it is considered to have failed. When this deadline is exceeded, the deployment controller automatically triggers a rollback to the previous revision. This is the correct parameter for automatically rolling back a failed rolling update where new pods crash immediately.

The correct command to initialize a new Ansible collection structure is `ansible-galaxy collection init <namespace.collection>`. This creates the required directory layout, including `galaxy.yml`, `README.md`, and subdirectories like `roles/`, `playbooks/`, and `plugins/`. Option D matches this syntax exactly.

In Ansible execution environments, Python dependencies that are not part of the base image must be declared in the `execution-environment.yml` file under the `dependencies` key, specifically within the `python` subkey. This file is used by `ansible-builder` to build a custom container image that includes those additional Python packages. The base image already contains a standard set of Python libraries, but any extra ones needed by a collection must be explicitly listed here to be installed during the build process.

The `ansible-builder build` command is the correct tool for building an Ansible execution environment from a a definition file. The `-f` flag specifies the path to the `execution-environment.yml` file, which defines the base image, required collections, and system dependencies for the containerized environment.

In Ansible Automation Platform, when a job is in 'pending' state, it typically indicates that the automation controller has queued the job because the maximum number of concurrent jobs (capacity limit) has been reached. The controller uses a job fork limit and instance group capacity to determine how many jobs can run simultaneously; once that limit is hit, additional jobs are placed in a pending queue until capacity frees up.

Handlers by default execute at the end of the play after all tasks complete. To run them earlier, a meta: flush_handlers task must be inserted at the desired point. Other options either change failure behavior, batching, or definition location, none of which alter the execution timing of handlers.

`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.

It uses the `map` filter with the `attribute` parameter to extract the `memory_mb` value from each dictionary in the list, then pipes the resulting list of integers into the `sum` filter to compute the total. This is the standard Ansible idiom for summing a specific attribute across a list of dictionaries.