Sample questions
Red Hat Certified Engineer EX294 practice questions
Drag and drop the steps to configure an Ansible control node for managing remote hosts into the correct order.
Drag steps to the numbered slots on the right, or tap a step then tap a slot.
Drag and drop the steps to configure a logical volume (LV) using LVM on a new disk in the correct order.
Drag steps to the numbered slots on the right, or tap a step then tap a slot.
Drag and drop the steps to configure a network bond (bond0) using nmcli in the correct order.
Drag steps to the numbered slots on the right, or tap a step then tap a slot.
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.
Drag and drop the steps to configure a basic NFS server to export a directory in the correct order.
Drag steps to the numbered slots on the right, or tap a step then tap a slot.
Drag and drop the steps to configure a systemd service to start automatically at boot in the correct order.
Drag steps to the numbered slots on the right, or tap a step then tap a slot.
Which two conditions could prevent an automation controller job from starting? (Choose two.)
Trap 1: The inventory source is empty
Job starts but may fail with no hosts.
Trap 2: The user is a system auditor
Auditors can have launch permissions.
Trap 3: The execution environment image tag is 'latest'
Tag 'latest' is acceptable.
- A
The inventory source is empty
Why wrong: Job starts but may fail with no hosts.
- B
The project sync is pending
Controller may block jobs until project sync completes.
- C
The job template is disabled
Disabled templates are not available for launch.
- D
The user is a system auditor
Why wrong: Auditors can have launch permissions.
- E
The execution environment image tag is 'latest'
Why wrong: Tag 'latest' is acceptable.
A systems administrator needs to securely store a database password for use in an Ansible playbook. The password should be encrypted at rest and decrypted only at runtime when the playbook is executed. Which approach should the administrator take?
Trap 1: Store the password as a plain text variable in the playbook and use…
no_log prevents printing but the password remains in plain text in the playbook.
Trap 2: Store the password in an unprotected external file and reference it…
External file without encryption is not secure.
Trap 3: Save the password in an environment variable and access it via…
Environment variables may be exposed in process listings and logs.
- A
Store the password as a plain text variable in the playbook and use the no_log: yes directive to prevent logging.
Why wrong: no_log prevents printing but the password remains in plain text in the playbook.
- B
Use the ansible-vault encrypt_string command to encrypt the password and store it in a variables file.
Encrypts the password at rest; decrypted at runtime with vault password.
- C
Store the password in an unprotected external file and reference it with include_vars.
Why wrong: External file without encryption is not secure.
- D
Save the password in an environment variable and access it via lookup('env','DB_PASS').
Why wrong: Environment variables may be exposed in process listings and logs.
A systems administrator is securing Ansible automation. Which two practices help protect sensitive data in playbooks? (Choose two.)
Trap 1: Use the debug module with verbosity to output passwords.
Debug exposes sensitive data.
Trap 2: Avoid using become: yes on tasks that access secrets.
Privilege escalation does not directly protect secrets.
Trap 3: Store credentials in plain text in the inventory.
Plain text is not secure.
- A
Use ansible-vault to encrypt variable files.
Encrypts sensitive variables at rest.
- B
Set the no_log flag on tasks that handle sensitive data.
Prevents sensitive output from being logged.
- C
Use the debug module with verbosity to output passwords.
Why wrong: Debug exposes sensitive data.
- D
Avoid using become: yes on tasks that access secrets.
Why wrong: Privilege escalation does not directly protect secrets.
- E
Store credentials in plain text in the inventory.
Why wrong: Plain text is not secure.
A workflow template in automation controller consists of three job templates that must run sequentially with different credentials. The first job template uses a machine credential to provision a VM, the second uses a network credential to configure the switch, and the third uses a cloud credential to deploy the application. To secure the credential usage, what should the administrator configure?
Trap 1: Create a single credential that covers all three environments.
A single credential cannot cover different contexts (machine, network, cloud).
Trap 2: Define credential validation rules in the workflow node properties.
No such feature exists in automation controller.
Trap 3: Assign all three credentials to the workflow template directly.
Workflow templates do not store credentials; credentials are assigned to job templates.
- A
Create a single credential that covers all three environments.
Why wrong: A single credential cannot cover different contexts (machine, network, cloud).
- B
Set each job template to use the appropriate credential and ensure workflow node permissions are set to 'use credential'.
Each job template uses its own credential; workflow nodes inherit those credentials.
- C
Define credential validation rules in the workflow node properties.
Why wrong: No such feature exists in automation controller.
- D
Assign all three credentials to the workflow template directly.
Why wrong: Workflow templates do not store credentials; credentials are assigned to job templates.
Refer to the exhibit. A playbook fails with the given error. What is the most likely cause?
Exhibit
The following error is displayed when running a playbook:
fatal: [server1]: FAILED! => {"msg": "Attempting to decrypt but no vault secrets found"}Trap 1: The playbook syntax is wrong.
Syntax errors produce different messages.
Trap 2: The inventory file is encrypted.
Inventory encryption would produce a different error.
Trap 3: The remote host is unreachable.
Unreachable host gives connection error, not decryption error.
- A
The playbook syntax is wrong.
Why wrong: Syntax errors produce different messages.
- B
The vault password file is missing or incorrect.
This error means no vault secrets were found to decrypt the file.
- C
The inventory file is encrypted.
Why wrong: Inventory encryption would produce a different error.
- D
The remote host is unreachable.
Why wrong: Unreachable host gives connection error, not decryption error.
An organization uses a proprietary API service that requires token-based authentication with a base64-encoded payload including username, password, and tenant ID. The administrator wants to create a custom credential type in automation controller so that users can input these three values separately, and the playbook receives the final token. Which input configuration fields should be defined?
Trap 1: One text field for the token, and inject it as an environment…
Does not allow separate inputs for components.
Trap 2: Two fields: username and password, and use a lookup plugin to fetch…
Tenant ID is missing from user input; lookup plugin may not be suitable.
Trap 3: Create a single multiline text field where users paste the base64…
Not user-friendly; requires base64 encoding knowledge.
- A
Three separate text fields (username, password, tenant ID) with a custom injector template that concatenates and base64-encodes them.
Allows separate inputs and injector creates the final token.
- B
One text field for the token, and inject it as an environment variable.
Why wrong: Does not allow separate inputs for components.
- C
Two fields: username and password, and use a lookup plugin to fetch tenant ID.
Why wrong: Tenant ID is missing from user input; lookup plugin may not be suitable.
- D
Create a single multiline text field where users paste the base64 string.
Why wrong: Not user-friendly; requires base64 encoding knowledge.
An Ansible automation team is designing a playbook to manage network devices. They need to ensure that the playbook can handle transient network failures by retrying failed tasks a specific number of times with a delay between retries. Which approach should they use?
Trap 1: Set `max_fail_percentage` in the play to 0 and use `ignore_errors:…
`max_fail_percentage` controls play failure, not retries; `ignore_errors` prevents failure but doesn't retry.
Trap 2: Use the `throttle` keyword to limit concurrent tasks and rely on…
`throttle` limits concurrency but does not retry failed tasks.
Trap 3: Set `serial: 1` on the play to ensure only one host is processed at…
`serial` controls batch size, not retries; it doesn't handle transient failures.
- A
Set `max_fail_percentage` in the play to 0 and use `ignore_errors: yes` with a rescue block.
Why wrong: `max_fail_percentage` controls play failure, not retries; `ignore_errors` prevents failure but doesn't retry.
- B
Use the `throttle` keyword to limit concurrent tasks and rely on idempotency.
Why wrong: `throttle` limits concurrency but does not retry failed tasks.
- C
Set `serial: 1` on the play to ensure only one host is processed at a time and rely on idempotency.
Why wrong: `serial` controls batch size, not retries; it doesn't handle transient failures.
- D
Use the `until` loop with `retries` and `delay` parameters on the task.
The `until` loop with `retries` and `delay` retries the task until a condition is met or retries are exhausted, ideal for transient failures.
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?
Trap 1: Set `gather_facts: no` to skip fact gathering and reduce failure…
Skipping facts does not alter failure handling behavior.
Trap 2: Set `any_errors_fatal: true` at the play level.
`any_errors_fatal: true` would cause the play to abort on the first failure, opposite of desired.
Trap 3: Set `force_handlers: true` at the play level.
`force_handlers` forces handlers to run even if the play fails, but does not affect continuation after task failure.
- A
Set `gather_facts: no` to skip fact gathering and reduce failure points.
Why wrong: Skipping facts does not alter failure handling behavior.
- B
Set `any_errors_fatal: true` at the play level.
Why wrong: `any_errors_fatal: true` would cause the play to abort on the first failure, opposite of desired.
- C
Set `force_handlers: true` at the play level.
Why wrong: `force_handlers` forces handlers to run even if the play fails, but does not affect continuation after task failure.
- D
`ignore_errors: yes` on each task that might fail.
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.
An automation controller administrator must ensure that a playbook's output does not expose sensitive data. Which TWO actions should be taken? (Choose exactly two.)
Trap 1: Set 'stdout_callback = actionable' in ansible.cfg.
This changes callback but does not hide sensitive data.
Trap 2: Use 'name: "Sensitive task"' but keep the task body visible.
The task name does not hide output.
Trap 3: Use 'tags: never' on sensitive tasks.
Tags control task execution, not output visibility.
- A
Set 'no_log: true' on tasks that handle sensitive data.
This prevents the output of those tasks from being displayed.
- B
Set 'stdout_callback = actionable' in ansible.cfg.
Why wrong: This changes callback but does not hide sensitive data.
- C
Use 'name: "Sensitive task"' but keep the task body visible.
Why wrong: The task name does not hide output.
- D
Add 'display_args_to_stdout = false' to the execution environment's ansible.cfg.
This prevents task arguments from being displayed, which may contain sensitive values.
- E
Use 'tags: never' on sensitive tasks.
Why wrong: Tags control task execution, not output visibility.
An organization requires that all Ansible playbooks be executed using a specific service account that has limited permissions. The account can only run playbooks from a specific directory. Which approach best enforces this requirement in automation controller?
Trap 1: Use an inventory that contains only the allowed hosts.
Inventory does not restrict which playbooks can be run.
Trap 2: Configure an execution environment that mounts the authorized…
Execution environments provide runtime dependencies, not execution path restrictions.
Trap 3: Assign the service account a machine credential that connects to…
Machine credentials provide authentication, not path restrictions.
- A
Use an inventory that contains only the allowed hosts.
Why wrong: Inventory does not restrict which playbooks can be run.
- B
Configure an execution environment that mounts the authorized directory as read-only.
Why wrong: Execution environments provide runtime dependencies, not execution path restrictions.
- C
Create a project that syncs only the authorized directory, and assign the service account as the only user with execute permissions on that project.
Projects control source of playbooks; RBAC can restrict execution to that project.
- D
Assign the service account a machine credential that connects to the controller via SSH.
Why wrong: Machine credentials provide authentication, not path restrictions.
An Ansible automation controller job template uses a custom credential type that requires a secret token. The token is stored as an extra variable in the job template definition. A security audit reveals the token is visible in plaintext in the job output. Which action should the administrator take to secure the secret?
Trap 1: Vault-encrypt the variable in the playbook and reference it with {{…
Vault encryption protects the value at rest but does not hide it from job output when passed as an extra variable.
Trap 2: Create a custom credential type that injects the token as an…
This is a good practice but does not address the existing extra variable; the token would still be visible if the extra variable remains.
Trap 3: Store the token in a file on the controller with 600 permissions…
This does not prevent the token from being displayed in job output if it is used as a variable without no_log.
- A
Define the variable in the job template's 'extra variables' field with 'no_log: true' set in the playbook for that variable.
Setting no_log on the variable prevents it from being displayed in logs and job output, meeting the security requirement.
- B
Vault-encrypt the variable in the playbook and reference it with {{ vault_var }}.
Why wrong: Vault encryption protects the value at rest but does not hide it from job output when passed as an extra variable.
- C
Create a custom credential type that injects the token as an environment variable, and remove the extra variable from the job template.
Why wrong: This is a good practice but does not address the existing extra variable; the token would still be visible if the extra variable remains.
- D
Store the token in a file on the controller with 600 permissions and use 'lookup' in the playbook.
Why wrong: This does not prevent the token from being displayed in job output if it is used as a variable without no_log.
A Red Hat Ansible Automation Platform deployment uses automation mesh to manage remote nodes across a high-latency WAN. An administrator notices that some job runs fail intermittently due to connection timeouts. The administrator wants to improve reliability without changing network infrastructure. Which configuration change is most effective?
Trap 1: Increase the 'retries' parameter for each task.
Retries handle transient failures but do not extend the time allowed for a single connection.
Trap 2: Increase the 'forks' value in ansible.cfg to 50.
Forks control the number of parallel connections, not timeout behavior.
Trap 3: Set 'async: 600' and 'poll: 10' in the playbook.
Async/poll is for long-running tasks, not for general connection timeouts.
- A
Increase the 'timeout' value in the [defaults] section of ansible.cfg to 60 seconds.
This extends the connection timeout, accommodating high-latency links.
- B
Increase the 'retries' parameter for each task.
Why wrong: Retries handle transient failures but do not extend the time allowed for a single connection.
- C
Increase the 'forks' value in ansible.cfg to 50.
Why wrong: Forks control the number of parallel connections, not timeout behavior.
- D
Set 'async: 600' and 'poll: 10' in the playbook.
Why wrong: Async/poll is for long-running tasks, not for general connection timeouts.
A managed node is not responding to Ansible automation. The administrator verifies that the node is reachable via SSH and that the SSH key is correctly deployed. However, 'ansible all -m ping' fails with 'UNREACHABLE'. The automation controller uses a custom execution environment. What is the most likely cause?
Trap 1: The SSH private key has incorrect permissions on the controller.
The administrator verified the SSH key is correctly deployed.
Trap 2: The remote user specified in the credential does not have sudo…
The ping module does not require sudo.
Trap 3: The automation controller is behind a firewall that blocks SSH.
The administrator verified the node is reachable via SSH, so firewall is not blocking.
- A
The SSH private key has incorrect permissions on the controller.
Why wrong: The administrator verified the SSH key is correctly deployed.
- B
The remote user specified in the credential does not have sudo access.
Why wrong: The ping module does not require sudo.
- C
The custom execution environment is missing the 'python3' or 'python' package.
Ansible requires Python on the control node (execution environment) to execute modules; missing Python causes unreachable errors.
- D
The automation controller is behind a firewall that blocks SSH.
Why wrong: The administrator verified the node is reachable via SSH, so firewall is not blocking.
Which TWO of the following are best practices when coordinating rolling updates with Ansible?
Trap 1: Use 'strategy: free' to allow hosts to run tasks independently.
The free strategy bypasses the ordered batch control, which can lead to inconsistent states.
Trap 2: Use 'gather_facts: no' to speed up the playbook.
Speeding up does not improve coordination or safety; fact gathering is often needed for conditional logic.
Trap 3: Set 'any_errors_fatal: true' to stop the update on the first…
This stops the entire update prematurely, which is not ideal for rolling updates; better to handle failures gracefully.
- A
Define a 'max_fail_percentage' to abort the update if too many hosts fail.
This ensures the update stops if a critical number of hosts fail, preventing widespread issues.
- B
Use the 'serial' keyword to update a subset of hosts at a time.
This controls the number of hosts updated concurrently, reducing risk.
- C
Use 'strategy: free' to allow hosts to run tasks independently.
Why wrong: The free strategy bypasses the ordered batch control, which can lead to inconsistent states.
- D
Use 'gather_facts: no' to speed up the playbook.
Why wrong: Speeding up does not improve coordination or safety; fact gathering is often needed for conditional logic.
- E
Set 'any_errors_fatal: true' to stop the update on the first failure.
Why wrong: This stops the entire update prematurely, which is not ideal for rolling updates; better to handle failures gracefully.
A developer has created a collection and needs to publish it to a private Automation Hub. Which command should be used to upload the collection archive?
Trap 1: `ansible-galaxy collection server upload ./tar.gz`
Invalid syntax.
Trap 2: `ansible-galaxy role import my-namespace my_collection`
Used for roles, not collections.
Trap 3: `ansible-galaxy collection upload…
'upload' is not a valid subcommand.
- A
`ansible-galaxy collection server upload ./tar.gz`
Why wrong: Invalid syntax.
- B
`ansible-galaxy collection publish ./my-namespace-my_collection-1.0.0.tar.gz`
Correct command to publish a collection archive.
- C
`ansible-galaxy role import my-namespace my_collection`
Why wrong: Used for roles, not collections.
- D
`ansible-galaxy collection upload ./my-namespace-my_collection-1.0.0.tar.gz`
Why wrong: 'upload' is not a valid subcommand.
A developer wants to create a new Ansible collection from a skeleton template. Which command should be used?
Trap 1: `ansible-galaxy collection generate my_namespace.my_collection`
'generate' is not a valid subcommand.
Trap 2: `ansible-galaxy collection create my_namespace.my_collection`
'create' is not a valid subcommand.
Trap 3: `ansible-galaxy collection start my_namespace.my_collection`
'start' is not a valid subcommand.
- A
`ansible-galaxy collection generate my_namespace.my_collection`
Why wrong: 'generate' is not a valid subcommand.
- B
`ansible-galaxy collection create my_namespace.my_collection`
Why wrong: 'create' is not a valid subcommand.
- C
`ansible-galaxy collection start my_namespace.my_collection`
Why wrong: 'start' is not a valid subcommand.
- D
`ansible-galaxy collection init my_namespace.my_collection`
Correct command to initialize a collection skeleton.
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?
Exhibit
version: 3 build_arg_defaults: EE_BASE_IMAGE: registry.redhat.io/ansible-automation-platform-24/ee-minimal-rhel8:latest dependencies: galaxy: requirements.yml python: requirements.txt system: bindep.txt
Trap 1: The base image itself
Could be changed but bindep.txt is the direct method.
Trap 2: requirements.yml
Contains collections, not system packages.
Trap 3: requirements.txt
Contains Python packages.
- A
The base image itself
Why wrong: Could be changed but bindep.txt is the direct method.
- B
requirements.yml
Why wrong: Contains collections, not system packages.
- C
requirements.txt
Why wrong: Contains Python packages.
- D
bindep.txt
Contains system package dependencies.
Which THREE of the following are valid directives that can be used in an `execution-environment.yml` file for `ansible-builder`?
Trap 1: `system_packages:`
Not a valid directive; system packages are specified under 'dependencies: system:'.
Trap 2: `python_requirements:`
Not a valid directive; Python dependencies are listed under 'dependencies: python:'.
- A
`system_packages:`
Why wrong: Not a valid directive; system packages are specified under 'dependencies: system:'.
- B
`version:`
Specifies the version of the execution environment definition.
- C
`python_requirements:`
Why wrong: Not a valid directive; Python dependencies are listed under 'dependencies: python:'.
- D
`additional_build_steps:`
Allows adding custom build steps like installing extra RPMs.
- E
`dependencies:`
Defines collections, Python, and system dependencies.
Question Discussion
Share a tip, memory trick, or ask about the reasoning behind this question. Do not post real exam questions, leaked content, braindumps, or copyrighted exam material. Comments are moderated and may be removed without notice.
Sign in to join the discussion.