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

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.

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.

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.

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

The requirement is to cap concurrent offline hosts at 20 percent of the fleet while aborting when batch failures exceed 10 percent. With 20 nodes, 20 percent equals 4 hosts, so `serial: 20%` expresses the constraint as a percentage that scales with inventory size. `max_fail_percentage: 10` then aborts the play when more than 10 percent of the hosts in the current batch fail. Together they encode both the availability and failure-tolerance policies directly in the play.

Dynamic inclusion through include_tasks evaluates the filename expression when the task executes, after facts are available, so exactly one platform file is loaded. Static import_tasks resolves at parse time and cannot branch on facts, and tags or meta dependencies are selected by the operator or parse order rather than by host platform.

To update two hosts at a time in a six-node fleet while keeping four hosts online, the serial batch size must be two. Changing serial from 1 to 2 directly controls how many hosts Ansible targets per play iteration, halving the number of batches and shortening the rollout. Other keywords such as throttle and forks affect concurrency of task execution but do not define rolling update batch boundaries.

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.

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.

When serial is a percentage, Ansible multiplies that percentage by the total number of hosts in the play to determine each batch size. For 50 hosts at 20%, each batch contains 10 hosts. max_fail_percentage is then evaluated against the current batch, so the abort decision is based on failures among those 10 hosts, not the full inventory.

Group variables in Ansible are defined in group_vars/<group_name>.yml, and variables set there apply to all hosts in that group. Placing ansible_user in a group-specific file ensures each inventory group uses its correct SSH username without duplicating playbook logic. This is the idiomatic Ansible way to scope connection variables per group.

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.

The error 'async task did not complete within the requested time' indicates that the async timeout value (set via the async parameter) is too short for the actual task duration. The poll interval does not affect the timeout; it only controls how often Ansible checks the task status. Option B is correct because increasing the async value allows the task more time to complete.

Ansible roles can declare dependencies in the `meta/main.yml` file using the `dependencies` key. When the 'webserver' role is installed via `ansible-galaxy install`, Ansible automatically resolves and installs all listed dependencies from the same Galaxy server, ensuring 'common' is present without manual intervention.

Ansible's `copy` module is idempotent: when the source and destination files are identical (same content and checksum), the module reports `ok` rather than `changed`. On a second run with no source changes, all items in the loop will show `ok` because Ansible compares checksums and determines no copy is needed. This is the core idempotency guarantee of Ansible modules.

The `ansible-galaxy collection init` command is the correct way to create a new collection skeleton. It sets up the directory structure with the namespace and collection name, and generates essential files like `galaxy.yml` and `README.md`. Other commands either initialize roles (`ansible-galaxy init`) or serve entirely different purposes.

Ansible's package modules (such as yum, apt, or dnf) accept a list of packages in the 'name' parameter. Passing the entire list in a single task eliminates the overhead of multiple task executions, SSH connection reuse, and module setup/teardown that occur with each iteration in a loop. This reduces the number of Ansible task runs from N to 1, significantly improving performance.

The `stat` module returns a dictionary where the `stat` key contains the file status information. The correct way to check if the file exists is to reference `stat_result.stat.exists`. This ensures the conditional evaluates correctly based on the module's output.

The `default` filter is the correct mechanism because it supplies a fallback only when the variable is undefined, allowing user-provided values to take precedence. It avoids interactive prompts and precedence conflicts, and it works in any templated context. The other options either force a value, require interaction, or fail to provide a value at all.

The containerized AAP installer relies on the Podman API, which is exposed by `podman.socket`. When that socket is inactive, container operations fail even though the Podman binary is present. Enabling and starting `podman.socket`, then rerunning the installer, restores the API endpoint and allows the AAP container services to start successfully.

Because manual SSH succeeds but Ansible cannot connect, the difference lies in the identity Ansible uses. Ansible defaults to the local account name for remote logins, so when that name differs from the account holding the authorized key, the connection is refused and hosts are marked UNREACHABLE. Defining the correct remote user in inventory or on the command line restores key-based access without altering the transport.

The `map` filter is specifically designed for list manipulation in Ansible, allowing you to apply a transformation (such as extracting a specific attribute) to every element in a list. Option D is correct because the `select` filter is used to filter list items based on a condition, returning only those elements that match. Both are core Jinja2 filters commonly used in Ansible playbooks for processing lists.

Using no_log: true on tasks that handle secrets prevents their output from being logged or displayed. Storing secrets in automation controller credentials keeps them out of playbooks and job output. Together, these actions ensure sensitive data is not exposed while maintaining operational visibility.

The 'when' directive on a role inclusion evaluates the condition for each host, applying the role only where the condition is true. This is the correct method for per-host conditional role application. Tags, become, and delegate_to serve different purposes and do not provide conditional execution based on host-specific variables.

The error indicates that Ansible cannot resolve the variable 'nginx_version' during the playbook run. Since the `--check` flag only simulates changes and does not affect variable resolution, the most likely cause is that the nginx role's `defaults/main.yml` or `vars/main.yml` does not define this variable, leaving it undefined and causing the failure.

The add_host module is designed to add hosts to the in-memory inventory at runtime, enabling tasks to run on hosts not present in the static inventory. Other directives like delegate_to, local_action, and include_vars serve different purposes and do not add hosts.

`import_tasks` is a static import that is processed at playbook parse time, before any variables or loops are evaluated. Ansible does not support using `import_tasks` inside a loop (`loop:` or `with_items:`) because the import occurs once during parsing, not dynamically per iteration. To run tasks repeatedly, you must use `include_tasks`, which is processed dynamically at runtime and supports loops.

With 'serial: 1', Ansible updates one host at a time. 'max_fail_percentage: 0' means that if any host fails (0% failure tolerance), the entire playbook run is aborted immediately. When the first host fails, Ansible stops further execution because the failure percentage exceeds the threshold, and no retries or continuation occur.

The 'when' conditional and the 'group_by' module are both valid methods to limit task execution based on host facts. The 'when' clause evaluates facts per host, while 'group_by' dynamically creates groups that can be targeted in subsequent plays. Tags, delegate_to, and run_once do not provide fact-based filtering of hosts.

Ansible roles support tagging, and the `--skip-tags` option allows you to exclude all tasks within a role that share a specific tag. By assigning a unique tag to the role (e.g., `tags: skip_me`) and running the playbook with `--skip-tags skip_me`, the entire role is skipped without modifying individual tasks or hosts.

Automation Controller (formerly Ansible Tower) has a built-in setting under 'System → Logging' where you can configure a syslog server (e.g., using RFC 5424). Once configured, all job runs, playbook output, and audit events are automatically forwarded to that central syslog server without modifying any playbooks or adding custom callbacks. This is the simplest, most centralized, and most maintainable approach for audit logging.

The 'systemd' module in Ansible requires both 'enabled: yes' to set the service to start on boot and 'state: started' to ensure the service is currently running. This combination directly fulfills the requirement of ensuring a service is enabled and running on boot.

Common firewalld zones include public (default deny), trusted (allow all), external (NAT with limited inbound), dmz (limited inbound for public servers), internal (trusted but filtered), and drop (silent discard). Common confusions involve swapping the behaviors of public and trusted, or misunderstanding dmz as fully blocking instead of selectively allowing.

In Ansible, collections are distributed using a fully qualified collection name (FQCN) in the format `namespace.collection_name`. This naming convention is required by the Ansible Galaxy server and the `ansible-galaxy collection install` command to uniquely identify and install collections, minimizing namespace conflicts and ensuring discoverability across the organization.

The `--vault-password-file` option allows Ansible to read the vault password from a file, which is a standard method for providing the password non-interactively, especially in automation scripts or CI/CD pipelines. This avoids the need for manual password entry and supports secure password management.

serial defines how many hosts Ansible includes in each rolling batch. Setting serial: 1 ensures the entire play finishes on one host before the next host begins, which keeps 11 of 12 servers available to the load balancer. Other keywords such as throttle and forks affect parallelism or task concurrency, but they do not create per-host rolling batches.

The correct sequence for configuring a logical volume using LVM on a new disk is: first create a physical volume from the disk, then create a volume group from that physical volume, then create a logical volume from the volume group, then format the logical volume with a filesystem, and finally mount the filesystem to make it accessible. This order ensures that each step builds upon the previous one, following the LVM hierarchy of PV -> VG -> LV -> filesystem -> mount.

The correct sequence for configuring a systemd service to start at boot is: first create the unit file, then reload systemd to load the new unit, next enable the service to create the necessary symlinks for automatic start, then start the service immediately, and finally verify its status. Common mistakes include omitting the reload step, enabling after starting, or performing the reload too late.

In Ansible, when a task inside a `block` fails, the `rescue` section is executed immediately after the failure, without running any remaining tasks in the block. This is analogous to a try-catch mechanism in programming: the block is the 'try', and the rescue is the 'catch'. Option B correctly describes this behavior.

The AAP installer is executed by running the `setup.sh` script from the extracted directory. This script reads the `inventory` file and runs the necessary playbooks. Using any other command, such as `ansible-playbook` with a guessed playbook name or a nonexistent `install.sh`, will not perform the installation correctly.

The Injector configuration for a custom credential type in Ansible Automation Platform uses the `env` key to map credential inputs to environment variables. The syntax `env: {"MY_API_KEY": "{{ api_key }}"}` correctly references the input field `api_key` using Jinja2 templating and assigns it to the environment variable `MY_API_KEY`, which the playbook can then access via `ansible_env.MY_API_KEY`.

The `state` attribute is a core parameter of the `ansible.builtin.service` module, used to define the desired service status (e.g., `started`, `stopped`, `restarted`, `reloaded`). This directly controls the service's runtime state on the target system.

When `serial: 5` is set, Ansible processes hosts in batches of five. If one host in the batch takes an unusually long time to complete its tasks (e.g., due to a slow network, a hanging service restart, or a long-running command), the entire batch will appear to hang because Ansible waits for all hosts in the current batch to finish before proceeding to the next batch. This is the most likely cause of the observed behavior during a rolling update.

The error 'Permission denied' during SSH connection to a target host indicates an authentication failure. Since the machine credential appears correct, the most immediate cause is that the username or private key/password stored in the credential is incorrect or mismatched. This is the first thing to check because the credential directly controls authentication to the target host.

The `difference` filter in Ansible returns the elements of the first list that are not present in the second list. This directly matches the requirement: all hosts in the 'webservers' group that are not in the 'drain' subgroup.

The failure in check mode indicates that the /var/www/html directory does not exist, and the apache role's copy task cannot write to it. The correct fix is to add a task in the apache role that uses the file module to create the directory with the desired state (e.g., state: directory), ensuring idempotency because the task will only create it if absent. This keeps the role self-contained and maintains idempotent behavior.

The error indicates Ansible cannot find the variable 'vault_httpd_port' because the encrypted vault file containing it is not being loaded into the playbook's variable scope. The administrator must first verify that the vault file is properly referenced via include_vars or vars_files in the playbook, and that the correct vault password is supplied (e.g., via --ask-vault-pass or a vault password file). Without loading the vault file, the variable remains undefined regardless of encryption password changes.

In Ansible, the `reject` filter removes elements from a list that match a given condition, effectively selecting only those that do not match. The `select` filter does the opposite: it keeps elements that match the condition. Both are used for conditional selection from a list based on a test, making C and D correct.

The 'free' strategy in Ansible allows each host to run through the playbook independently, without waiting for other hosts to finish the current task. This means a faster host can proceed to subsequent tasks while slower hosts are still working on earlier tasks, maximizing parallelism and reducing overall execution time.

Package facts are stored as a dictionary keyed by package name, with each value being a list of records. Extracting versions therefore requires converting the mapping to items, filtering keys, unwrapping the value lists with flatten, and then mapping the version attribute. Pipelines that skip the flatten step or that treat the dictionary as a list of objects cannot reach the nested version field.

The `until` loop with `retries` and `delay` parameters is the correct approach because it allows a task to be retried a specified number of times with a configurable pause between attempts, directly addressing transient network failures. This is a built-in Ansible feature for handling intermittent issues without additional error-handling constructs.

The correct order is to parse the raw JSON string first with `from_json`, then traverse the nested structure with `json_query`, and finally cast the extracted value with `int`. Reversing or substituting `to_json` breaks the pipeline because it serializes rather than parses. Using `map` is inappropriate for a single dictionary input, and querying before parsing cannot succeed on a raw string.

The correct command to download and install a collection from Automation Hub to the default collections path is `ansible-galaxy collection install`. This command uses the `ansible-galaxy` utility, which is the standard tool for managing Ansible roles and collections, and the `collection install` subcommand specifically handles collection installation from configured sources like Automation Hub or Ansible Galaxy.

The yum module manages packages, service manages system services, and copy transfers files from local to remote. Common confusions include swapping definitions or using the wrong direction for file transfers.

Ansible collections store custom modules in the 'plugins/modules' directory within the collection's installation path on the control node. Navigating to that directory allows you to view the module's source code directly, which is the most reliable way to locate it when documentation is missing.

Roles are the standard Ansible mechanism for packaging and reusing tasks, variables, handlers, and other automation content across multiple playbooks. By placing tasks in a role's `tasks/main.yml`, the administrator can reference that role in any playbook using the `roles:` directive, enabling clean, modular reuse without duplication.

Ansible Vault is the correct feature for securely storing SSH private keys because it encrypts sensitive data at rest using AES-256, allowing keys to be decrypted at runtime when a vault password or key is provided. This enables playbooks to reference encrypted SSH key files without exposing plaintext credentials in version control or on disk.

A shared vault credential in automation controller allows multiple job templates to use the same secret. Rotating the password only requires updating the credential, which automatically applies to all attached job templates. This is both efficient and secure, as the credential is encrypted and access-controlled.