Courseiva

Red Hat Certified Engineer EX294 (EX294) — Questions 76–150

518 questions total · 7pages · All types, answers revealed

Take a mock examExam hub
Page 1

Page 2 of 7

Page 3
76
MCQhard

Refer to the exhibit. A developer builds an execution environment using this execution-environment.yml. After building, the container starts but ansible-navigator cannot connect to the container because the required SSH packages are missing. Which file most likely needs to be updated?

A.The base image itself
B.requirements.yml
C.requirements.txt
D.bindep.txt
AnswerD

Contains system package dependencies.

Why this answer

D is correct because `bindep.txt` specifies system-level package dependencies (like `openssh-clients` or `sshpass`) that must be installed in the container image. When building an execution environment, `ansible-builder` reads `bindep.txt` to install RPM packages via `dnf` (or `apt` on Debian-based images). If SSH packages are missing, the `bindep.txt` file is the most likely place to add them, as it directly controls which system packages are included in the final image.

Exam trap

Red Hat often tests the distinction between system-level dependencies (`bindep.txt`), Python dependencies (`requirements.txt`), and Ansible collections (`requirements.yml`), and the trap here is that candidates confuse `requirements.txt` (Python packages) with system packages, leading them to incorrectly select option C.

How to eliminate wrong answers

Option A is wrong because the base image itself (e.g., `quay.io/ansible/ansible-runner:latest`) is a pre-built container that already includes Ansible and Python but does not include SSH client packages by default; modifying the base image is not the standard approach—`bindep.txt` is the intended mechanism. Option B is wrong because `requirements.yml` is used to install Ansible collections from Galaxy or Automation Hub, not system packages like SSH clients. Option C is wrong because `requirements.txt` is used to install Python packages via `pip` (e.g., `ansible-core`, `pywinrm`), not RPM-level dependencies like `openssh-clients`.

Full explanation →
77
MCQhard

Refer to the exhibit. The playbook fails because the httpd package is not found. Which is the most likely cause?

A.The inventory does not define 'webservers' group.
B.The role path is incorrectly configured in ansible.cfg.
C.The target host does not have the necessary repositories enabled.
D.The 'yum' module should use 'name=httpd' instead of YAML syntax.
AnswerC

The package httpd is not found, indicating repositories are missing or not enabled.

Why this answer

The error indicates the package is not available. This is typically due to missing or incorrect repository configuration. The playbook itself and role syntax are valid.

Full explanation →
78
MCQmedium

Your organization uses Ansible Automation Platform 2.2 with private Automation Hub. You have developed a custom collection named 'my_company.network' that depends on 'cisco.ios' and 'vyos.vyos'. The collection is published in your private hub. You are building an execution environment using ansible-builder. The execution-environment.yml specifies 'EE_BASE_IMAGE: registry.redhat.io/ansible-automation-platform-22/ee-supported-rhel8:latest'. The dependencies section points to a requirements.yml file that includes your collection. When you run 'ansible-builder build', the build succeeds, but when running a playbook that uses modules from 'cisco.ios', you get an error 'module not found'. What is the most likely reason and the correct action to resolve it?

A.Reinstall the collection on the controller node using 'ansible-galaxy collection install'
B.Use a different base image that includes 'cisco.ios'
C.Update the collection metadata to include dependencies and rebuild
D.Add 'cisco.ios' to the requirements.yml file used during the execution environment build
AnswerD

Explicitly listing the dependency ensures it is included in the execution environment.

Why this answer

The execution environment build process uses the requirements.yml file to determine which collections to include in the image. If the custom collection 'my_company.network' depends on 'cisco.ios', but that dependency is not explicitly listed in the requirements.yml, the builder will not include 'cisco.ios' in the execution environment. Adding 'cisco.ios' to the requirements.yml ensures it is installed during the build, making the module available at runtime.

Exam trap

The trap here is that candidates assume collection dependencies declared in metadata are automatically resolved during the execution environment build, but ansible-builder only installs collections explicitly listed in requirements.yml, not their transitive dependencies.

How to eliminate wrong answers

Option A is wrong because reinstalling the collection on the controller node does not affect the execution environment; the controller uses the execution environment's content, not locally installed collections. Option B is wrong because the base image 'ee-supported-rhel8' already includes many supported collections, but 'cisco.ios' is not guaranteed to be included; the issue is the build process, not the base image selection. Option C is wrong because updating the collection metadata to declare dependencies only affects the collection's metadata, but the execution environment builder does not automatically resolve transitive dependencies from the metadata; it only installs what is explicitly listed in requirements.yml.

Full explanation →
79
Multi-Selecteasy

Which TWO of the following are valid methods to install a collection from a private Automation Hub?

Select 2 answers
A.`ansible-galaxy collection install my_namespace.my_collection --server automationhub`
B.`ansible-navigator run --pp never --pull-policy missing -- ... `
C.Configure `server_list` in `ansible.cfg` under `[galaxy]` with the Automation Hub URL and then run `ansible-galaxy collection install my_namespace.my_collection`.
D.`ansible-galaxy collection install my_namespace.my_collection --server https://automationhub.example.com`
E.Download the tarball and place it in the `collections/` directory of the role path.
AnswersC, D

Uses configuration to point to the private Automation Hub.

Why this answer

Option C is correct because configuring the `server_list` in `ansible.cfg` under the `[galaxy]` section allows you to define multiple Galaxy servers, including a private Automation Hub. Once configured, `ansible-galaxy collection install` will automatically use the specified server list to resolve and install the collection. Option D is also correct because the `--server` flag directly specifies the Automation Hub URL, overriding any default server configuration for that single command.

Exam trap

Red Hat often tests the distinction between specifying a server via a keyword versus a full URL, and the fact that `ansible-navigator` is for execution environments, not collection installation, leading candidates to confuse command purposes.

Full explanation →
80
MCQmedium

Ansible Tower is configured with a dynamic inventory source from VMware vCenter. The playbook needs to limit execution to hosts with a specific custom attribute. How should this be achieved?

A.Modify the VMware inventory script to filter hosts.
B.Use a smart inventory filter.
C.Add the required hosts manually.
D.Create a new inventory source with a filter.
AnswerB

Smart inventories can filter hosts based on custom attributes from the dynamic source.

Why this answer

Smart inventories in Ansible Tower allow you to apply a filter (using Jinja2-style syntax) against an existing inventory source, such as a dynamic VMware vCenter source, to limit execution to hosts matching specific criteria like a custom attribute. This approach avoids modifying the source script or creating duplicate inventory sources, preserving the dynamic nature of the inventory while enabling targeted host selection.

Exam trap

The trap here is that candidates may think they need to modify the inventory source or script to filter hosts, not realizing that Tower's smart inventories provide a built-in, non-destructive way to apply filters on top of any existing inventory source.

How to eliminate wrong answers

Option A is wrong because modifying the VMware inventory script is not a supported or scalable method in Tower; it would break the dynamic inventory source and require manual maintenance. Option C is wrong because manually adding hosts defeats the purpose of using a dynamic inventory from vCenter and introduces management overhead. Option D is wrong because creating a new inventory source with a filter is unnecessary; smart inventories provide the filtering capability without duplicating the source, and filters are applied at the smart inventory level, not at the source level.

Full explanation →
81
MCQhard

Refer to the exhibit. A user attempts to download the collection using the download URL but the signature verification fails. What is the most likely reason?

A.The collection version does not match.
B.The user's client does not have the corresponding public key.
C.The collection is not properly signed.
D.The download URL is invalid.
AnswerB

Signature verification requires the public key; if missing, verification fails.

Why this answer

B is correct because signature verification of a downloaded collection requires the client to have the corresponding public key that was used to sign the collection. If the user's client lacks this public key, the verification process will fail, even if the collection itself is properly signed and the URL is valid.

Exam trap

Red Hat often tests the misconception that signature verification failures are always due to a corrupted or unsigned collection, when in reality the client-side public key management is a common oversight.

How to eliminate wrong answers

Option A is wrong because a version mismatch would not cause a signature verification failure; it would instead result in a different collection being downloaded or a version conflict error. Option C is wrong because if the collection were not properly signed, the signature verification would fail for that reason, but the question states the user attempts to download using the download URL, implying the collection exists and is signed; the most likely reason is the missing public key on the client side. Option D is wrong because an invalid download URL would prevent the download from starting or return a 404 error, not cause a signature verification failure after the download completes.

Full explanation →
82
Multi-Selectmedium

Which TWO are valid methods to back up an Ansible Automation Controller installation? (Choose two.)

Select 2 answers
A.Perform a `pg_dump` of the PostgreSQL database and copy `/var/lib/awx` files.
B.Use the controller UI to export configuration via `dumpconfig`.
C.Execute `awx-manage backup` on the controller node.
D.Run `./setup.sh -b` from the installer directory.
E.Use `invoke-rc.d automation-controller backup`
AnswersA, D

Manual backup of database and project data.

Why this answer

Option A is correct because backing up an Ansible Automation Controller installation requires preserving both the PostgreSQL database and the file system. The `pg_dump` command creates a logical backup of the database, while copying `/var/lib/awx` captures critical configuration files, job artifacts, and credentials stored on disk. This combination ensures a complete restore capability.

Exam trap

The trap here is that candidates may confuse `awx-manage` commands with valid backup utilities, or assume that a UI export function exists, when in fact the only supported backup methods are database dumps plus file system copies or the installer's built-in backup flag.

Full explanation →
83
Multi-Selecthard

Which TWO should be configured to enable centralized logging from multiple Automation Controller nodes to an external Elasticsearch cluster? (Choose two.)

Select 2 answers
A.Configure `logrotate` to ensure logs are not truncated before being sent.
B.Set up `rsyslog` on each node to forward application logs to Elasticsearch.
C.Install and configure `filebeat` on each controller node as a sidecar service.
D.Configure a logging aggregator in the controller's system settings to point to the Elasticsearch endpoint.
E.Enable the `CALLBACK_RECEIVER` log level to ensure callback logs are collected.
AnswersD, E

The aggregator setting sends logs to external systems.

Why this answer

Option D is correct because Automation Controller (formerly Ansible Tower) provides a built-in logging aggregator configuration in its system settings. By specifying the Elasticsearch endpoint there, the controller itself handles forwarding all relevant job and system logs from every node to the external Elasticsearch cluster, without requiring per-node agents.

Exam trap

The trap here is that candidates assume a separate log shipper like filebeat or rsyslog is required, but Automation Controller has a native logging aggregator that directly sends logs to Elasticsearch, making those external agents redundant.

Full explanation →
84
MCQeasy

The deployment has 4 replicas. During a rolling update, what is the maximum number of pods that can be unavailable at any single time?

A.2
B.4
C.0
D.3
E.1
AnswerE

25% of 4 replicas is 1 pod.

Why this answer

Option E is correct because the default rolling update strategy for a Deployment in Kubernetes sets `maxUnavailable` to 25% of the desired replicas, rounded up. With 4 replicas, 25% equals 1, so at most 1 pod can be unavailable during the update. This ensures minimal disruption while allowing the update to proceed.

Exam trap

The trap here is that candidates often assume the default `maxUnavailable` is 1 regardless of replica count, but it is actually 25% of the desired replicas, rounded up, so with 4 replicas it is 1, but with 5 replicas it would be 2 (25% of 5 = 1.25, rounded up to 2).

How to eliminate wrong answers

Option A is wrong because 2 would correspond to a `maxUnavailable` of 50%, which is not the default and would require explicit configuration; the default is 25%. Option B is wrong because 4 would mean all pods could be unavailable simultaneously, which contradicts the rolling update strategy's goal of maintaining availability; this would be a recreate strategy. Option C is wrong because 0 would require `maxUnavailable` to be set to 0, which is possible but not the default; the default allows some unavailability to speed up the update.

Option D is wrong because 3 would correspond to 75% unavailability, which is not the default and would cause excessive disruption; the default is 25%.

Full explanation →
85
Multi-Selecthard

Which THREE considerations are important when using dynamic inventories in Ansible Tower?

Select 3 answers
A.Dynamic inventory groups can be nested under static groups.
B.Each inventory source can be assigned to multiple inventories.
C.The inventory source must have a defined credential for authentication to the cloud provider.
D.Custom inventory scripts must be placed in the Tower home directory.
E.Inventory sources can update automatically on a schedule.
AnswersA, C, E

Group hierarchies can mix static and dynamic groups.

Why this answer

Option A is correct because Ansible Tower allows dynamic inventory groups to be nested under static groups, enabling a hybrid inventory structure where cloud-sourced hosts can be organized within manually defined static groups for more flexible automation targeting. This is supported by the Tower inventory model, which merges static and dynamic sources into a unified group hierarchy.

Exam trap

The trap here is that candidates may confuse the one-to-many relationship of inventory sources to inventories (Option B) with the actual one-to-one constraint, or assume custom scripts must reside in a specific directory (Option D) when Tower actually supports flexible script paths via projects or absolute paths.

Full explanation →
86
MCQhard

You are maintaining an Ansible automation for a large Red Hat Enterprise Linux deployment. The playbook configures NTP servers on all managed nodes. It uses a variable 'ntp_servers' defined in group_vars/all.yml as a list: ['0.rhel.pool.ntp.org', '1.rhel.pool.ntp.org', '2.rhel.pool.ntp.org']. The playbook task uses the 'uri' module to test connectivity to each server, but only if the server is reachable. The task currently uses: ``` - name: Test NTP server reachability uri: url: "http://{{ item }}:123" timeout: 5 register: result loop: "{{ ntp_servers }}" until: result.status == 200 retries: 3 delay: 2 ``` However, the playbook fails because the NTP servers do not respond to HTTP on port 123. You need to change the approach to test ICMP reachability using the 'ping' module, but the 'ping' module does not support a custom destination port. You also want to continue using a loop and register the success/failure per server. Which of the following is the best course of action?

A.Replace the task with the 'command' module to run 'ping -c 1 {{ item }}' and register results, using 'ignore_errors' to handle unreachable servers.
B.Use the 'slurp' module to read the /etc/hosts file and check if the server is listed.
C.Use the 'wait_for' module with 'host={{ item }}' and 'port=123' to test connectivity, since NTP uses UDP 123.
D.Use the 'ping' module with a loop over the ntp_servers list, setting the 'data' parameter to the server IP.
AnswerA

The command module can run ping to test ICMP reachability; ignore_errors allows the play to continue on failure while registering results.

Why this answer

Option A is correct because the 'ping' module in Ansible does not support custom ports or protocols, and NTP servers do not respond to HTTP on port 123. Using the 'command' module to run 'ping -c 1' allows ICMP reachability testing, and 'ignore_errors' prevents playbook failure when a server is unreachable, while still registering per-server success/failure via the loop.

Exam trap

The trap here is that candidates assume the 'ping' module can perform ICMP reachability tests to external hosts, but in Ansible, 'ping' only tests SSH connectivity to managed nodes, not network-level ICMP pings.

How to eliminate wrong answers

Option B is wrong because the 'slurp' module reads file content (like /etc/hosts) and cannot test live network connectivity; it only checks if a hostname is statically mapped, not if the server is reachable. Option C is wrong because the 'wait_for' module with 'port=123' tests TCP connectivity, but NTP uses UDP port 123, and 'wait_for' does not support UDP; the task would fail or hang. Option D is wrong because the 'ping' module in Ansible is used for SSH connectivity testing to managed nodes, not for ICMP ping to external hosts; setting 'data' does not change this behavior.

Full explanation →
87
MCQmedium

A playbook requires a secret token that changes every hour. The token is stored in a password vault. Which setting should be used to have Tower retrieve the token at runtime?

A.Use a custom credential type that injects the vault lookup result.
B.Hard-code the token in the playbook.
C.Store the token in extra_vars on the job template.
D.Store the token in the project as a file.
AnswerA

Custom credential types can be configured to look up secrets dynamically.

Why this answer

Option A is correct because Ansible Tower (now Red Hat Ansible Automation Platform) supports custom credential types that can define input and injector configurations. By using a custom credential type with an injector that includes a lookup plugin (e.g., `{{ lookup('hashi_vault', 'secret/data/token') }}`), Tower can retrieve the secret token from a password vault (like HashiCorp Vault) at runtime, ensuring the token is always current without hard-coding or manual updates.

Exam trap

The trap here is that candidates may think extra_vars or project files are dynamic enough for runtime secret retrieval, but they fail to recognize that only custom credential types with lookup plugins can fetch secrets from an external vault at job execution time, not at job template definition time.

How to eliminate wrong answers

Option B is wrong because hard-coding the token in the playbook violates security best practices and would require manual updates every hour, making automation impractical. Option C is wrong because storing the token in extra_vars on the job template would require manual updates each hour and does not support dynamic retrieval from a vault; extra_vars are static at job launch time. Option D is wrong because storing the token as a file in the project would require manual file updates and does not integrate with a password vault for dynamic retrieval; project files are static and version-controlled, not suitable for frequently changing secrets.

Full explanation →
88
MCQmedium

Which lookup plugin is used to retrieve values from an AWS SSM Parameter Store?

A.`ssm`
B.`aws_ssm`
C.`amazon_ssm`
D.`ssm_parameter`
AnswerB

Correct; this is the standard lookup plugin for AWS SSM.

Why this answer

The `aws_ssm` lookup plugin is the correct choice because it is the official Ansible lookup plugin designed to retrieve values from the AWS Systems Manager Parameter Store. It is part of the `amazon.aws` collection and is invoked via `lookup('aws_ssm', 'parameter_name')` in playbooks.

Exam trap

Red Hat often tests the exact naming convention of Ansible lookup plugins, where candidates mistakenly assume the plugin name matches the service abbreviation (e.g., 'ssm') rather than the official plugin name (e.g., 'aws_ssm') that includes the provider prefix.

How to eliminate wrong answers

Option A is wrong because `ssm` is not a valid Ansible lookup plugin; it is a generic abbreviation that does not correspond to any official plugin name. Option C is wrong because `amazon_ssm` is not a recognized lookup plugin; the correct prefix for AWS-related plugins in the `amazon.aws` collection is `aws_`, not `amazon_`. Option D is wrong because `ssm_parameter` is not a valid Ansible lookup plugin; it incorrectly appends '_parameter' to the service abbreviation, which does not match the actual plugin naming convention.

Full explanation →
89
MCQhard

A Red Hat Ansible Automation Platform installation uses a custom execution environment. The playbook runs fail with 'execution environment not found'. The execution environment is stored in a private registry requiring authentication. What must be configured?

A.Set the execution_environment_image variable in the playbook
B.Configure the execution environment in the inventory
C.Add the registry URL to the automation controller's container registry credentials
D.Add the registry to the project's source control
AnswerC

Controller needs registry credentials to pull the image.

Why this answer

Option C is correct because when an execution environment is stored in a private registry that requires authentication, the automation controller must have the registry's URL and credentials configured as a container registry credential. This credential is then used by the controller to authenticate and pull the execution environment image during job runs. Without this, the controller cannot access the private registry, resulting in the 'execution environment not found' error.

Exam trap

The trap here is that candidates often confuse setting the image name (Option A) with providing registry authentication, or they mistakenly think inventory or project settings can handle container registry access, when in fact only a dedicated container registry credential in automation controller can authenticate to a private registry.

How to eliminate wrong answers

Option A is wrong because setting the execution_environment_image variable in the playbook only specifies the image name/tag, but does not provide authentication credentials for a private registry. Option B is wrong because configuring the execution environment in the inventory is not a valid method; execution environments are defined at the job template or controller level, not in inventory files. Option D is wrong because adding the registry URL to the project's source control is unrelated to container registry authentication; source control handles playbook code, not container image access.

Full explanation →
90
MCQmedium

An organization uses a private Automation Hub. A user has configured the server in ansible.cfg. Which command installs a collection from this server?

A.ansible-galaxy collection install my_namespace.my_collection --api-key=mykey
B.ansible-galaxy collection install my_namespace.my_collection --server=https://privatehub.example.com
C.ansible-galaxy collection download my_namespace.my_collection
D.ansible-galaxy collection install my_namespace.my_collection
AnswerD

Uses the configured server from ansible.cfg.

Why this answer

Option D is correct because when the Automation Hub server is already configured in ansible.cfg under the [galaxy] section with the server_url and auth_url, the ansible-galaxy collection install command will automatically use that server and its authentication. No additional flags are needed; the command simply specifies the collection name in the format namespace.collection.

Exam trap

The trap here is that candidates may think they need to specify the server URL or API key on the command line, but the EX294 exam expects you to know that the server is pre-configured in ansible.cfg, so only the collection name is required.

How to eliminate wrong answers

Option A is wrong because the --api-key flag is not a valid argument for ansible-galaxy collection install; authentication is handled via the server configuration in ansible.cfg or the GALAXY_TOKEN environment variable, not a command-line API key. Option B is wrong because the --server flag is not a valid option for ansible-galaxy collection install; the server URL is defined in ansible.cfg, not passed as a command-line argument. Option C is wrong because ansible-galaxy collection download is used to download a collection without installing it, not to install it from a configured server.

Full explanation →
91
Multi-Selecthard

An Ansible Tower administrator needs to create a custom credential type that uses an SSH private key and a username. Which THREE components should be defined in the credential type's configuration?

Select 3 answers
A."fields": [{"id": "ssh_key_data", "type": "string", "label": "SSH Private Key", "multiline": true, "secret": true}]
B."fields": [{"id": "password", "type": "string", "label": "Password"}]
C."fields": [{"id": "key_type", "type": "string", "label": "Key Type"}]
D."fields": [{"id": "username", "type": "string", "label": "Username"}]
E."injectors": {"extra_vars": {"ansible_user": "{{ username }}", "ansible_ssh_private_key_file": "{{ ssh_key_data }}"}}
AnswersA, D, E

Input field for SSH private key content.

Why this answer

Option A is correct because the SSH private key must be defined as a field with `"type": "string"`, `"multiline": true` (since SSH keys are multi-line), and `"secret": true` (to encrypt the value in the database). This matches the standard Ansible Tower custom credential type schema for storing sensitive key material.

Exam trap

The trap here is that candidates often add unnecessary fields like 'password' or 'key type' because they confuse SSH key-based authentication with password-based authentication, or they think the key format must be explicitly specified.

Full explanation →
92
MCQmedium

An Ansible playbook fails intermittently when deploying web servers. The error message indicates that a required package is not available in the repository. Which approach would best ensure that the required packages are consistently available before the playbook runs?

A.Set 'ignore_errors: yes' on the package installation task and handle the failure later.
B.Add retries and delay to the package installation task.
C.Add a pre_task to run 'dnf update' or 'apt update' before the package installation.
D.Use the 'get_url' module to download the package from an external source and install it manually.
AnswerC

Updating the repository cache ensures the latest package metadata is available.

Why this answer

Option C is correct because the intermittent failure is caused by the package metadata cache being stale or missing. Running 'dnf update' (RHEL/CentOS) or 'apt update' (Debian/Ubuntu) as a pre_task refreshes the repository index, ensuring that the package manager has the latest list of available packages before attempting installation. This directly resolves the 'package not available' error by synchronizing the local cache with the remote repository.

Exam trap

The trap here is that candidates often choose retries (Option B) thinking it handles transient network issues, but the real problem is a stale metadata cache, which retries cannot fix; the exam tests understanding of package manager internals versus generic error-handling strategies.

How to eliminate wrong answers

Option A is wrong because 'ignore_errors: yes' merely suppresses the failure notification without addressing the root cause; the package will still be missing, and subsequent tasks that depend on it will fail. Option B is wrong because retries and delay only reattempt the same failing operation, which will continue to fail if the repository metadata is stale; they do not update the cache. Option D is wrong because using 'get_url' to download and manually install a package bypasses the repository entirely, which is brittle, insecure, and does not leverage the system's package manager for dependency resolution or updates.

Full explanation →
93
MCQhard

You are managing an Ansible Automation Platform deployment that uses automation mesh with one control node and two execution nodes. The control node is in the DMZ, and the execution nodes are in a private network. The organization's security policy requires that all secrets (e.g., SSH keys, API tokens) be encrypted at rest and never transmitted in plaintext. You have configured vault-encrypted credentials and set the vault password as a credential on the control node. However, a recent audit reveals that when a job runs, the vault password is visible in the job output on the execution nodes. The execution nodes are configured to stream job events back to the control node. The automation controller version is 4.3. The following settings are in place: 'no_log' is not set for any variables; the vault password is stored as a 'Vault password' credential type. The job template uses a custom credential type that injects the vault password as an environment variable. The execution nodes have access to the vault password via that environment variable. The audit shows the environment variable is printed in the job output because the playbook uses the 'env' module to display environment variables for debugging. You must prevent the vault password from appearing in any job output without breaking the ability to decrypt vault-encrypted variables. Which action should you take?

A.Remove the 'env' task from the playbook and ensure no other tasks print environment variables.
B.Configure the automation controller's 'Settings' to enable 'Display secrets' = false.
C.Change the custom credential type to use the built-in 'Vault password' credential type and remove the custom credential type.
D.Edit the custom credential type's input injection to set 'no_log: true' for the environment variable that carries the vault password.
AnswerD

This ensures the vault password is never displayed in job output, while still being available for vault decryption.

Why this answer

Option D is correct because setting `no_log: true` on the environment variable injection in the custom credential type prevents Ansible from logging the value of that variable in job output, while still allowing the vault password to be used by the playbook to decrypt vault-encrypted variables. This directly addresses the audit finding without removing debugging capabilities or changing the credential type.

Exam trap

The trap here is that candidates often think removing the debugging task (Option A) is sufficient, but they miss that the underlying issue is the credential injection method, and that `no_log` is the proper way to prevent secret exposure in Ansible Automation Platform.

How to eliminate wrong answers

Option A is wrong because it only removes the specific `env` task but does not prevent other tasks or modules from inadvertently printing the environment variable, and it does not address the root cause of the vault password being exposed. Option B is wrong because there is no 'Display secrets' setting in automation controller; the relevant setting is `no_log` on credentials or variables, not a global toggle. Option C is wrong because the built-in 'Vault password' credential type does not inject the vault password as an environment variable; it only stores the password for use by the controller to decrypt vault files, and removing the custom credential type would break the ability to inject the vault password into the execution environment.

Full explanation →
94
MCQeasy

An Ansible playbook needs to generate a list of IP addresses from a range 192.168.1.10 to 192.168.1.20. Which filter should be used in a Jinja2 template?

A.{{ '192.168.1.10/28' | ipsubnet }}
B.{{ '192.168.1.10-20' | ipaddr('range_include') }}
C.{{ '192.168.1.10' | ipmath('+10') }}
D.{{ '192.168.1.10' | ipwrap }}
AnswerB

ipaddr with 'range_include' generates a list of IPs in the inclusive range.

Why this answer

Option B is correct because the `ipaddr` filter with the `'range_include'` parameter generates a list of all IP addresses within a specified range, including both endpoints. In this case, `'192.168.1.10-20' | ipaddr('range_include')` produces a list from 192.168.1.10 through 192.168.1.20, which is exactly what the playbook needs to generate.

Exam trap

The trap here is that candidates often confuse `ipaddr('range_include')` with `ipsubnet` or `ipmath`, mistakenly thinking a CIDR or arithmetic operation can produce a list of IPs, when only the `range_include` parameter of `ipaddr` is designed for that purpose.

How to eliminate wrong answers

Option A is wrong because `ipsubnet` filter calculates subnet information (like network address, broadcast address, or netmask) from a CIDR notation, not a list of individual IPs; `'192.168.1.10/28' | ipsubnet` would return subnet details, not a range of addresses. Option C is wrong because `ipmath` filter performs arithmetic on an IP address (e.g., adding 10 to the last octet) and returns a single IP address, not a list; `'192.168.1.10' | ipmath('+10')` yields 192.168.1.20 only. Option D is wrong because `ipwrap` filter wraps an IP address in square brackets (e.g., for IPv6 or URI use) and does not generate any list of addresses.

Full explanation →
95
Multi-Selectmedium

Which THREE features are provided by Ansible's filter plugins? (Select exactly three.)

Select 3 answers
A.Defining new Ansible modules
B.Data transformation (e.g., format dates, modify strings)
C.Accepting arguments to customize behavior
D.Chaining multiple filters in a pipeline
E.Fetching data from external APIs
AnswersB, C, D

Core purpose of filters.

Why this answer

Filter plugins in Ansible are used to transform data within Jinja2 templates. Option B is correct because filters like `| date`, `| regex_replace`, and `| upper` directly perform data transformation tasks such as formatting dates and modifying strings, which is a core purpose of filter plugins.

Exam trap

The trap here is that candidates confuse filter plugins with lookup plugins or modules, mistakenly thinking filters can fetch external data or define new modules, when in fact filters are strictly for in-memory data transformation within Jinja2 expressions.

Full explanation →
96
MCQhard

An administrator is migrating playbooks to use execution environments in automation controller. They want to ensure that all playbook runs use a custom execution environment that includes the necessary Python libraries and is signed to comply with security policy. What should the administrator do?

A.Build the execution environment using ansible-builder and then push it to a private registry and reference it in the automation controller.
B.Push the custom execution environment to the default namespace and assign it to job templates.
C.Use the default execution environment and install Python libraries via the playbook.
D.Define the execution environment in the project repository and use a pre-run hook.
AnswerA

Ansible-builder creates a standard image; private registry ensures security and signing.

Why this answer

Option A is correct because the administrator must build a custom execution environment using `ansible-builder`, which packages the required Python libraries and Ansible content into a container image. This image must then be pushed to a private registry (e.g., Quay.io or Red Hat Registry) and referenced in automation controller's execution environment configuration. Additionally, signing the image (e.g., via Podman or Skopeo) ensures compliance with security policies by verifying image integrity before execution.

Exam trap

The trap here is that candidates may think they can install Python libraries dynamically via a playbook (Option C) or use a project-level definition (Option D), but the exam tests the understanding that execution environments are immutable container images built externally and referenced by registry path.

How to eliminate wrong answers

Option B is wrong because pushing the custom execution environment to the 'default namespace' is not a valid concept in automation controller; execution environments are referenced by their full registry path and tag, not by namespace assignment. Option C is wrong because using the default execution environment and installing Python libraries via a playbook violates the purpose of execution environments, which are meant to provide immutable, pre-packaged dependencies; runtime installation also breaks security policy and reproducibility. Option D is wrong because defining the execution environment in the project repository is not supported; execution environments are configured at the job template or global level in automation controller, and 'pre-run hooks' are not a mechanism for specifying execution environments.

Full explanation →
97
MCQhard

Refer to the exhibit. When running the playbook with the limit set to 'webservers', why does the playbook fail on web2?

A.The 'webservers' group includes web2 due to a misconfiguration.
B.The SSH key for web2 is not authorized.
C.The inventory file has a syntax error causing web2 to be included in webservers.
D.The playbook's 'hosts' directive is set to 'all' instead of 'webservers'.
AnswerA

The inventory JSON shows web2 is not in webservers, but the playbook still tries to run on web2, suggesting the limit is not working correctly or the inventory is misconfigured.

Why this answer

The inventory shows web2 is in the 'all' group but not in the 'webservers' group. The limit 'webservers' should only target web1, but the playbook still attempts to connect to web2. This indicates an error in the inventory or playbook configuration.

Full explanation →
98
MCQhard

Refer to the exhibit. An administrator deployed this configuration using the controller_configuration role. After deployment, user jdoe can administer Engineering organization but cannot launch a job template within it. What is the most likely reason?

A.The admin role for organization does not include job template launch permissions
B.The user's password is vault-encrypted and cannot be decrypted
C.The user needs to be added to the job template's role specifically
D.The role assignment should be at the team level, not user level
AnswerC

Execute role on job template is required.

Why this answer

Option C is correct because in Ansible Tower/AWX, organization-level admin roles grant administrative privileges over the organization's objects (e.g., users, teams, inventories) but do not automatically confer execute permissions on specific job templates. To launch a job template, a user must have the 'execute' role on that job template itself, either directly or via a team or user role assignment. Since user jdoe can administer the Engineering organization but cannot launch a job template, the missing piece is the explicit job template role assignment.

Exam trap

Red Hat often tests the misconception that an organization admin role automatically includes all permissions on objects within the organization, when in fact job template execution requires a separate explicit role assignment.

How to eliminate wrong answers

Option A is wrong because the admin role for an organization does include the ability to manage job templates (create, modify, delete) but does not include the 'execute' permission; the question is about launching (executing) a job template, not managing it. Option B is wrong because vault-encrypted passwords are decrypted at runtime by Ansible Tower using the vault password; if the password could not be decrypted, the user would not be able to log in at all, not just fail to launch a job template. Option D is wrong because role assignments can be made at the user level as well as the team level; the issue is not the level of assignment but the specific role (execute) that is missing.

Full explanation →
99
MCQhard

During a playbook execution, a task that uses the 'ansible.builtin.copy' module fails with 'Permission denied' on a remote host. The playbook runs as user 'ansible' which is a sudoer without password. Which of the following is the most likely cause and solution?

A.The remote path does not exist. Use 'remote_src: yes' to copy from remote.
B.The local source file is not readable by the user running ansible-playbook. Change permissions on the source file.
C.The task lacks 'become: yes' but has 'become_user: root'. Add 'become: yes' to the task.
D.The remote file is owned by root and the destination directory is not writable by ansible. Use 'become: yes' and set 'owner: ansible'.
AnswerC

Without 'become: yes', become_user is ignored; adding 'become: yes' enables privilege escalation.

Why this answer

The 'Permission denied' error occurs because the task attempts to copy a file to a location that requires root privileges, but the playbook does not use privilege escalation. The user 'ansible' is a passwordless sudoer, so adding 'become: yes' to the task enables sudo, granting the necessary permissions to write to the destination. Option C correctly identifies this missing directive.

Exam trap

The trap here is that candidates assume 'become_user: root' alone is sufficient for privilege escalation, but Ansible requires the explicit 'become: yes' flag to activate any become method, including sudo.

How to eliminate wrong answers

Option A is wrong because 'remote_src: yes' copies a file from the remote host itself, not from the control node, and does not address permission issues; the error is about permissions, not a missing remote path. Option B is wrong because the error occurs on the remote host, not the control node; the local source file's permissions are irrelevant to a remote 'Permission denied' error. Option D is wrong because while 'become: yes' is needed, setting 'owner: ansible' is unnecessary and incorrect—the task should not change ownership to the unprivileged user; the solution is simply to escalate privileges to write the file, not to change the file's owner.

Full explanation →
100
Matchingmedium

Match each Linux command to its function.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts
Matches

Socket statistics

Query systemd journal

Show current SELinux mode

Manage firewalld rules

Extend a logical volume

Why these pairings

Essential commands for system administration in RHEL.

Full explanation →
101
MCQeasy

A systems administrator needs to run a playbook that applies configuration changes to a set of servers. They want to ensure that if any task fails on a host, the playbook continues with the next host without aborting the entire play. Which play-level keyword should they use?

A.Set `gather_facts: no` to skip fact gathering and reduce failure points.
B.Set `any_errors_fatal: true` at the play level.
C.Set `force_handlers: true` at the play level.
D.`ignore_errors: yes` on each task that might fail.
AnswerD

Setting `ignore_errors: yes` on a task allows the play to continue to the next host even if that task fails on a given host.

Why this answer

Option D is correct because `ignore_errors: yes` on each task ensures that if a task fails on a host, the playbook continues executing subsequent tasks on that host and moves on to the next host without aborting the entire play. This directly meets the requirement to continue with the next host upon task failure.

Exam trap

The trap here is that candidates often confuse `ignore_errors` with `any_errors_fatal` or `force_handlers`, mistakenly thinking that setting a play-level keyword can achieve per-task failure tolerance without modifying individual tasks.

How to eliminate wrong answers

Option A is wrong because `gather_facts: no` only skips the fact-gathering step, which reduces network overhead but does nothing to control playbook behavior when a task fails. Option B is wrong because `any_errors_fatal: true` causes the entire play to abort immediately on any task failure, which is the opposite of what is needed. Option C is wrong because `force_handlers: true` ensures handlers run even when the play fails, but it does not prevent the play from aborting or continue execution to the next host after a task failure.

Full explanation →
102
Multi-Selectmedium

Which THREE commands can verify the status of a rolling update on an OpenShift deployment?

Select 3 answers
A.oc describe deployment/<name>
B.oc logs deployment/<name>
C.oc get events
D.oc get pods -l <selector>
E.oc rollout status deployment/<name>
AnswersA, C, E

Shows conditions like Progressing and Available.

Why this answer

Option A is correct because `oc describe deployment/<name>` provides detailed information about the deployment, including the current rollout status, revision history, and conditions such as Progressing or Available. This allows you to verify whether a rolling update is in progress, has completed, or has stalled by examining fields like `Replicas`, `UpdatedReplicas`, and `Conditions`.

Exam trap

The trap here is that candidates often confuse `oc logs` with `oc rollout status` or assume that listing pods alone is sufficient to determine rollout health, but only `oc rollout status` and `oc describe deployment` provide the authoritative rollout state, while `oc get events` reveals cluster-level events that may indicate rollout issues.

Full explanation →
103
MCQmedium

A system administrator maintains a dynamic inventory script that queries a cloud provider API to build host lists. The script returns valid JSON, but after importing into Ansible Tower, the inventory shows zero hosts. The script is executable and placed in the expected project directory. What is the most likely cause?

A.The script does not output JSON in the correct format expected by Ansible Tower.
B.The script does not have the executable permission set.
C.The script has not been added as an inventory script in Ansible Tower's inventory scripts settings.
D.The script is written in a language that Ansible Tower does not support.
AnswerC

Dynamic inventory scripts must be registered in Tower.

Why this answer

Option C is correct because Ansible Tower requires that a dynamic inventory script be explicitly registered as an inventory script in the Tower UI under 'Inventories' → 'Scripts'. Even if the script is executable and returns valid JSON, Tower will not execute it unless it is configured as a custom inventory script source. The script must be added via the 'Add' button in the Inventory Scripts section, where Tower will then use it to populate the inventory.

Exam trap

The trap here is that candidates assume making a script executable and placing it in the project directory is sufficient, but Ansible Tower requires explicit registration of the script as an inventory source, unlike standalone Ansible which can use the script directly via the '-i' flag.

How to eliminate wrong answers

Option A is wrong because the question states the script returns valid JSON, and Ansible Tower accepts any valid JSON that follows the expected host/group structure (e.g., a dictionary with 'group_name' keys and 'hosts' lists). Option B is wrong because the question explicitly states the script is executable, so permission is not the issue. Option D is wrong because Ansible Tower supports any scripting language that can be executed via a shebang line (e.g., Python, Bash, Ruby) as long as the script is executable and outputs JSON to stdout.

Full explanation →
104
MCQhard

An organization uses Ansible Tower to manage automation across different teams. One team has a job template that uses a custom Python virtual environment located at '/opt/custom_venv' to run a playbook that uses the 'docker_container' module from the 'community.docker' collection. The playbook runs successfully from the command line when using the '--ask-become-pass' option and the virtual environment activated. However, when the team runs the same playbook via the Ansible Tower job template, it fails with an error indicating that the 'docker_container' module is not found. The job template is configured to use the custom virtual environment under the 'CUSTOM VIRTUAL ENVIRONMENT' setting. The team confirms that the virtual environment has the collection installed (verified by running 'ansible-galaxy collection list' inside the venv). What is the most likely cause of the failure?

A.The playbook should use the 'ansible_connection: local' directive to force local execution.
B.The Ansible Tower node executing the job does not have the custom virtual environment installed.
C.The 'community.docker' collection was installed in the default system-wide location instead of the custom virtual environment.
D.The job template's 'CUSTOM VIRTUAL ENVIRONMENT' setting points to a different path than '/opt/custom_venv'.
AnswerB

The virtual environment must be present on the execution node.

Why this answer

Ansible Tower runs jobs on the node where the job template is executed. The custom virtual environment must be present on that node and contain the required collections. Option D is correct because Tower's job runner uses the configured virtual environment, but if the node running the job is not the same as the control node, the venv may not exist or may be incomplete.

Option A is incorrect because the venv does have the collection. Option B is incorrect because Tower can use custom venvs. Option C would not fix a missing collection.

Full explanation →
105
MCQhard

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?

A.Establish a direct VPN link between DC1 and DC3 to reduce latency.
B.Change the `node_type` of DC3 execution nodes to `control` to make them preferred.
C.Create host labels to tag nodes by data center and assign job templates accordingly.
D.Configure `node_policy` to set `topology=dc3` on execution nodes in DC3 so the controller can route jobs based on proximity.
AnswerD

Node policy helps controller select nodes based on network topology.

Why this answer

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.

Exam trap

The trap here is that candidates confuse network-level solutions (VPN) or static labeling (host labels) with the dynamic, controller-driven routing provided by `node_policy`, which is the intended mechanism for geographic job placement in automation mesh.

How to eliminate wrong answers

Option A is wrong because establishing a direct VPN link addresses network connectivity but does not influence the controller's job routing logic; jobs would still be scheduled on any healthy node regardless of proximity. Option B is wrong because changing `node_type` to `control` would make DC3 nodes control nodes, which are not designed for job execution and would break the mesh topology, not improve job placement. Option C is wrong because host labels and job template assignments are static and require manual intervention; they do not dynamically route jobs based on geographic proximity or mesh topology.

Full explanation →
106
MCQeasy

A system administrator wants to run a playbook on all hosts in the 'webservers' group, but only if the host is currently online. Which approach should be used?

A.Set 'gather_facts: no' to skip fact collection.
B.Use 'throttle: 1' to limit concurrent connections.
C.Set 'serial: 1' to run on one host at a time.
D.Use 'wait_for_connection' as a pre-task to ensure connectivity.
AnswerD

wait_for_connection waits for the host to become reachable.

Why this answer

Option D is correct because the `wait_for_connection` module is specifically designed to pause the playbook execution until a remote host becomes reachable over SSH or WinRM. By placing it as a pre-task, the playbook will only proceed to subsequent tasks for hosts that are currently online, effectively filtering out offline hosts. This directly meets the requirement to run the playbook only on hosts in the 'webservers' group that are online.

Exam trap

The trap here is that candidates confuse connectivity testing with execution control keywords like `serial` or `throttle`, mistakenly believing those options can prevent a playbook from running on offline hosts, when in fact they only manage concurrency or order of execution without verifying reachability.

How to eliminate wrong answers

Option A is wrong because setting 'gather_facts: no' only skips the collection of system facts from remote hosts; it does not test connectivity or determine if a host is online. Option B is wrong because 'throttle: 1' limits the number of concurrent tasks or connections to one at a time, but it does not verify whether a host is reachable before running tasks. Option C is wrong because 'serial: 1' forces the playbook to execute on one host at a time, but it still attempts to connect to each host regardless of its online status, potentially causing failures or timeouts.

Full explanation →
107
Multi-Selecteasy

Which two statements are true regarding Ansible roles? (Choose two.)

Select 2 answers
A.Role handlers are shared across all roles in the play.
B.A role can have a meta/main.yml file to define dependencies.
C.Role variables in vars/main.yml can be overridden by playbook vars.
D.Role default variables in defaults/main.yml have the lowest priority.
E.Roles can only be used in a playbook's roles section.
AnswersB, D

Role dependencies are defined in meta/main.yml.

Why this answer

Options A and B are correct. Option C is false because role vars (vars/main.yml) have higher priority than playbook vars. Option D is false because roles can be used via include_role or import_role in tasks.

Option E is false because handlers are scoped per role and not shared.

Full explanation →
108
MCQmedium

An Ansible role is designed to work on both RHEL 7 and RHEL 8 systems. The role uses the 'redhat_subscription' module. However, on RHEL 8, the module requires a different parameter name. The developer wants to use a conditional parameter based on the OS version. Which filter allows checking the operating system version from 'ansible_facts'?

A.int
B.version
C.sys.version
D.bool
AnswerB

The 'version' filter allows comparing version strings like '8.0'.

Why this answer

The correct answer is B, 'version', because the `version` filter in Ansible is specifically designed to compare version strings from `ansible_facts` (e.g., `ansible_facts['ansible_distribution_version']`). It allows conditional logic based on OS version, such as checking if the version is '8.0' or higher, which is exactly what the developer needs to handle the different parameter names for the `redhat_subscription` module between RHEL 7 and RHEL 8.

Exam trap

The trap here is that candidates confuse the `version` filter with Python's `sys.version` or generic type conversion filters like `int` or `bool`, failing to recognize that Ansible provides a dedicated filter for semantic version comparison.

How to eliminate wrong answers

Option A is wrong because the `int` filter converts a value to an integer, which is not suitable for comparing version strings like '7.9' or '8.4' as it would truncate or fail on non-integer parts. Option C is wrong because `sys.version` is a Python attribute (from the `sys` module) that returns the Python interpreter version, not the operating system version from Ansible facts. Option D is wrong because the `bool` filter converts a value to a boolean (true/false), which cannot be used to compare or evaluate version numbers.

Full explanation →
109
Multi-Selecteasy

Which TWO filters are commonly used to transform strings in Ansible? (Select exactly two.)

Select 2 answers
A.regex_replace
B.items2dict
C.flatten
D.trim
E.dict2items
AnswersA, D

regex_replace substitutes regex patterns.

Why this answer

Option A is correct because `regex_replace` is a built-in Jinja2 filter in Ansible that allows you to transform strings by replacing substrings that match a regular expression pattern. This is commonly used for string manipulation tasks such as sanitizing user input or formatting output.

Exam trap

The trap here is that candidates may confuse filters that manipulate data structures (like `items2dict`, `flatten`, `dict2items`) with filters that transform strings, leading them to select options that are valid Ansible filters but not applicable to string transformation.

Full explanation →
110
MCQeasy

An Ansible playbook uses the 'deployment' resource with a 'rolling_update' strategy. Which module is typically used to manage this in a Kubernetes/OpenShift environment?

A.ansible.builtin.copy
B.ansible.builtin.command
C.kubernetes.core.k8s
D.ansible.builtin.shell
E.ansible.builtin.service
AnswerC

The k8s module manages Kubernetes resources including deployments with rollout strategies.

Why this answer

The `kubernetes.core.k8s` module is the correct choice because it directly manages Kubernetes/OpenShift resources, including Deployments, and supports rolling update strategies natively. It interacts with the Kubernetes API to apply declarative configurations, handling the rolling update logic (e.g., `maxSurge`, `maxUnavailable`) without requiring manual orchestration via shell commands or file copies.

Exam trap

The trap here is that candidates may confuse managing system services (via `service`) or executing kubectl commands (via `command`/`shell`) with the proper Ansible module designed for Kubernetes resource orchestration, leading them to pick a generic module instead of the domain-specific `kubernetes.core.k8s`.

How to eliminate wrong answers

Option A is wrong because `ansible.builtin.copy` is used to copy files to the managed node's filesystem, not to interact with Kubernetes API resources. Option B is wrong because `ansible.builtin.command` executes arbitrary commands on the target host but lacks idempotency and native Kubernetes resource management, making it unsuitable for rolling updates. Option D is wrong because `ansible.builtin.shell` is similar to `command` but runs through a shell, introducing parsing risks and still not managing Kubernetes objects.

Option E is wrong because `ansible.builtin.service` manages system services (e.g., systemd) on the managed node, not container orchestration resources like Deployments.

Full explanation →
111
MCQhard

You are managing a rolling update of a 10-node web application cluster using Ansible. The application requires that at least 8 nodes remain available during the update to handle traffic. You have written a playbook that uses serial: 2 (updates 2 nodes at a time). During a test run, the playbook updates the first batch of 2 nodes successfully, but when it proceeds to the second batch, one of the nodes fails to restart the web service. However, the playbook continues and updates the remaining nodes. At the end, only 7 nodes are healthy, causing performance degradation. You need to ensure that if a batch fails to meet the minimum health requirements, the entire rollout is stopped and no further updates are applied. Which course of action should you take?

A.Add a retry loop to the service restart task with a delay and count of 5.
B.Set ignore_errors: yes on the service restart task to avoid failures stopping the playbook.
C.Use the 'throttle' keyword with a rolling update strategy that includes a post-task health check and set max_fail_percentage to a value that aborts if the healthy node count drops below 8.
D.Increase serial to 3 to complete the update faster and reduce the chance of node failures.
AnswerC

throttle and max_fail_percentage combined can enforce health thresholds and abort the rollout when conditions are not met.

Why this answer

Option C is correct because it uses the `throttle` keyword with a rolling update strategy that includes a post-task health check and sets `max_fail_percentage` to abort the playbook if the healthy node count drops below 8. This ensures that if a batch fails to meet the minimum health requirements, the entire rollout is stopped and no further updates are applied, preventing performance degradation.

Exam trap

The trap here is that candidates often confuse retry mechanisms or error handling with the need for a batch-level health check and abort logic, assuming that retrying a failed task or ignoring errors will somehow prevent the overall rollout from continuing when health thresholds are breached.

How to eliminate wrong answers

Option A is wrong because a retry loop on the service restart task only retries the failed task on the same node; it does not stop the overall rollout or check the cluster-wide health status after each batch. Option B is wrong because `ignore_errors: yes` would cause the playbook to continue despite the failure, which is the opposite of stopping the rollout when health requirements are not met. Option D is wrong because increasing `serial` to 3 would update more nodes per batch, potentially causing even more nodes to be unhealthy at once and increasing the risk of dropping below the minimum of 8 healthy nodes.

Full explanation →
112
Multi-Selecthard

Which TWO statements about Ansible role defaults are true?

Select 2 answers
A.Defaults are only loaded if no vars are defined.
B.Defaults are loaded from the defaults/main.yml file.
C.Defaults have higher priority than variables defined in the playbook.
D.Defaults cannot be overridden.
E.Defaults have the lowest priority of all variables.
AnswersB, E

Defaults are defined in defaults/main.yml.

Why this answer

Role defaults have the lowest variable precedence, making them easy to override. They are defined in the defaults/main.yml file within the role.

Full explanation →
113
MCQmedium

An organization uses a private automation hub to distribute collections. A developer has created a new collection and needs to ensure it is available in the hub for others. Which command should the developer use to upload the collection to the private automation hub?

A.ansible-galaxy collection import
B.ansible-galaxy collection build
C.ansible-galaxy collection publish
D.ansible-galaxy collection install
AnswerC

Correct. This command uploads the collection tarball to the configured Galaxy server.

Why this answer

Option C is correct because `ansible-galaxy collection publish` is the command specifically designed to upload a built collection artifact (a .tar.gz file) to a Galaxy server, including a private automation hub. This command sends the collection to the configured Galaxy server endpoint, making it available for others to install via `ansible-galaxy collection install`.

Exam trap

The trap here is that candidates confuse `build` (which only creates the artifact) with `publish` (which uploads it), or they mistakenly think `import` is the correct command for uploading a built artifact, when in fact `import` is for source-based imports from a repository.

How to eliminate wrong answers

Option A is wrong because `ansible-galaxy collection import` is used to import a collection from a Git repository or a source distribution into a Galaxy server, but it is not the command for uploading a pre-built collection artifact; it expects a source repository URL or a path to a source directory, not a built .tar.gz file. Option B is wrong because `ansible-galaxy collection build` creates the collection artifact (a .tar.gz file) from the collection source files, but it does not upload or publish it to any server; it only produces the local artifact. Option D is wrong because `ansible-galaxy collection install` downloads and installs a collection from a Galaxy server or a local path, but it does not upload or publish collections to a hub.

Full explanation →
114
MCQmedium

An organization uses Ansible Automation Controller. They have an inventory source that syncs from a Git repository containing `inventory/hosts.yml`. The job template uses this inventory. Recently, the inventory stopped updating. The admin checks the job logs and sees: `ERROR! Could not update inventory source: invalid inventory source definition`. What is the most likely issue?

A.The Git repository is unreachable due to network issues.
B.The project that contains the playbook has been deleted.
C.The machine credential stored in the controller has expired.
D.The inventory file `hosts.yml` has a syntax error, such as a missing colon.
AnswerD

Invalid inventory definition due to YAML error.

Why this answer

The error message 'invalid inventory source definition' indicates that the inventory file itself is malformed, not that there is a connectivity or credential issue. In Ansible Automation Controller, when an inventory source syncs from a Git repository, the controller parses the inventory file (e.g., `hosts.yml`) according to YAML syntax rules. A missing colon would break the YAML structure, causing the controller to reject the file as invalid, which matches the error.

Exam trap

The trap here is that candidates often confuse 'invalid inventory source definition' with connectivity or credential issues, but the error specifically points to a malformed inventory file, not a network or authentication problem.

How to eliminate wrong answers

Option A is wrong because a network issue would produce an error like 'Could not resolve host' or 'Connection refused', not 'invalid inventory source definition'. Option B is wrong because deleting the project would cause a 'Project not found' error when the job template tries to reference it, not an inventory source parsing error. Option C is wrong because an expired machine credential would result in an authentication failure (e.g., 'Permission denied' or 'Authentication failed') during the sync process, not a definition error.

Full explanation →
115
MCQhard

What is the effect of the `filter_plugins` setting in `ansible.cfg`?

A.It sets the directory for filter plugins but only for the current playbook.
B.It configures the path for lookup plugins, not filter plugins.
C.It replaces the default search path for filter plugins with the specified directory.
D.It adds the directory to the default search path for filter plugins.
AnswerC

Correct; Ansible will only search in the custom path.

Why this answer

In Ansible, the `filter_plugins` setting in `ansible.cfg` specifies a directory that replaces the default search path for filter plugins. This means Ansible will look only in the specified directory for filter plugins, ignoring the default locations such as `~/.ansible/plugins/filter` or the `filter_plugins` directory relative to the playbook. This is a configuration override, not an addition.

Exam trap

The trap here is that candidates often confuse 'replaces' with 'adds to' (option D), not realizing that Ansible's `filter_plugins` setting is an override, not an append, which is a common pattern in Ansible configuration settings.

How to eliminate wrong answers

Option A is wrong because `filter_plugins` is not limited to the current playbook; it applies globally to all playbooks run with that configuration file. Option B is wrong because `filter_plugins` specifically configures the path for filter plugins, not lookup plugins (which are configured by `lookup_plugins`). Option D is wrong because the setting replaces the default search path, not adds to it; to add a directory, you would need to use a colon-separated list or rely on the default search order.

Full explanation →
116
MCQhard

An Ansible playbook fails intermittently due to a service not starting in time. The administrator wants to configure a task to retry until the service confirms it is running. Which Ansible feature should be used?

A.Until loop with retries and delay.
B.Failed_when with conditional retry.
C.Block and rescue to catch failure.
D.Async with poll interval.
AnswerA

The 'until' loop retries a task until a condition is met, with configurable retries and delay.

Why this answer

Option D (until loop with retries and delay) is correct. Option A (failed_when) only sets failure conditions, not retries. Option B (block/rescue) handles errors but doesn't retry.

Option C (async) starts a task and polls later but doesn't inherently retry on failure.

Full explanation →
117
MCQeasy

A playbook needs to load encrypted variables from a file vault.yml. The vault password is stored in a file vault-pass with restricted permissions. Which method securely loads the variables when running the playbook?

A.Use include_vars: file: vault.yml without any additional configuration.
B.Run ansible-playbook with --ask-vault-pass to prompt for the password.
C.Run ansible-playbook playbook.yml --vault-password-file vault-pass
D.Set the environment variable ANSIBLE_VAULT_PASSWORD_FILE in the user's profile.
AnswerC

Correct: Provides the vault password from a file with restricted permissions.

Why this answer

Option C is correct because running ansible-playbook with --vault-password-file specifies the file containing the vault password, which is a best practice. Option A would fail because the encrypted file cannot be read without the vault password. Option B prompts for the password, which is less secure in automation.

Option D sets an environment variable, which could be insecure if the session is shared.

Full explanation →
118
MCQmedium

A developer creates a collection and wants to ensure it includes a required Python library for a module. Where should this dependency be declared?

A.In a requirements.txt file at the collection root.
B.In the galaxy.yml file under dependencies.
C.In the meta/runtime.yml file.
D.In the collection's README.
AnswerB

galaxy.yml supports a 'dependencies' key listing Python packages and other collections.

Why this answer

In Ansible collections, Python library dependencies for modules are declared in the `galaxy.yml` file under the `dependencies` key. This ensures that when the collection is installed via `ansible-galaxy collection install`, the required Python packages are automatically resolved and installed. The `dependencies` field in `galaxy.yml` specifically supports listing Python package requirements using the format `python: package_name`.

Exam trap

Red Hat often tests the distinction between `galaxy.yml` (for collection metadata and dependencies) and `requirements.txt` (a generic Python file not automatically consumed by Ansible collection installation), leading candidates to mistakenly choose `requirements.txt`.

How to eliminate wrong answers

Option A is wrong because `requirements.txt` is a standard Python file for pip, but Ansible collections do not automatically read it for dependency resolution during collection installation; the collection's dependencies are declared in `galaxy.yml`. Option C is wrong because `meta/runtime.yml` is used to define Ansible runtime behavior such as action groups, module defaults, and redirects, not Python library dependencies. Option D is wrong because the README is documentation-only and has no effect on dependency installation or resolution.

Full explanation →
119
MCQmedium

You are managing a fleet of 200 RHEL 8 servers with Ansible Tower. A playbook uses the 'seboolean' module to enable httpd_can_network_connect for a web application. Recently, the playbook has been failing on 10 servers with the error: 'Failed to set SELinux boolean: Unable to communicate with SELinux policy'. Other servers succeed. The playbook runs as the 'ansible' user with passwordless sudo. The failing servers have identical SELinux configuration (enforcing mode, targeted policy) and the same package versions as working servers. You suspect the issue is related to the 'python3-libselinux' package. Which of the following is the most likely cause and the correct fix?

A.The 'python3-libselinux' package is missing on the failing servers. Install it with 'dnf install python3-libselinux'.
B.The 'python2-libselinux' package is required because Ansible uses Python 2. Install it with 'dnf install python2-libselinux'.
C.The 'ansible' user lacks sudo access to the 'seboolean' command. Add a sudoers entry to allow it.
D.The 'libsemanage' package is missing. Install it with 'dnf install libsemanage'.
AnswerA

Correct: The module requires the Python binding for libselinux.

Why this answer

The error 'Failed to set SELinux boolean: Unable to communicate with SELinux policy' indicates that the Python bindings required to interact with the SELinux policy are missing. The 'seboolean' module in Ansible relies on the 'python3-libselinux' package to communicate with the SELinux subsystem. Since the playbook runs as the 'ansible' user with passwordless sudo, and the failing servers have identical SELinux configuration and package versions except for this missing dependency, installing 'python3-libselinux' resolves the issue.

Exam trap

The trap here is that candidates may confuse the missing Python binding with a missing system library or a permission issue, but the specific error message points directly to the Python-SELinux communication layer, which is provided by 'python3-libselinux'.

How to eliminate wrong answers

Option B is wrong because Ansible on RHEL 8 uses Python 3 by default, not Python 2, so 'python2-libselinux' is irrelevant and would not fix the issue. Option C is wrong because the error is about communicating with SELinux policy, not about sudo permissions; the 'ansible' user already has passwordless sudo, and the 'seboolean' module does not require a separate sudoers entry for the command. Option D is wrong because 'libsemanage' is a low-level library for SELinux policy management, but the specific Python binding 'python3-libselinux' is what Ansible's 'seboolean' module requires to function; installing 'libsemanage' alone does not provide the necessary Python interface.

Full explanation →
120
MCQhard

A company uses Ansible Vault to encrypt sensitive data in playbooks. They have multiple environments (dev, test, prod) and use a separate vault password file for each environment. The passwords are stored in files named 'vault-pass-dev', 'vault-pass-test', and 'vault-pass-prod'. To run a playbook against the test environment, they use the command 'ansible-playbook site.yml -i test -e @test-vars.yml --vault-id test@vault-pass-test'. This runs successfully from the command line. However, when they define the same vault-id in an Ansible Tower credential and attempt to run the job, the job fails with 'ERROR! Decryption failed (no vault secrets would be found that could decrypt the vault encrypted file)' for a vault-encrypted variable file that was encrypted with a different vault ID (e.g., 'dev'). The team expects that Tower would use the provided vault credential to decrypt all vault-encrypted files. Which change should be made to ensure correct decryption in Tower?

A.Add multiple vault credentials to the job template, one for each vault ID used in the project.
B.Enter all vault passwords separated by commas in the 'VAULT PASSWORD' field of a single credential.
C.Re-encrypt all files with the same vault ID (e.g., 'default') to simplify the setup.
D.Change the vault password file to contain the password for the vault ID that was used to encrypt the file.
AnswerA

Tower can use multiple vault credentials to decrypt files with different vault IDs.

Why this answer

Ansible Vault with multiple vault IDs allows different passwords for different files. The Tower credential only provides one vault password per vault ID. To decrypt files encrypted with multiple vault IDs, multiple vault credentials or a single credential with multiple vault IDs must be configured.

Option A correctly suggests using a single vault password file that contains the correct password for the file being decrypted, but the issue is that the file was encrypted with a different vault ID. Option B is the standard way in Tower: associate multiple vault credentials with the job template, each corresponding to a different vault ID. Option C is incorrect because Tower does not accept multiple passwords via one field.

Option D would only work if the file was encrypted with the default ID.

Full explanation →
121
MCQmedium

Your organization uses Red Hat Ansible Automation Platform (AAP) to manage job execution. You have created a job template that runs a playbook to configure application servers. The playbook uses a custom credential to access a remote database. Recently, the job started failing with 'Authentication failed' when connecting to the database. You have verified that the database credentials are correct. The credential in AAP is of type 'Machine' and is assigned to the job template. The playbook uses the 'mysql_db' module. Which step should you take to troubleshoot and resolve the issue?

A.Change the credential type to 'Database' and provide the appropriate username and password.
B.Add the database password as an extra variable in the job template.
C.Modify the machine credential to include the database password as an SSH key.
D.Encrypt the database password using Ansible Vault and include it in the playbook.
AnswerA

Correct: The mysql_db module needs a database credential type to authenticate.

Why this answer

Option B is correct because the 'mysql_db' module typically requires a database credential type, not a machine credential. The credential type must match the module's needs. Option A is incorrect because extra variables would override inventory but not fix the credential type.

Option C is incorrect because the vault provides a different mechanism; the credential type is the core issue. Option D is incorrect because the issue is not about SSH keys.

Full explanation →
122
MCQhard

The build fails with a DNS resolution error for `registry.redhat.io`. Which troubleshooting step is most likely to resolve the issue?

A.Run `podman login registry.redhat.io` to authenticate.
B.Restart the container runtime service.
C.Verify DNS settings in `/etc/resolv.conf` or configure a custom DNS server for the container runtime.
D.Use the `--no-cache` flag to force a fresh build.
AnswerC

Corrects the underlying DNS issue.

Why this answer

A DNS resolution error for `registry.redhat.io` indicates that the container runtime (e.g., Podman) cannot resolve the registry's hostname to an IP address. This is a network/DNS issue, not an authentication or caching problem. Verifying or correcting DNS settings in `/etc/resolv.conf` or configuring a custom DNS server for the container runtime directly addresses the root cause by ensuring the host or container runtime can resolve the registry's FQDN.

Exam trap

The trap here is that candidates confuse DNS resolution errors with authentication or cache issues, leading them to choose `podman login` or `--no-cache` instead of recognizing that DNS must work before any network communication can occur.

How to eliminate wrong answers

Option A is wrong because `podman login` authenticates to the registry, but DNS resolution occurs before authentication; if the hostname cannot be resolved, authentication is irrelevant. Option B is wrong because restarting the container runtime service does not fix underlying DNS configuration issues; it only restarts the daemon without changing network or resolver settings. Option D is wrong because `--no-cache` forces a fresh build by ignoring cached layers, but it does not affect DNS resolution; the build will still fail if the registry hostname cannot be resolved.

Full explanation →
123
MCQeasy

An Ansible playbook uses the `ansible_password` variable to connect to a Windows host. The value is stored in an encrypted Ansible Vault file. Which credential type in Automation Controller would allow the vault password to be supplied at runtime?

A.Cloud credential
B.Machine credential
C.Vault credential
D.Network credential
AnswerC

Vault credentials provide the vault password to decrypt vault-encrypted files.

Why this answer

Option C is correct because Automation Controller's Vault credential type is specifically designed to provide the vault password needed to decrypt Ansible Vault-encrypted variables like `ansible_password`. When a job runs, the controller uses this credential to unlock the vault file, allowing the playbook to access the encrypted value at runtime without exposing the plaintext password.

Exam trap

The trap here is that candidates confuse the credential type used to authenticate to the target host (Machine credential) with the credential type needed to decrypt the vault file containing the host's password, leading them to select Option B instead of C.

How to eliminate wrong answers

Option A is wrong because Cloud credentials are used to authenticate against cloud providers (e.g., AWS, Azure, GCP) and have no mechanism to supply a vault password for decrypting Ansible Vault files. Option B is wrong because Machine credentials provide SSH keys or username/password for connecting to target hosts, not the vault password needed to decrypt encrypted variables stored in vault files. Option D is wrong because Network credentials are used for network device authentication (e.g., via SSH or API tokens) and do not support supplying vault passwords for Ansible Vault decryption.

Full explanation →
124
MCQeasy

An administrator wants to run a playbook with a different user for a specific host. Which variable should be set?

A.ansible_user
B.ansible_user_id
C.ansible_ssh_user
D.ansible_remote_user
AnswerA

Correct variable to set SSH user.

Why this answer

Option A is correct because ansible_user sets the SSH user for a host. Option B is a deprecated synonym. Option C is for user ID on target.

Option D is a deprecated alternative.

Full explanation →
125
Drag & Dropmedium

Drag and drop the steps to configure a container using Podman with a custom Dockerfile in the correct order.

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

Steps
Order

Why this order

Podman workflow: create Dockerfile, build image, list images, run container, verify.

Full explanation →
126
MCQhard

An administrator has a requirements.yml file specifying roles from multiple sources: a public Galaxy server, a private Git repository, and a local path. They want to install all roles into the roles directory of the current project. Which command will achieve this?

A.ansible-galaxy collection install -r requirements.yml
B.ansible-galaxy install -r requirements.yml --roles-path ./roles
C.ansible-galaxy install -r requirements.yml -p .
D.ansible-galaxy role install --force -r requirements.yml
AnswerB

Correct: Installs all roles from requirements.yml into ./roles.

Why this answer

Option B is correct because ansible-galaxy install with -r reads the requirements file and --roles-path specifies the target directory. Option A uses -p . which installs into the current directory, not the roles subdirectory. Option C installs collections, not roles.

Option D uses --force which is unnecessary and may overwrite existing roles.

Full explanation →
127
MCQmedium

Given a list of dictionaries `users` with keys `name` and `role`, a playbook needs to create a list of names where role is 'admin'. Which expression achieves this?

A.{{ users | selectattr('role', 'equalto', 'admin') | map(attribute='name') | list }}
B.{{ users | map(attribute='name') | selectattr('role', 'equalto', 'admin') | list }}
C.{{ users | json_query("[?role=='admin'].{name: name}") }}
D.{{ users | selectattr('role', 'equalto', 'admin') | list }}
AnswerA

Correctly filters and then extracts names.

Why this answer

Option A is correct because it first uses `selectattr` to filter the list of dictionaries, keeping only those where `role` equals `'admin'`, then applies `map(attribute='name')` to extract the `name` values from the filtered dictionaries, and finally converts the result to a list with the `list` filter. This produces a list of names for admin users.

Exam trap

Red Hat often tests the order of filter chaining: candidates mistakenly apply `map` before `selectattr`, not realizing that `map` transforms the data structure, making subsequent attribute-based filtering impossible.

How to eliminate wrong answers

Option B is wrong because it applies `map(attribute='name')` before `selectattr`, which extracts names from all users first, turning the list into a list of strings; then `selectattr` tries to filter a list of strings by a `role` attribute, which does not exist on strings, so the filter returns an empty list. Option C is wrong because `json_query` with the JMESPath expression `[?role=='admin'].{name: name}` returns a list of dictionaries with a single key `name`, not a list of plain names; to get a list of names, the expression should be `[?role=='admin'].name`. Option D is wrong because it only filters the list to dictionaries where `role` is `'admin'` but does not extract the `name` attribute, so the result is a list of dictionaries, not a list of names.

Full explanation →
128
Multi-Selecteasy

Which TWO of the following are valid 'serial' values for an Ansible rolling update playbook?

Select 2 answers
A.serial: [1,2,3]
B.serial: 50%
C.serial: 1
D.serial: '25%'
E.serial: 'batch'
AnswersB, C

A percentage is a valid value.

Why this answer

Option B is correct because Ansible's 'serial' keyword accepts a percentage value to control how many hosts are updated at a time during a rolling update. The format '50%' (without quotes in YAML) tells Ansible to update half of the hosts in the batch, which is a valid and commonly used pattern for gradual rollouts.

Exam trap

The trap here is that candidates confuse the valid 'serial' syntax with other Ansible constructs like 'batch' or lists, or incorrectly assume that quoted percentage strings are acceptable, when in fact Ansible requires the percentage as a bare value without quotes.

Full explanation →
129
MCQeasy

What is the purpose of the 'meta: flush_handlers' task?

A.Restart services immediately
B.Clear the handler queue
C.Wait for handlers to complete
D.Force handlers to run immediately
AnswerD

flush_handlers triggers all notified handlers right away.

Why this answer

The meta task 'flush_handlers' forces all pending handler actions to run immediately at that point in the play, rather than waiting until the end of the play's task section.

Full explanation →
130
MCQmedium

An Ansible playbook includes a role that defines default variables in 'defaults/main.yml' and role variables in 'vars/main.yml'. A playbook sets the same variable in the play's 'vars' section. Which variable value takes precedence?

A.Role defaults
B.Inventory group vars
C.Role vars
D.Play vars
AnswerD

Play vars have higher precedence than role vars.

Why this answer

In Ansible, variable precedence is hierarchical, and play vars (set directly in the play's `vars` section) have a higher priority than role defaults and role vars. Specifically, play vars override role vars, which in turn override role defaults. Therefore, when the same variable is defined in all three locations, the play vars value takes precedence.

Exam trap

Red Hat often tests the misconception that role vars override play vars because they are defined inside the role, but the actual precedence places play vars above role vars, so candidates must memorize the full variable precedence order to avoid this trap.

How to eliminate wrong answers

Option A is wrong because role defaults have the lowest precedence among the listed options; they are meant to be easily overridden by any other variable source. Option B is wrong because inventory group vars have a lower precedence than play vars; they are overridden by play vars when both define the same variable. Option C is wrong because role vars have a higher precedence than role defaults but are still overridden by play vars, which sit higher in the variable precedence order.

Full explanation →
131
MCQhard

Given the command and error above, what is the most likely cause of the failure?

A.The vault file 'vault@prompt' does not exist.
B.The vault password file must be encrypted with ansible-vault.
C.The --vault-id syntax is incorrect; 'vault@prompt' should be a label and password source, not a vault file.
D.The --check flag is incompatible with vault encryption.
AnswerC

Users often confuse vault-id with vault file; proper usage is '--vault-id @prompt' or '--vault-id myvault@prompt'.

Why this answer

Option D is correct because --vault-id expects a password source, not an encrypted file; the vault file itself should not be specified as a vault-id. Option A is wrong because --check should work. Option B is wrong because the vault file exists.

Option C is wrong because encryption is needed, but the error message says the vault password must be encrypted, which is misleading; actually the vault-id parameter is misused.

Full explanation →
132
MCQeasy

What is the output of this playbook task?

A.'APPLE'
B.An error because map expects a list of strings.
C.['APPLE', 'BANANA']
D.'apple'
AnswerA

Correct; the filters produce 'APPLE'.

Why this answer

Option A is correct because the `map` filter in Ansible applies the `upper` filter to each element of the list `['apple', 'banana']`, converting both strings to uppercase. The `map` filter returns a generator, but when used in a `debug` task, Ansible automatically converts it to a list, producing `['APPLE', 'BANANA']`. However, the question's output is shown as `'APPLE'` (a single string), which is incorrect for the given list; the correct output should be `['APPLE', 'BANANA']`.

Based on the answer options, A is marked as correct, but this is a misalignment—the actual output would be a list, not a single string. Assuming the question intended a single-element list or a different input, the `map` filter with `upper` on a list of strings yields a list of uppercased strings.

Exam trap

The trap here is that candidates may think `map` returns a list directly, but it returns a generator, and they might also confuse the output format (single string vs. list) or incorrectly assume an error occurs when the input is not a list of strings.

How to eliminate wrong answers

Option B is wrong because `map` does not require a list of strings; it can accept any iterable, and the `upper` filter works on strings within the list, so no error occurs. Option C is wrong because the output is `['APPLE', 'BANANA']`, not `['APPLE', 'BANANA']` as a single string—this option is actually correct if the question's expected output is a list, but the question states A is correct, so C is considered wrong in this context. Option D is wrong because `map` with `upper` converts all elements to uppercase, not lowercase, so the output is not `'apple'`.

Full explanation →
133
Multi-Selecthard

An Ansible Automation Platform administrator is reviewing a job template that runs a playbook against a large inventory. To improve performance without sacrificing accuracy, which TWO strategies should be implemented? (Choose two.)

Select 2 answers
A.Implement the ansible-cmdb tool to generate a CMDB from gathered facts.
B.Enable fact caching using a Redis backend.
C.Use the serial keyword to limit concurrent execution to 1 host at a time.
D.Set forks to 50 in ansible.cfg to maximize parallel execution.
E.Set gathering = explicit in ansible.cfg to skip fact gathering.
AnswersA, B

ansible-cmdb centralizes system information, reducing the need for repeated fact gathering.

Why this answer

Option A is correct because the ansible-cmdb tool generates a Configuration Management Database (CMDB) from gathered facts, which can be used for documentation and analysis without re-running fact gathering on every playbook execution. Option B is correct because enabling fact caching with a Redis backend stores gathered facts in a fast, external cache, allowing subsequent playbook runs to reuse cached facts instead of gathering them again from each host, which significantly reduces execution time for large inventories.

Exam trap

The trap here is that candidates may confuse 'improving performance' with 'increasing parallelism' (Option D) or 'skipping facts entirely' (Option E), without realizing that fact caching preserves accuracy while reducing redundant work, and that ansible-cmdb is a documentation tool, not a runtime performance enhancer.

Full explanation →
134
MCQmedium

The inventory above is used in a job template in Automation Controller. The job template also has a machine credential assigned that specifies username 'root' and an SSH key. When the job runs against host web1, which username will Ansible use to connect?

A.admin (from inventory host variable)
B.The username set in the job template's 'extra variables'
C.The first defined username in the credential chain
D.root (from credential)
AnswerA

Inventory host variables take precedence over credential settings.

Why this answer

Option A is correct because Ansible uses a specific precedence order for determining the connection user. When a host variable (like `ansible_user: admin`) is defined in the inventory for host web1, it overrides the username set in the job template's machine credential. The credential's username ('root') acts only as a fallback if no `ansible_user` is defined at the host or group level.

Exam trap

The trap here is that candidates assume the credential's username is always used, forgetting that inventory host variables (like `ansible_user`) override credential settings, a common point of confusion in Ansible's variable precedence hierarchy.

How to eliminate wrong answers

Option B is wrong because extra variables in the job template do not directly set the connection username; they are used for playbook variables, not for the SSH user unless explicitly referenced via `ansible_user` in the extra vars. Option C is wrong because there is no 'credential chain' that selects the first username; Ansible uses a deterministic precedence: host vars > group vars > credential username > default (current user). Option D is wrong because the credential's username ('root') is overridden by the host variable `ansible_user: admin` defined in the inventory for web1.

Full explanation →
135
MCQeasy

What is the purpose of the 'vars' keyword under the nginx role inclusion?

A.Set variables for the common role
B.Define new variables for the playbook
C.Set variables for all roles in the play
D.Override default variables for that role
AnswerD

vars specified with a role override the role's defaults.

Why this answer

The 'vars' keyword under a role inclusion allows the playbook to override default variables defined in that role's defaults/main.yml file. In this case, it sets http_port to 8080 for the nginx role.

Full explanation →
136
MCQmedium

An Ansible playbook needs to dynamically include a set of variables based on the environment (dev/staging/prod). The developer wants to use a variable from a lookup plugin that returns a YAML file path. Which lookup plugin is most appropriate for fetching a file’s contents?

A.env
B.pipe
C.file
D.template
AnswerC

Lookup plugin 'file' reads a file's content as a string.

Why this answer

The `file` lookup plugin is the most appropriate for fetching the contents of a file from the control node, as it reads the entire file and returns its content as a string. This is ideal for dynamically including variable files based on environment (e.g., `{{ lookup('file', 'vars/{{ env }}.yml') }}`), allowing the playbook to load environment-specific YAML data.

Exam trap

Red Hat often tests the distinction between lookup plugins that read from the control node vs. remote host, and the trap here is confusing the `file` lookup (control node) with the `slurp` module (remote host) or assuming `template` can read raw file contents without rendering.

How to eliminate wrong answers

Option A is wrong because the `env` lookup plugin retrieves the value of an environment variable from the control node's shell, not the contents of a file. Option B is wrong because the `pipe` lookup plugin executes a command on the control node and returns its stdout, which is not designed for reading file contents directly. Option D is wrong because the `template` lookup plugin processes a Jinja2 template file and returns the rendered output, not the raw contents of a static YAML file.

Full explanation →
137
MCQmedium

An Ansible playbook uses 'become: yes' to install packages. The playbook works when run manually by the administrator but fails when run from automation controller with 'Missing sudo password'. The administrator has configured a machine credential with the SSH key and the 'Become password' field is blank. What is the most likely issue?

A.The machine credential does not include the become password.
B.The become method is set to 'su' instead of 'sudo'.
C.The remote user is not in the sudoers file.
D.The SSH private key is not loaded into the automation controller.
AnswerA

The become password must be supplied in the credential's 'Become password' field when the remote user requires a password for privilege escalation.

Why this answer

The playbook uses 'become: yes' to escalate privileges, which requires a become password when the remote user's sudo configuration demands password authentication. Since the machine credential's 'Become password' field is blank, Automation Controller cannot supply the password during the privilege escalation step, causing the 'Missing sudo password' error. The administrator's manual run succeeds because the SSH session can prompt interactively for the password, but Automation Controller's non-interactive execution requires the password to be pre-configured in the credential.

Exam trap

Red Hat often tests the distinction between SSH authentication (private key) and privilege escalation (become password) in Automation Controller, tempting candidates to focus on SSH key issues when the error clearly points to the missing become password.

How to eliminate wrong answers

Option B is wrong because the error message explicitly mentions 'sudo', and the default become method in Ansible is 'sudo'; changing to 'su' would produce a different error or require different configuration. Option C is wrong because if the remote user were not in the sudoers file, the error would typically be 'user is not in the sudoers file' or a permission denied message, not 'Missing sudo password'. Option D is wrong because the playbook runs successfully when executed manually by the administrator, proving the SSH key works; the issue is specifically with the become password, not the SSH authentication.

Full explanation →
138
MCQhard

Based on the exhibit, which collection provides modules for managing Red Hat Insights subscriptions?

A.`community.general`
B.`redhat.insights`
C.`ansible.posix`
D.`insights`
AnswerB

The official Red Hat collection for Insights.

Why this answer

The `redhat.insights` collection is the official Ansible collection from Red Hat that provides modules specifically for managing Red Hat Insights subscriptions, including `insights_register` and `insights_unregister`. This collection is maintained by Red Hat and is the correct source for automating Insights registration and subscription management tasks.

Exam trap

The trap here is that candidates may confuse the generic term 'insights' with a valid collection name, or assume `community.general` covers all Red Hat-specific modules, when in fact Red Hat provides a dedicated, namespaced collection (`redhat.insights`) for this purpose.

How to eliminate wrong answers

Option A is wrong because `community.general` is a community-maintained collection that contains a wide variety of general-purpose modules, but it does not include dedicated modules for Red Hat Insights subscription management. Option C is wrong because `ansible.posix` is a collection focused on POSIX system utilities (like `mount`, `firewalld`, `authorized_key`) and has no modules for Red Hat Insights. Option D is wrong because `insights` is not a valid Ansible collection name; the correct collection namespace is `redhat.insights`, and using a bare `insights` would cause a module resolution failure.

Full explanation →
139
MCQhard

An Ansible automation engineer is developing a role that manages a microservice. The role needs to include conditional tasks based on whether a variable `microservice_version` is defined. If defined, it should use that version; otherwise, it should default to `latest`. Which of the following is the most efficient and idiomatic way to implement this default value within the role?

A.In `defaults/main.yml`: `microservice_version: latest` and reference `{{ microservice_version }}` in the task.
B.In the task: `image: "myimage:{{ microservice_version }}"` and use `| mandatory` to fail if undefined.
C.In the task: `vars: microservice_version: "{{ microservice_version | default('latest') }}"`
D.In the task: `image: "myimage:{{ microservice_version | default('latest') }}"`
AnswerD

The default filter provides a fallback value when the variable is undefined.

Why this answer

Option D is correct because it uses the `default` filter directly in the task to set a fallback value for `microservice_version` when it is undefined. This is the most efficient and idiomatic approach in Ansible, as it avoids modifying role defaults or introducing extra variables, and it handles the conditional logic inline without unnecessary complexity.

Exam trap

The trap here is that candidates often confuse the `default` filter with setting variables in `defaults/main.yml`, not realizing that `defaults/main.yml` always provides a value (even if the variable is defined elsewhere with a lower precedence), whereas the `default` filter only applies when the variable is truly undefined, preserving the ability to conditionally use an externally defined value.

How to eliminate wrong answers

Option A is wrong because setting `microservice_version: latest` in `defaults/main.yml` would override any variable defined at a higher precedence (e.g., play vars or extra vars) with the default, but it does not conditionally check if the variable is defined; it always provides a default, which is not the same as conditionally using the defined value. Option B is wrong because using `| mandatory` would cause the task to fail if `microservice_version` is undefined, which contradicts the requirement to default to `latest` when undefined. Option C is wrong because it attempts to redefine `microservice_version` inside the task's `vars` using the same variable name, which creates a recursive reference and will result in an undefined variable error or unexpected behavior.

Full explanation →
140
MCQhard

An organization uses Ansible Automation Platform to perform rolling updates on a 5-node PostgreSQL replication cluster. The playbook uses `serial: 1` and includes tasks to promote a standby, demote the primary, update PostgreSQL packages, and then re-elect the original primary. The cluster health check task verifies that replication lag is under 10 seconds before proceeding to the next node. Recently, during an update of the primary node (node1), the health check after re-election fails because replication lag is 15 seconds due to a large write load. The playbook aborts, leaving the cluster in a degraded state with node1 updated but not serving as primary. The administrator needs to ensure that the update continues while still maintaining cluster integrity. Which action should the administrator take?

A.Wrap the update tasks in a block with a rescue handler that reverts the update on the failed host and then continues with the next host.
B.Add `ignore_errors: yes` to the health check task so the playbook continues despite the failure.
C.Remove the health check task to allow the update to proceed without interruption.
D.Set `max_fail_percentage: 20` to allow up to one failure per update run.
AnswerA

This ensures that if any node fails the health check, the changes on that node are rolled back, and the update proceeds with the next node, preserving cluster integrity.

Why this answer

Option C is correct because using a rescue block allows reverting the update on node1 (e.g., demote it back to standby, re-promote the original standby) so the cluster returns to its original state, and then continue with the next node. This ensures no node remains in an inconsistent state and the update can proceed. Option A is wrong because removing the health check could allow a broken cluster state to go undetected, risking data integrity.

Option B is wrong because `ignore_errors` would continue without reverting the failed node, leaving node1 in a half-updated state that could cause issues. Option D is wrong because `max_fail_percentage: 20` would allow only 1 failure out of 5, but if node1 fails, the count is 1 (20%), so the playbook would still abort; even if it continued, it would not revert the failed node, leading to inconsistencies.

Full explanation →
141
Multi-Selecthard

Which THREE of the following are valid directives that can be used in an `execution-environment.yml` file for `ansible-builder`?

Select 3 answers
A.`system_packages:`
B.`version:`
C.`python_requirements:`
D.`additional_build_steps:`
E.`dependencies:`
AnswersB, D, E

Specifies the version of the execution environment definition.

Why this answer

Option B is correct because `version:` is a valid directive in an `execution-environment.yml` file for ansible-builder. It specifies the version of the execution environment definition format, ensuring compatibility with the builder tool. This directive is used at the top level of the file to declare the schema version, such as `version: 1`.

Exam trap

The trap here is that candidates confuse `version:` as a dependency version specifier rather than recognizing it as a top-level schema version directive, leading them to incorrectly select options like `system_packages:` or `python_requirements:` as valid top-level keys.

Full explanation →
142
MCQmedium

An Ansible role has multiple dependencies defined in meta/main.yml. One of the dependent roles should be executed before the role's own tasks, but only if a certain condition is met. How can this be implemented?

A.The dependency cannot be conditional; use 'include_role' with 'when' in the tasks.
B.Use 'condition' field in the dependencies list.
C.Use 'when' condition in the role's tasks to include the dependency.
D.Use 'pre_tasks' in the playbook to run the conditional dependency.
AnswerA

Correct: Dependencies are always applied; use include_role with when for conditional execution.

Why this answer

Option C is correct because role dependencies in meta are unconditional. To conditionally apply a role, use 'include_role' with 'when' in the tasks. Option A is incorrect because including dependencies within tasks is awkward.

Option B has no such field. Option D uses pre_tasks but that is at the play level, not role level. Therefore, C is correct.

Full explanation →
143
MCQeasy

A systems administrator needs to use a different SSH private key for a group of hosts in an Ansible inventory. Which inventory variable should be set at the group level?

A.ansible_ssh_key
B.ansible_ssh_private_key_file
C.ansible_ssh_key_file
D.ansible_private_key
AnswerB

Correct variable for SSH private key path.

Why this answer

Option B is correct because `ansible_ssh_private_key_file` is the Ansible inventory variable that specifies the path to the SSH private key file for a host or group. When set at the group level, it applies to all hosts in that group, allowing the administrator to use a different key for authentication without modifying individual host definitions.

Exam trap

The trap here is that candidates confuse the variable name with similar-sounding but invalid options like `ansible_ssh_key` or `ansible_private_key`, forgetting that Ansible requires the exact `ansible_ssh_private_key_file` syntax to specify a private key file path.

How to eliminate wrong answers

Option A is wrong because `ansible_ssh_key` is not a valid Ansible variable; the correct variable name includes `private_key_file` to indicate the file path. Option C is wrong because `ansible_ssh_key_file` is not a recognized variable; Ansible uses `ansible_ssh_private_key_file` to avoid ambiguity with public keys. Option D is wrong because `ansible_private_key` omits the `ssh` connection plugin prefix and the `file` suffix, making it an invalid variable that Ansible will ignore.

Full explanation →
144
MCQhard

An Ansible playbook uses a rolling update strategy with serial: 1. After the first host is updated, the playbook stops and shows 'PLAY RECAP' with only one host. What is the most likely reason?

A.the playbook has a 'failed_when' condition that stops execution
B.the inventory contains only one host
C.the play uses 'delegate_to' incorrectly
D.the playbook does not have any task that triggers the next batch, and 'serial' only controls concurrency, not retry
AnswerD

Correct: Serial limits batch size; playbook runs once per batch and finishes.

Why this answer

Option A is correct because the playbook only runs one iteration per host due to 'serial: 1' and lacks a loop or next batch trigger. Options B, C, D are plausible but not the direct cause.

Full explanation →
145
Multi-Selectmedium

Which TWO statements are true about Ansible content collections?

Select 2 answers
A.Collections can be installed from Automation Hub, Galaxy, or a Git repository.
B.Collections cannot contain playbooks.
C.A role stored in a collection can be referenced by its short name without the collection prefix.
D.Execution environments are required to use collections.
E.Fully qualified collection names (FQCN) help avoid naming conflicts.
AnswersA, E

Collections support multiple installation sources.

Why this answer

Option A is correct because Ansible collections can be installed from multiple sources: Automation Hub (a Red Hat curated repository), Galaxy (the community repository), or directly from a Git repository using the `ansible-galaxy collection install` command with a Git URL. This flexibility allows users to leverage curated, community, or custom collections as needed.

Exam trap

The trap here is that candidates often assume collections cannot contain playbooks (option B) or that execution environments are mandatory (option D), but the EX294 exam expects you to know that collections can include playbooks and that EEs are optional for basic collection usage.

Full explanation →
146
Matchingmedium

Match each SELinux context component to its meaning.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts
Matches

SELinux user identity

Role-based access control

Type enforcement (most common)

MLS sensitivity level

MLS/MCS category range

Why these pairings

Components of an SELinux security context.

Full explanation →
147
Multi-Selectmedium

Which TWO are valid ways to restrict access to job templates in Automation Controller?

Select 2 answers
A.Use tags in playbooks
B.Set job template to 'run at specific times'
C.Use inventory source filters
D.Use credential types with separate permissions
E.Assign RBAC roles to teams
AnswersD, E

Credential types can have permissions that restrict which users or teams can use specific credentials in job templates.

Why this answer

Assigning RBAC roles to teams and using credential types with separate permissions are both valid methods to control access to job templates. Tags filter tasks within playbooks, not access. Inventory source filters determine dynamic inventory hosts.

Scheduling sets execution time, not permissions.

Full explanation →
148
MCQmedium

An engineer runs the playbook as shown. 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

Option B is correct because the playbook uses the `block` and `rescue` keywords. The 'configure firewall' task runs first and fails (e.g., due to a syntax error or connectivity issue). The `rescue` block then executes the 'enable service' task.

However, the `always` block (which contains 'start service') is not present, so the playbook does not execute any 'always' tasks; instead, it proceeds to the next play after the rescue block completes. The 'start service' task is not part of the block/rescue structure and is skipped because the play moves to the next play after the rescue.

Exam trap

Cisco 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 →
149
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 →
150
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

Option A is correct. The rescue tasks run after a failure inside the block, and then the play continues with the next task after the block. Option B is wrong because the play does not fail after rescue.

Option C is wrong because the block is not re-executed. Option D is wrong because rescue tasks are executed. Therefore, A is correct.

Full explanation →
Page 1

Page 2 of 7

Page 3

All pages

1234567

Practice EX294 by domain

Target a specific domain to shore up weak areas.

Deploy Ansible Automation PlatformManage inventories and credentialsManage task execution and rolesCoordinate rolling updatesTransform data with filters and pluginsCreate content collections and execution environmentsImplement advanced Ansible automationManage automation security and operations
See all domains with question counts →