CCNA Advanced Automation Questions — Page 1 of 2

MCQhard

Refer to the exhibit. A playbook fails with the error 'file not found: /var/www/app-v2.1.0.tar.gz' on the control node. What is the most likely cause?

A.The become: yes is missing from the copy task

B.The remote_src parameter is not set in the copy task

C.The archive file does not exist on the control node

D.The unarchive task should use remote_src: no

AnswerC

The copy source is /var/www/app-v2.1.0.tar.gz on the control node, which is missing.

Why this answer

The copy task uses a relative path to the source file on the control node, which is not found.

Practice this question →

MCQmedium

A role contains a handler. The playbook includes the role and also defines a task that notifies the same handler. When the playbook runs, the handler executes only once. Which of the following best explains this behavior?

A.the handler was already triggered by the role and is skipped for the play task

B.handlers are deduplicated by name; multiple notifications trigger the handler only once per play

C.the role's handler uses 'listen' which overrides notifications

D.the playbook's task notifies a different handler with the same name

AnswerB

Correct: Ansible ensures handlers execute once even if notified multiple times.

Why this answer

Ansible handlers are deduplicated by name within a play. When a handler is notified multiple times—whether from a role or a playbook task—it runs only once at the end of the play, after all tasks have completed. This prevents redundant executions and is a core design feature of Ansible's handler system.

Exam trap

The trap here is that candidates may think handlers are executed immediately upon notification or that multiple notifications cause multiple executions, but Ansible deduplicates by handler name and runs them only once per play, regardless of the number of notifications.

How to eliminate wrong answers

Option A is wrong because handlers are not 'skipped' after being triggered; they are simply queued and executed once regardless of how many times they are notified. Option C is wrong because the 'listen' directive allows multiple handlers to be triggered by a single notification, but it does not override or deduplicate notifications; deduplication is inherent to handler names. Option D is wrong because if the playbook's task notifies a different handler with the same name, it would be the same handler object (since names are unique within a play), and the behavior would still be deduplication, not a separate handler.

Practice this question →

MCQeasy

An administrator needs to apply a set of firewall rules to multiple servers. They have created a playbook that uses the firewalld module. When running the playbook, they receive 'ERROR! module not found: firewalld'. The control node has the module available locally. What is the most likely cause?

A.The playbook uses the wrong module name.

B.The ansible.posix collection is not installed on the control node.

C.The ansible.cfg has a wrong module path.

D.The module is not installed on the target nodes.

AnswerB

The module resides in ansible.posix, which needs to be installed.

Why this answer

Error 'module not found: firewalld' indicates the module is not accessible. The firewalld module belongs to the ansible.posix collection, which must be installed on the control node (e.g., via 'ansible-galaxy collection install ansible.posix'). Option B is correct because the missing collection is the most likely cause.

Option A is incorrect because 'firewalld' is the valid module name. Option C is possible but less likely than a missing collection. Option D is incorrect because modules execute on the control node, not target nodes.

Practice this question →

MCQeasy

An Ansible playbook is designed to run on a group of database servers. The administrator wants to ensure that a task runs only on the primary database server, which is defined in the inventory with a variable 'primary: true'. Which conditional should be used?

A.ignore_errors: yes

B.when: primary

C.run_once: true

D.delegate_to: "{{ primary }}"

AnswerB

The when clause evaluates to true if the variable is truthy.

Why this answer

The `when` conditional in Ansible evaluates a Jinja2 expression to determine whether a task should execute. By using `when: primary`, the task will run only on hosts where the inventory variable `primary` is defined and evaluates to `true` (a truthy value). This directly meets the requirement to target the primary database server.

Exam trap

The trap here is that candidates confuse `run_once: true` with a conditional that selects a specific host, not realizing `run_once` merely limits execution to a single arbitrary host in the group, not the one defined by a variable like `primary: true`.

How to eliminate wrong answers

Option A is wrong because `ignore_errors: yes` does not control task execution based on a condition; it merely continues playbook execution if the task fails, which is irrelevant to targeting a specific host. Option C is wrong because `run_once: true` ensures a task runs only once across the entire batch of hosts (typically on the first host in the group), but it does not select a specific host based on a variable like `primary: true`; it could run on any host, not necessarily the primary. Option D is wrong because `delegate_to: "{{ primary }}"` attempts to delegate the task to a host named by the variable `primary`, but this is not a conditional; it changes the target host for execution and would fail if `primary` is not a valid hostname or group, and it does not evaluate a boolean variable.

Practice this question →

Drag & Dropmedium

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.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

Why this order

The correct order to configure a network bond using nmcli is: create the bond connection first, then add slave interfaces to it, set the bonding mode (e.g., active-backup), activate the bond, and finally verify the bond status. This sequence ensures that the bond interface exists before adding slaves and that the mode is set before activation so that the bond operates correctly from the start.

Practice this question →

MCQmedium

A playbook uses serial: 2 and sets any_errors_fatal: true. The first batch of 2 hosts both fail. What happens?

A.The playbook continues with the next batch.

B.The playbook aborts and no further batches run.

C.The playbook marks the batch as unreachable and continues.

D.The playbook retries the failed hosts.

AnswerB

any_errors_fatal stops execution on first failure.

Why this answer

When `any_errors_fatal: true` is set and a batch of hosts fails, Ansible immediately aborts the entire playbook run for all remaining hosts, regardless of the `serial` setting. Since the first batch of 2 hosts both fail, no further batches are executed. This behavior is designed to prevent cascading failures in critical deployments.

Exam trap

In Red Hat RHCE exams, candidates are often tested on the interaction between `serial` and `any_errors_fatal`, trapping those who assume `serial` batches always run independently, forgetting that `any_errors_fatal` forces a global abort on the first failure.

How to eliminate wrong answers

Option A is wrong because `any_errors_fatal: true` overrides the default batch-continue behavior of `serial`; Ansible does not proceed to the next batch after a failure in the current batch. Option C is wrong because the hosts are not marked as unreachable (which would require a connectivity failure, not a task failure), and the playbook does not continue; it aborts. Option D is wrong because `any_errors_fatal: true` does not trigger automatic retries; retry behavior is controlled by `retries` and `until` on individual tasks, not by this directive.

Practice this question →

Multi-Selecthard

Which two statements about ansible-vault are true? (Select exactly 2.)

Select 2 answers

A.Vault-encrypted files cannot be used with include_vars.

B.Vault can encrypt entire files or individual variables.

C.Vault uses AES-128 encryption by default.

D.Vault passwords can be stored directly in ansible.cfg.

E.Vault supports multiple passwords with vault IDs.

AnswersB, E

ansible-vault encrypts at file level; variable encryption requires specific syntax.

Why this answer

Ansible-vault can encrypt either entire files (e.g., vars files, role defaults) or individual variables within a YAML file using the `!vault` tag. This flexibility allows you to protect sensitive data at the granularity you choose, without requiring separate encrypted files for each secret.

Exam trap

The trap here is that candidates often confuse the encryption algorithm (AES-128 vs AES-256) or assume vault-encrypted files cannot be dynamically included, when in fact include_vars works seamlessly with decryption.

Practice this question →

MCQmedium

An Ansible role has tasks that need to run in a specific order, and some tasks must use a different shell interpreter. Which feature allows the role to control task execution order and environment settings?

A.Use the meta module to declare dependencies and the environment directive in tasks.

B.Use the strategy plugin and a custom lookup to set interpreter.

C.Use tags to control execution order and a custom inventory script.

D.Use the block directive to order tasks and a vars file for interpreter.

AnswerD

The block directive groups tasks so they execute in the defined order. A vars file can set variables like ansible_shell_executable to change the shell interpreter for tasks in the block.

Why this answer

The block directive groups tasks that run in the order they appear, allowing control over task execution order within a role. Environment settings, such as a different shell interpreter, can be achieved using a vars file to define variables like ansible_shell_executable, which applies to tasks in the block. Option A is incorrect because the meta module (ansible.builtin.meta) does not declare role dependencies; role dependencies are defined in meta/main.yml.

Options B and C are incorrect as strategy plugins and tags do not directly control task order or interpreter settings.

Exam trap

Confusing the meta module (flush_handlers, end_play) with meta/main.yml, which defines role dependencies.

Practice this question →

MCQhard

An administrator needs to securely pass a database password to a playbook without exposing it in logs or the command line. Which approach is the most secure?

A.Store the password in an Ansible Vault-encrypted variable file and include it.

B.Set the password in a variable and use 'no_log: true' on tasks that use it.

C.Store the password in a host_vars file with restricted file permissions.

D.Prompt for the password and pass it as an extra variable using -e.

AnswerA

Vault encrypts the data, and the vault password is prompted or provided via a vault password file.

Why this answer

Ansible Vault encrypts the variable file at rest, and including it via `vars_files` or `include_vars` decrypts it only in memory during playbook execution. This prevents the password from appearing in logs, the command line, or the process table, meeting the security requirement.

Exam trap

The trap here is that candidates often confuse `no_log: true` with actual encryption, thinking it hides the secret from all exposure, when in fact it only suppresses output and does not protect the secret from being visible in the process table or module internals.

How to eliminate wrong answers

Option B is wrong because `no_log: true` only hides the task output from logs, but the password is still passed in plaintext to the module and could be exposed via the process table or debug output if the module itself logs it. Option C is wrong because `host_vars` files with restricted file permissions still store the password in plaintext on disk, and any user with read access to the file or a backup can retrieve it. Option D is wrong because passing the password as an extra variable with `-e` exposes it in the command line, which is visible in the process list and shell history, and it may also appear in logs if the playbook uses `--log-level` or `ANSIBLE_LOG_PATH`.

Practice this question →

MCQmedium

Refer to the exhibit. Which of the following is the most likely cause of this error?

A.The playbook is running without '--become' flag.

B.The 'become_method' is set to 'su' instead of 'sudo'.

C.The 'ansible_become_password' was provided but incorrect.

D.The remote user is not in the sudoers file.

E.The 'ask_become_pass' is set to 'false' and no become password is provided.

AnswerE

Correct: If ask_become_pass is false and no password is set via variable or vault, Ansible cannot obtain a sudo password, resulting in 'Missing sudo password'.

Why this answer

The error message indicates that Ansible is unable to authenticate with the remote host, which occurs when `ask_become_pass` is set to `false` (or defaults to `false` in some configurations) and no become password is provided via `--ask-become-pass` or an `ansible_become_password` variable. Without a password, the privilege escalation attempt fails, resulting in a permission denied error.

Exam trap

The RHCE exam often tests the distinction between enabling privilege escalation (`--become`) and providing the authentication credential (`--ask-become-pass` or `ansible_become_password`), leading candidates to mistakenly choose options that address the escalation method rather than the missing password.

How to eliminate wrong answers

Option A is wrong because the `--become` flag only enables privilege escalation; it does not provide a password, and the error is about authentication failure, not about missing escalation. Option B is wrong because `become_method` set to `su` would use a different escalation method, but the error is generic and not specific to `su` vs `sudo`; the core issue is missing password, not method. Option C is wrong because if `ansible_become_password` were provided but incorrect, the error would typically be 'Incorrect sudo password' or similar, not a generic authentication failure.

Option D is wrong because if the remote user were not in the sudoers file, the error would be 'user is not in the sudoers file' or 'sorry, you must have a tty to run sudo', not a generic authentication failure.

Practice this question →

MCQhard

An Ansible playbook uses the 'constructed' inventory plugin with 'keyed_groups' to create groups based on 'ansible_distribution'. Despite correct configuration, hosts are not assigned to the expected groups. What is the most likely cause?

A.the 'keyed_groups' syntax uses invalid Jinja2 expressions

B.the inventory file is incorrectly formatted

C.the 'strict' option is set to 'yes' and the required facts are not gathered

D.the plugin is not enabled in ansible.cfg

AnswerC

Correct: with strict: yes, undefined variables cause group assignment to fail silently.

Why this answer

'strict: yes' causes plugin to fail on undefined variables; if facts are not gathered, 'ansible_distribution' is undefined. Options A, B, D are plausible but less likely.

Practice this question →

MCQeasy

A large enterprise manages its infrastructure with Ansible Automation Platform. The operations team reports that job runs are taking longer than expected, especially for playbooks that include role dependencies. After investigation, they notice that the control node has high CPU and memory usage during job execution. The inventory contains 500 hosts, and the playbooks use several roles that include dynamic includes (include_tasks) based on conditional variables. The team wants to reduce the load on the control node without changing the playbook logic or reducing functionality. Which action should the team take?

A.Use the --limit flag to run the playbook against a subset of hosts.

B.Increase the forks value in ansible.cfg to 100 to speed up execution.

C.Enable pipelining in ansible.cfg by setting pipelining = True.

D.Migrate to AWX to distribute job execution across multiple nodes.

AnswerC

Pipelining reduces the number of SSH operations, decreasing control node load.

Why this answer

Enabling pipelining reduces the number of SSH connections Ansible makes to each host by combining multiple task operations into a single SSH session. This drastically lowers the overhead on the control node's CPU and memory, especially when executing many tasks with dynamic includes across a large inventory, without altering playbook logic.

Exam trap

The trap here is that candidates often confuse increasing forks (Option B) as a performance fix, but it actually increases control node load, while pipelining reduces connection overhead without changing parallelism.

How to eliminate wrong answers

Option A is wrong because --limit reduces the number of target hosts, which changes the scope of execution and does not reduce load per host or address the control node's resource usage during role dependency resolution. Option B is wrong because increasing forks speeds up parallel execution but actually increases CPU and memory load on the control node by spawning more concurrent SSH processes, worsening the problem. Option D is wrong because migrating to AWX distributes job execution across worker nodes, which offloads work from the control node but is a significant architectural change that goes beyond the requirement of not changing functionality and is not a simple configuration fix.

Practice this question →

Multi-Selecteasy

Which TWO of the following are advantages of using 'ansible-pull' over 'ansible-playbook'?

Select 2 answers

A.It can be used in environments where a central control node is not desired.

B.It eliminates the need for an inventory file.

C.Nodes can self-configure by pulling playbooks from a git repository.

D.It supports a different syntax for playbooks that is more efficient.

E.It reduces load on the control node because it runs locally on each node.

AnswersA, C

ansible-pull eliminates the need for a central push server.

Why this answer

Ansible-pull operates in a pull-based model where each managed node independently retrieves and executes playbooks from a central repository (e.g., a Git server). This eliminates the need for a persistent central control node, making it ideal for environments where a dedicated Ansible control node is not desired or feasible, such as in large-scale or decentralized deployments.

Exam trap

The trap here is that candidates often confuse 'eliminating the need for a control node' with 'eliminating the need for inventory,' or incorrectly assume that running locally automatically reduces load, when in fact the load is redistributed rather than reduced.

Practice this question →

MCQhard

Refer to the exhibit. An Ansible playbook targeting 'production' hosts fails with 'deploy_user is undefined'. What is the most likely cause?

A.the playbook uses a different group name in the play

B.the inventory file is missing the host entries

C.the variable is defined but overridden by a higher precedence variable

D.the variable 'deploy_user' is not defined in any group or host vars

AnswerD

Correct: the inventory only defines ansible_user, not deploy_user.

Why this answer

The error 'deploy_user is undefined' indicates that Ansible cannot find a value for the variable 'deploy_user' in any of the variable sources it searches. In Ansible, variables are resolved from group vars, host vars, play vars, and other sources with a specific precedence order. If the variable is not defined in any group or host vars file, nor in the inventory itself, Ansible will fail with an 'undefined variable' error.

The exhibit shows a play targeting 'production' hosts, so the most likely cause is that no group or host var file defines 'deploy_user' for that group or its hosts.

Exam trap

In Red Hat exams, the distinction between 'undefined' and 'overridden' variables is often tested; the trap here is that candidates confuse a variable being overridden (which still results in a defined value) with a variable being completely missing from all variable sources.

How to eliminate wrong answers

Option A is wrong because if the playbook used a different group name in the play, the error would likely be about an undefined group or no hosts matched, not a specific variable being undefined. Option B is wrong because missing host entries would cause a 'no hosts matched' or 'could not find host' error, not a variable undefined error. Option C is wrong because if the variable were defined but overridden by a higher precedence variable, the variable would still be defined (just with a different value), and Ansible would not throw an 'undefined' error; it would use the overridden value.

Practice this question →

MCQeasy

A playbook uses the copy module to deploy a configuration file. The file should be templated with variables, but the engineer mistakenly uses the 'src' parameter with a static file instead of 'content' or a template module. What is the most likely outcome?

A.The module automatically renders the Jinja2 template before copying.

B.The file is copied without variable substitution, resulting in literal Jinja2 syntax in the destination.

C.The playbook fails because the source file contains undefined variables.

D.The task is skipped because copy cannot handle variables.

AnswerB

Copy module does not process templates.

Why this answer

The copy module with the 'src' parameter copies a file without any processing of Jinja2 templates. It does not perform variable substitution. Therefore, if the source file contains Jinja2 syntax (e.g., {{ variable }}), it will be copied literally to the destination.

The correct answer is B. Option A is incorrect because the copy module does not automatically render templates. Option C is incorrect because the playbook will not fail due to undefined variables; it simply copies the file as-is.

Option D is incorrect because the task will execute and copy the file, not skip.

Practice this question →

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.

Practice this question →

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

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.

Practice this question →

MCQhard

An Ansible inventory file includes a group [webservers] containing web1. Another group [all] contains web1 and web2. When running a playbook with --limit webservers, the playbook fails on web2. Why does this happen?

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 file does not list web2 under the 'webservers' group; only web1 is listed. However, when running the playbook with --limit webservers, web2 is still targeted. This indicates a misconfiguration, such as a duplicate host entry, incorrect group assignment, or a faulty inventory script that inadvertently includes web2 in the webservers group.

Ansible's --limit option restricts execution to hosts that are members of the specified group, so if web2 is not supposed to be in webservers but appears due to error, the playbook fails on web2 because it is unreachable or misconfigured for that role.

Exam trap

Candidates often assume that the --limit option filters based on intended roles or hostnames rather than actual group membership in the inventory. The trap here is that the inventory determines group membership, and any host included (even by mistake) will be targeted. This question tests the understanding that --limit uses inventory data, not logical groupings.

How to eliminate wrong answers

Option B is wrong because the SSH key authorization issue would cause a connection failure for any host, not specifically web2 when limited to 'webservers'; the question focuses on why the playbook fails on web2 due to group membership, not SSH authentication. Option C is wrong because a syntax error in the inventory file would typically cause the entire playbook to fail or produce a parsing error, not selectively include web2 in the 'webservers' group; the exhibit shows a valid inventory structure. Option D is wrong because the playbook's 'hosts' directive set to 'all' would target all inventory hosts, but the limit option overrides this to only 'webservers', so web2 would still be included only if it is in that group; the failure is due to web2 being in 'webservers', not the 'hosts' directive.

Practice this question →

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

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

Practice this question →

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

The most likely cause is that the Ansible Tower node executing the job does not have the custom virtual environment installed (Option B). Even though the job template is configured to use the custom virtual environment at '/opt/custom_venv', Tower runs jobs on its own execution nodes (or the node specified in the job template's execution environment). If that node does not have the custom virtual environment installed, it will fail to find the 'community.docker' collection.

Option A is incorrect because 'ansible_connection: local' does not affect collection availability. Option C is incorrect because the team verified the collection is installed in the custom venv. Option D is incorrect because the question states the job template uses the correct path; the failure is due to the node lacking the venv entirely.

Practice this question →

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

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.

Practice this question →

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

In Ansible Tower, each vault credential is associated with a single vault ID. When a playbook uses multiple vault IDs (e.g., dev, test, prod), Tower must have a vault credential for each ID to decrypt files encrypted with that ID. By adding multiple vault credentials to the job template—one for each vault ID used in the project—Tower can automatically select the correct credential for decryption, resolving the failure.

Option A is correct because it provides Tower with all necessary vault IDs. Option B is wrong because Tower does not support comma-separated passwords in a single credential. Option C would simplify but is not a configuration change.

Option D is incorrect because the password file already contains the correct password for the test vault ID, but the encrypted file uses the dev vault ID.

Practice this question →

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

Ansible_user sets the remote user for SSH connections to the target host. Option B (ansible_user_id) is a fact variable that returns the UID of the user running the task on the remote host, not the connection user. Option C (ansible_ssh_user) is a deprecated alias for ansible_user.

Option D (ansible_remote_user) is also a deprecated alias.

Practice this question →

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.

Practice this question →

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

The `--vault-id` option expects a label and a password source (e.g., `vault@prompt` means the label is 'vault' and the password is prompted interactively). The error indicates that Ansible is interpreting the entire string as a vault file path, which fails because no file named 'vault@prompt' exists. Option C correctly identifies that the syntax is being misapplied.

Exam trap

The trap here is that candidates confuse the `--vault-id` argument with a vault file path, assuming the error means the file is missing, rather than recognizing that the syntax requires a label and source separated by `@`.

How to eliminate wrong answers

Option A is wrong because the error is not about a missing file named 'vault@prompt'; it is about Ansible misinterpreting the `--vault-id` argument as a file path due to incorrect syntax. Option B is wrong because vault password files are plain-text files containing the password, not encrypted with `ansible-vault`; encrypting the password file would make it unreadable by Ansible. Option D is wrong because the `--check` flag is fully compatible with vault encryption; it performs a dry run without making changes and does not affect vault password handling.

Practice this question →

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

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.

Practice this question →

MCQmedium

Refer to the exhibit. An admin wants to run a playbook on all hosts in the 'webservers' group. Which ansible-playbook command is correct?

A.ansible-playbook site.yml -i webservers

B.ansible-playbook site.yml --limit webservers

C.ansible-playbook site.yml -e 'groups=webservers'

D.ansible-playbook site.yml --hosts webservers

AnswerB

Correctly limits to webservers group.

Why this answer

The command uses --limit to target the specific group.

Practice this question →

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

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.

Practice this question →

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

Ansible role dependencies defined in meta/main.yml do not support conditional execution; the 'dependencies' field only accepts role names or a dictionary with 'role' and optional 'vars'. To conditionally execute a role, you must use 'include_role' with a 'when' clause in the playbook or tasks, not in the metadata. This is by design because dependency resolution happens at playbook parsing time, not at runtime.

Exam trap

The trap here is that candidates assume the 'dependencies' block in meta/main.yml supports a 'when' or 'condition' keyword similar to tasks, but Ansible explicitly does not allow conditional dependencies at the metadata level.

How to eliminate wrong answers

Option B is wrong because the 'condition' field does not exist in Ansible's role dependency syntax; the only supported fields are 'role', 'vars', 'tags', and 'when' is not valid in meta/main.yml. Option C is wrong because using 'when' in the role's tasks to include the dependency would require the dependency to be defined as a task-level include, not as a metadata dependency, and it would not honor the dependency ordering semantics. Option D is wrong because 'pre_tasks' is a playbook-level construct that runs before roles, but it cannot conditionally execute a role dependency defined in meta/main.yml; it would require duplicating the role logic outside the dependency system.

Practice this question →

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

AnswerB

Correct. If the inventory contains only one host, the playbook will run on that host and then finish, producing a PLAY RECAP with exactly one host. This is the most likely reason given the behavior described.

Why this answer

The `serial: 1` directive in Ansible limits concurrency to one host at a time, but the playbook will still process all hosts in the inventory. If the playbook stops after the first host and shows PLAY RECAP with only one host, the most likely reason is that the inventory contains only one host. With a single host, the play executes on that host and then finishes.

Option B accurately identifies this scenario.

Exam trap

In the Red Hat RHCE exam, examinees may overthink the behavior of 'serial' and forget to check the inventory size. The trap is assuming 'serial: 1' somehow stops the playbook, whereas the real cause is often a single-host inventory.

How to eliminate wrong answers

Option A is wrong because a `failed_when` condition would cause the playbook to fail on a specific task, but it would not stop the playbook after the first host unless combined with `any_errors_fatal` or `max_fail_percentage`; even then, the 'PLAY RECAP' would show the failed host, not just one host. Option B is wrong because if the inventory contained only one host, the playbook would still run and show a 'PLAY RECAP' with that single host, which is expected behavior, not a reason for stopping after the first host in a multi-host scenario. Option C is wrong because incorrect `delegate_to` usage might cause tasks to run on the wrong host or fail, but it would not cause the playbook to stop after the first host and show a 'PLAY RECAP' with only one host; it would either fail or complete on all hosts.

Practice this question →

MCQmedium

An engineer runs the playbook as shown: ```yaml - hosts: all tasks: - block: - name: configure firewall command: /bin/false - name: enable service service: name=httpd enabled=yes - name: start service service: name=httpd state=started - hosts: all tasks: - name: next task debug: msg="Continuing to next play" ``` 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

The playbook includes a block containing only the 'configure firewall' task. When this task fails and no rescue block is defined, the play fails immediately. The playbook then moves to the next play, skipping any remaining tasks in the current play, including the 'enable service' task.

Thus, 'configure firewall' is executed, 'enable service' is skipped, and the playbook continues to the next play.

Exam trap

The EX294 exam 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.

Practice this question →

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

In Ansible, when a task inside a `block` fails, the `rescue` section is executed to handle the failure. After the rescue tasks complete successfully, the play continues with the next task after the block, not from the beginning of the block. This behavior allows for error recovery without terminating the entire play.

Exam trap

The trap here is that candidates often confuse `rescue` with a retry mechanism, thinking it re-executes the block, or they assume that any failure in the block immediately fails the entire play, ignoring the rescue capability.

How to eliminate wrong answers

Option A is wrong because after the rescue tasks run, the play does not fail; it continues with the next task after the block, unless the rescue tasks themselves fail. Option C is wrong because the rescue tasks are not ignored; they are specifically designed to run when a task in the block fails, and the play does not fail immediately unless the rescue tasks also fail. Option D is wrong because the block is not re-executed after rescue; the rescue section runs once, and then execution proceeds to the task after the block.

Practice this question →

MCQhard

A playbook uses the 'include_tasks' module to load platform-specific tasks. The playbook fails intermittently with 'Could not find or access file' error on some runs but works on others. Which of the following is the most likely cause?

A.The 'include_tasks' is used inside a block that has 'always' section.

B.The task file path is not absolute and Ansible's search order is inconsistent.

C.The 'include_tasks' is used with a loop and the loop variable shadows the included file's parameter.

D.The playbook uses 'any_errors_fatal: true' causing early exits.

AnswerC

Correct: Variable shadowing can cause the included file's expected variable to be overridden, leading to file lookup failures on some iterations.

Why this answer

When 'include_tasks' is used inside a loop, the loop variable (e.g., 'item') can override or shadow the parameters expected by the included task file. This causes the included file to receive unexpected variable values, leading to incorrect file path resolution and intermittent 'Could not find or access file' errors depending on the loop iteration.

Exam trap

Red Hat often tests the subtle interaction between loop variables and included task file parameters, where candidates mistakenly attribute the intermittent failure to path resolution or error handling rather than variable shadowing.

How to eliminate wrong answers

Option A is wrong because the 'always' section in a block does not affect file path resolution; it only ensures certain tasks run regardless of failure. Option B is wrong because Ansible's search order for relative paths in 'include_tasks' is deterministic (relative to the playbook or role directory), not inconsistent, so this would not cause intermittent failures. Option D is wrong because 'any_errors_fatal: true' stops execution on any failure but does not cause file-not-found errors; it would make failures consistent, not intermittent.

Practice this question →

MCQhard

An Ansible playbook uses delegation to run a task on localhost while targeting remote hosts. The task fails with 'connection refused' for the remote host. What is the most likely cause?

A.the remote host is not reachable from the control node

B.the task uses 'connection: local' incorrectly or omits it

C.the playbook lacks 'gather_facts: yes'

D.the delegate host lacks required Python libraries

AnswerB

Correct: when delegating, the connection should be set to local unless using 'delegate_to' with proper connection vars.

Why this answer

'delegate_to: localhost' runs the task locally, but the connection keyword 'ansible_connection' may still refer to remote if not set correctly. Option A is plausible but less common. Options C and D are incorrect.

Practice this question →

Multi-Selectmedium

Which three of the following are valid methods to pass variables to an Ansible playbook at runtime? (Choose three.)

Select 3 answers

A.Using '--extra-vars' command line option.

B.Using '--ask-vault-pass' and storing variables in encrypted files.

C.Using 'environment' directive in the playbook.

D.Using 'vars_prompt' in the playbook.

E.Using '-e @file' to load variables from a JSON file.

AnswersA, D, E

Correct: This directly passes variables or file paths.

Why this answer

The `--extra-vars` (or `-e`) command-line option allows you to pass variables directly to an Ansible playbook at runtime. This overrides any previously defined variables and can accept key=value pairs or load from JSON/YAML files, making it the primary method for runtime variable injection.

Exam trap

The trap here is confusing variable injection methods with authentication or environment configuration; candidates often mistake `--ask-vault-pass` or `environment` for runtime variable passing, when they serve entirely different purposes in Ansible's architecture.

Practice this question →

Multi-Selecteasy

An administrator wants to ensure that Ansible facts gathered from a host are consistent across multiple playbook runs. Which two actions can help achieve this? (Choose two.)

Select 2 answers

A.Use 'gather_facts: no' and manually run 'setup' module with specific filter.

B.Use 'tags' to only gather facts on selective runs.

C.Enable fact caching using 'ansible_cache' plugin with a persistent backend like Redis.

D.Disable fact caching and gather facts every time.

E.Set 'ANSIBLE_GATHERING=smart' and configure cache_timeout.

AnswersC, E

Correct: Caching stores facts between runs, ensuring consistency.

Why this answer

Enabling fact caching with a persistent backend like Redis stores gathered facts between playbook runs, ensuring consistency without re-gathering. Option E is correct because setting 'ANSIBLE_GATHERING=smart' with a configured cache_timeout allows Ansible to reuse cached facts within the timeout period, providing consistent data across runs.

Exam trap

Red Hat often tests the distinction between controlling when facts are gathered (tags, gather_facts: no) versus ensuring consistency across runs (caching), leading candidates to pick options that limit fact collection but do not persist data between executions.

Practice this question →

MCQeasy

An administrator wants to reuse a set of tasks that configure a firewall across multiple playbooks. Which Ansible feature should be used to achieve this?

A.Create a role for firewall configuration.

B.Add the tasks to the inventory file under a group.

C.Define the tasks in a vars file and include it.

D.Define the tasks as handlers and notify them.

AnswerA

Roles are the standard way to package reusable content.

Why this answer

A role is the correct Ansible feature for reusing a set of tasks across multiple playbooks. Roles provide a structured, self-contained directory layout for tasks, handlers, variables, templates, and files, allowing the firewall configuration logic to be packaged once and referenced in any playbook via the `roles:` directive or `import_role`/`include_role` modules.

Exam trap

The trap here is confusing roles with other reusable components like variables or handlers, leading candidates to think that storing tasks in a vars file or using handlers can achieve the same cross-playbook reuse.

How to eliminate wrong answers

Option B is wrong because the inventory file defines hosts and groups, not reusable task logic; adding tasks to an inventory file is syntactically invalid and would not execute them. Option C is wrong because vars files store variables, not tasks; including a vars file with `include_vars` cannot run tasks. Option D is wrong because handlers are special tasks triggered by notifiers only when a change occurs, not designed for general-purpose reuse across playbooks.

Practice this question →

MCQeasy

Refer to the exhibit. What is the purpose of the 'failed_when' condition?

A.It fails the task only if the return code is non-zero and the error does not indicate 'not installed'.

B.It ensures the task never fails regardless of return code.

C.It fails the task only if the package is installed.

D.It fails the task if the package is not installed.

AnswerA

Correct: This is exactly what the condition defines.

Why this answer

The 'failed_when' condition in Ansible allows you to define custom failure criteria for a task. In the exhibit, the condition 'failed_when: result.rc != 0 and "not installed" not in result.stderr' means the task will only be marked as failed if the return code is non-zero AND the error message does not contain the string 'not installed'. This is useful when a command returns a non-zero exit code for expected reasons (e.g., package not found), and you want to treat that as a non-failure.

Exam trap

The trap here is that candidates assume 'failed_when' always causes failure when the condition is true, but they overlook that the condition is a logical AND of two parts, and the second part ('not installed' not in stderr) is a negative check that prevents failure when the expected error message appears.

How to eliminate wrong answers

Option B is wrong because 'failed_when' does not ensure the task never fails; it only defines custom failure conditions, and if the condition evaluates to false, the task may still fail based on the default behavior (non-zero return code). Option C is wrong because the condition does not check whether the package is installed; it checks the return code and the presence of 'not installed' in stderr, not the package installation status itself. Option D is wrong because the condition does not fail the task if the package is not installed; it actually prevents failure when the error indicates 'not installed', so it would not fail in that case.

Practice this question →

Multi-Selectmedium

Which THREE statements about Ansible roles are correct? (Select exactly 3)

Select 3 answers

A.A role can directly include tasks from another role using the `include_tasks` module.

B.Roles can have dependencies on other roles defined in `meta/main.yml`.

C.Roles have a predefined directory structure that includes `tasks`, `handlers`, `defaults`, `vars`, `meta`, `templates`, and `files`.

D.Variables defined in `defaults/main.yml` override those in `vars/main.yml`.

E.Roles cannot include playbooks.

AnswersB, C, E

Correct. Roles can define dependencies on other roles in `meta/main.yml` using the `dependencies` keyword.

Why this answer

Ansible roles can declare dependencies on other roles in their `meta/main.yml` file using the `dependencies` keyword. Option C is correct because roles have a predefined directory structure that includes `tasks`, `handlers`, `defaults`, `vars`, `meta`, `templates`, and `files`. Option E is correct because roles are designed for tasks and handlers, not playbooks; you cannot directly include a playbook within a role.

Options A and D are incorrect: A is wrong because to include tasks from another role you use `include_role`, not `include_tasks`; D is wrong because variables in `vars/main.yml` override those in `defaults/main.yml`.

Exam trap

A common trap is confusing `include_role` with `include_tasks`—`include_tasks` includes a tasks file from within the same role, not from another role. Another trap is thinking `defaults` override `vars`, when in fact `vars` has higher precedence. Also, many candidates mistakenly believe roles can include playbooks, but roles only contain tasks, handlers, and other role components.

Practice this question →

MCQhard

Refer to the exhibit. After the playbook run fails on the 'Verify config' task, what happens to the 'restart service' handler?

A.The handler runs immediately after the failed task.

B.The handler is not executed because the playbook failed before the end of the play.

C.The handler runs on the next playbook run.

D.The handler is executed because it was notified before the failure.

AnswerB

By default, handlers run at the end of the play only if all tasks succeed. If a task fails, the play aborts and handlers are not run.

Why this answer

Handlers are notified but only run at the end of the play if notified. However, if a subsequent task fails, the playbook stops, and handlers are not executed unless the 'force_handlers' option is set.

Practice this question →

MCQeasy

An automation engineer wants to run a playbook only on hosts that belong to both the 'webservers' group and the 'production' group. Which inventory grouping method achieves this?

A.webservers:&production

B.webservers:production

C.webservers:!production

D.webservers+,production

AnswerA

Ampersand specifies intersection of hosts in both groups.

Why this answer

In Ansible, the '&' operator is used to intersect groups. 'webservers:&production' targets hosts that are in both the 'webservers' and 'production' groups. Option B is wrong because 'webservers:production' uses ':' which is a union operator, meaning hosts in either group. Option C is wrong because 'webservers:!production' uses '!' to exclude hosts in production.

Option D is wrong because 'webservers+,production' is not a valid inventory pattern; Ansible does not support '+' for group intersection.

Practice this question →

MCQeasy

A developer reports that a role's behavior is not as expected. They set a variable in the playbook's vars section, but the role still uses the value from its vars/main.yml. Which of the following explains this issue?

A.vars defined in the playbook have higher precedence than those in roles/vars/main.yml

B.vars defined in group_vars override both play and role vars

C.the playbook must use include_vars after the role to override

D.vars defined in roles/vars/main.yml have higher precedence than those in the playbook's vars section

AnswerD

Correct: role vars override play vars.

Why this answer

In Ansible, variable precedence is hierarchical, and role defaults (roles/role_name/defaults/main.yml) have the lowest precedence, while role vars (roles/role_name/vars/main.yml) have a higher precedence than playbook-level vars. Since the developer set the variable in the playbook's vars section, but the role still uses the value from its vars/main.yml, this indicates that vars defined in roles/vars/main.yml override those in the playbook's vars section, making option D correct.

Exam trap

The trap here is that candidates often confuse role defaults (defaults/main.yml) with role vars (vars/main.yml), assuming both are easily overridden by playbook vars. In Red Hat Ansible Automation Platform, role vars have higher precedence than playbook vars, making them effectively 'hardcoded' unless overridden by even higher precedence sources like extra vars or set_facts.

How to eliminate wrong answers

Option A is wrong because vars defined in the playbook have lower precedence than those in roles/vars/main.yml, not higher. Option B is wrong because group_vars have a lower precedence than both play vars and role vars, so they cannot override both; in fact, role vars override group_vars. Option C is wrong because include_vars is used to load variables from a file at runtime, but it does not change the inherent precedence; the role's vars/main.yml would still take precedence over playbook vars regardless of when include_vars is used.

Practice this question →

MCQhard

An Ansible Tower/AWX job template uses a custom inventory script that dynamically queries an API. The script returns JSON including groups and hosts. Recently, the API started returning HTTP 500 errors intermittently, causing inventory sync failures. Which Ansible approach can make the inventory source more resilient?

A.Configure the inventory script to use the Ansible cache plugin with a timeout and fallback to cached data.

B.Wrap the inventory script invocation in a Jinja2 template with error handling.

C.Use the setup module to gather facts and store them locally as a fallback inventory.

D.Modify the inventory script to retry on failure and write results to a static file.

AnswerA

Cache can serve stale data if API fails.

Why this answer

The Ansible cache plugin can store the results of a dynamic inventory script and serve them when the API is unavailable. By configuring a timeout and fallback to cached data, the job template avoids failures during transient HTTP 500 errors, ensuring inventory sync resilience without modifying the script itself.

Exam trap

The trap here is that candidates may think modifying the script (Option D) is the only way to handle API failures, overlooking Ansible Tower/AWX's built-in caching mechanism that provides a cleaner, more maintainable solution without altering the script's code.

How to eliminate wrong answers

Option B is wrong because Jinja2 templates are used for data transformation and rendering, not for error handling or retry logic in inventory scripts; they cannot catch HTTP errors or implement fallback mechanisms. Option C is wrong because the setup module gathers facts from existing hosts, not from an API, and storing facts locally does not provide a fallback inventory source for dynamic inventory scripts that query an external API. Option D is wrong because modifying the inventory script to retry and write to a static file is a valid workaround but is not an Ansible approach; it bypasses Ansible's built-in caching and inventory management features, and the static file would not be automatically refreshed or integrated with Ansible's inventory lifecycle.

Practice this question →

MCQmedium

The playbook above fails with 'template source file not found' for the copy task. Which change should be made to fix it?

A.Use the 'template' module instead of 'copy' for .j2 files.

B.Add 'delegate_to: localhost' to copy the file from the control node.

C.Set 'backup: no' because backup creates additional files.

D.Set 'gather_facts: yes' to allow Ansible to locate the template.

AnswerA

Template module processes Jinja2 templates.

Why this answer

The 'copy' module does not render Jinja2 templates; it simply copies files as is. When using a .j2 file with the copy module, Ansible expects the source file to exist literally, but it looks for the template in the wrong location, causing the 'template source file not found' error. The 'template' module is designed to process .j2 files, applying variables and Jinja2 logic, and then copying the result to the remote host.

Therefore, replacing 'copy' with 'template' resolves the issue.

Practice this question →

MCQhard

A playbook uses the 'win_chocolatey' module to install software on Windows hosts. The playbook is idempotent for most packages, but one package consistently fails with 'The package is already installed' error despite being reinstalled each run. Which approach ensures true idempotency?

A.Change state=present to state=latest to ensure the module only updates if needed.

B.Use the 'force' option in win_chocolatey to allow reinstalling, and ignore the error.

C.Add a 'when' condition to skip the package if it is already installed based on a registered variable from the win_chocolatey module's results.

D.Use a win_shell task with a check command to detect installation, and conditionally run the win_chocolatey task only when absent.

AnswerD

Manual check ensures idempotent execution.

Why this answer

The win_chocolatey module's 'state=present' does not guarantee idempotency for all packages; some packages may not report their installed state correctly to Chocolatey, causing the module to attempt installation every run and fail with 'already installed'. By using a win_shell task with a check command (e.g., `choco list --local-only`) to detect installation and conditionally running the win_chocolatey task only when absent, you bypass the module's flawed state detection and achieve true idempotency.

Exam trap

The EX294 exam often tests the misconception that Ansible modules are inherently idempotent for all edge cases, but the trap here is that some modules (like win_chocolatey) depend on external tools' state reporting, which can be unreliable, requiring a manual pre-check to guarantee idempotency.

How to eliminate wrong answers

Option A is wrong because 'state=latest' forces an upgrade check on every run, which can still trigger the same error if the package is already at the latest version and Chocolatey's state reporting is broken. Option B is wrong because using 'force' ignores the error but does not prevent the unnecessary reinstall attempt, violating idempotency and potentially causing side effects like overwriting configuration files. Option C is wrong because the win_chocolatey module does not reliably register a variable indicating 'already installed' for packages with broken state detection; the module may still fail before registering a useful result, making the 'when' condition ineffective.

Practice this question →

MCQmedium

An organization uses separate network hops that require different SSH usernames for different inventory groups. Which Ansible configuration approach ensures each group uses the correct SSH user without duplicating playbooks?

A.Create a group_vars directory with a file named after the group containing ansible_user.

B.Specify the SSH user in the inventory file for each host.

C.Set the ansible_user variable in ansible.cfg.

D.Define ansible_user in the playbook using vars.

AnswerA

Group vars allow per-group variable values.

Why this answer

Creating a group_vars directory with a file named after a group and setting ansible_user inside it is the best practice for assigning different SSH users per group without duplicating playbooks. Option B is incorrect because specifying the SSH user in the inventory file for each host is possible but less scalable and harder to maintain. Option C is incorrect because setting ansible_user in ansible.cfg applies globally to all hosts, not per group.

Option D is incorrect because defining ansible_user in the playbook using vars would require editing the playbook for each group, which leads to duplication and is not scalable.

Practice this question →

MCQmedium

An Ansible playbook uses async and poll to run a long-running task. The task reports 'async task did not complete within the requested time'. Which of the following is the most likely cause?

A.the poll interval is set too long

B.the async timeout value is set too short for the task duration

C.the async task requires become: yes

D.the host is unreachable

AnswerB

Correct: the timeout must be greater than the expected task runtime.

Why this answer

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

Practice this question →

MCQhard

Refer to the exhibit. The playbook copies all .conf files from the control node to host1. If the playbook runs again on the same host without any changes, which task status is expected?

A.The task will fail because the destination directory already contains files.

B.All items will show 'ok' because files are identical.

C.The task will be skipped because the files already exist.

D.All items will show 'changed'.

AnswerB

The copy module uses checksums; if source and destination are the same, it reports 'ok'.

Why this answer

The copy module uses checksums to detect changes. If the files are identical, the task will report 'ok' (not 'changed'). However, the with_fileglob lookup runs on the control node and will always return the same list.

The copy module will compare each file and report 'ok' if unchanged.

Practice this question →

MCQmedium

A playbook uses a loop over a list of packages to ensure they are installed. However, the playbook runs slowly because each package is processed individually. Which optimization technique should be used to improve performance?

A.Pass the entire list to the package module's 'name' parameter instead of looping.

B.Use with_items instead of loop; with_items is faster.

C.Set the async parameter on the looped task to run packages in parallel.

D.Use the serial keyword at the play level to increase parallelism.

AnswerA

Many package modules accept a list, reducing task overhead.

Why this answer

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

Exam trap

The trap here is that candidates often confuse task-level parallelism (which Ansible does not natively support for loops) with host-level parallelism (controlled by 'serial' or 'strategy'), leading them to select options that seem to increase parallelism but do not apply to a single-host loop.

How to eliminate wrong answers

Option B is wrong because 'with_items' is a legacy loop syntax that is functionally equivalent to 'loop' and does not provide any performance advantage; both still execute the task once per item. Option C is wrong because setting 'async' on a looped task does not run packages in parallel; it only allows the task to run in the background with polling, but each iteration still runs sequentially. Option D is wrong because the 'serial' keyword controls the number of hosts processed at a time in a play, not the parallelism of tasks within a single host; it does not affect how a loop over packages is executed on a given host.

Practice this question →

MCQmedium

A DevOps team is developing a collection of Ansible roles to standardize web server deployments. One role, 'webserver-base', configures the firewall and installs common packages. Another role, 'webserver-app', depends on 'webserver-base' and adds application-specific configurations. The team wants to ensure that when 'webserver-app' is applied to a host, 'webserver-base' is automatically applied first. They currently have a 'meta/main.yml' file in 'webserver-app' that lists 'webserver-base' as a dependency. However, when they run a playbook that includes 'webserver-app' in a role list, they notice that 'webserver-base' runs after 'webserver-app' sometimes, causing configuration conflicts. They verify that the dependency is correctly defined and that no other roles are involved. What change should they make to ensure 'webserver-base' always runs before 'webserver-app'?

A.Change the dependency type to 'include_role' in the playbook to control ordering.

B.Set 'static: yes' in the dependency entry in the dependent role's meta/main.yml.

C.Add 'order: before' to the dependency entry in meta/main.yml.

D.Add a 'pre_tasks' section in the playbook to include 'webserver-base' before 'webserver-app'.

AnswerB

This forces the dependency to be resolved statically, ensuring correct order.

Why this answer

By default, role dependencies are executed before the dependent role. However, when roles are included dynamically (e.g., via `include_role`), the order may not be guaranteed. Setting `static: yes` in the dependency entry in `meta/main.yml` forces Ansible to statically inline the dependency at playbook parse time, ensuring that `webserver-base` always runs before `webserver-app`.

Option B is correct because it directly addresses the ordering issue by making the dependency static. Option A is incorrect because `include_role` is a dynamic inclusion module, not a dependency type. Option C is incorrect because `order` is not a valid attribute for dependencies.

Option D is a playbook-level workaround but does not enforce the dependency when the role is used elsewhere.

Practice this question →

MCQmedium

An Ansible playbook sets a variable with a dictionary value in the play's vars and also in group_vars/all. When the play runs, the dictionary in group_vars completely replaces the one in play vars. What is the most likely reason?

A.the playbook uses 'set_fact' which overrides all other vars

B.the play vars dictionary is defined with incorrect YAML syntax

C.the group_vars file uses a different variable name

D.Ansible's default variable precedence uses replacement, not merging, for dictionaries

AnswerD

Correct: unless 'hash_behaviour=merge' is set, later sources replace earlier ones.

Why this answer

Ansible's default variable precedence treats dictionaries as atomic values: when a dictionary variable is defined at a higher precedence level (like group_vars), it completely replaces the same variable defined at a lower precedence level (like play vars). Ansible does not merge dictionaries by default; the `hash_behaviour` setting, which controls merging, defaults to `replace`. Option A is incorrect because `set_fact` has a higher precedence than group_vars, but the question describes group_vars replacing play vars, which is normal precedence behavior, not set_fact.

Option B is incorrect because YAML syntax is not the issue; even with correct syntax, replacement occurs. Option C is incorrect because the same variable name is used, leading to replacement rather than merging.

Practice this question →

Multi-Selecthard

Which TWO of the following are correct about Ansible Vault?

Select 2 answers

A.vault encryption is irreversible

B.vault encrypted files cannot be edited in place

C.the vault password can be provided via the '--vault-password-file' option

D.vault can encrypt only specific variable values within a file

E.the vault id can be specified to use multiple vault passwords

AnswersC, E

Correct: this is a common way to automate vault decryption.

Why this answer

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

Exam trap

In the RHCE exam, candidates often assume vault encryption is irreversible or that it can encrypt only specific values within a file, confusing it with `ansible-vault encrypt_string` which encrypts a single string, not partial file encryption.

Practice this question →

Multi-Selecthard

An Ansible playbook repeatedly uses the same pattern: check if a service is running, if not start it, and then verify it's running. Which three Ansible features can be used to reduce code duplication? (Choose three.)

Select 2 answers

A.Using 'include_vars' to reuse variable files.

B.Using a role with multiple tasks and handlers.

C.Using 'debug' module to output the status.

D.Creating a custom filter plugin to encapsulate the logic.

E.Using 'include_tasks' with a loop to include a common task file.

AnswersB, E

Correct. A role groups tasks, handlers, and variables into a reusable structure. Handlers can start services only when notified, effectively reducing repetition.

Why this answer

Options B and E are correct because roles (with tasks and handlers) and include_tasks with loops are the proper mechanisms for reusing task patterns in Ansible. Option D is incorrect: custom filter plugins are used for data transformation in templates, not for encapsulating task execution logic. include_vars (A) only reuses variables, and debug (C) only outputs messages; neither reduces code duplication for the described check-start-verify pattern.

Exam trap

The trap is that candidates may consider custom plugins or filters (like filter plugins) as a way to encapsulate task logic, but in Ansible, only roles, task includes, and imports are designed for reusing task execution patterns. Filter plugins are exclusively for template data manipulation.

Practice this question →

MCQmedium

A playbook uses the 'block' and 'rescue' keywords to handle errors. The block contains three tasks. The first task fails. What happens next?

A.The rescue section runs and retries the failed task.

B.The rescue section runs immediately after the failure.

C.The playbook fails with an error message.

D.The remaining tasks in the block run, then the rescue section runs.

AnswerB

Rescue is executed when any task in the block fails.

Why this answer

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

Exam trap

The trap here is that candidates often confuse `block`/`rescue` with a simple retry mechanism or assume that all tasks in the block must complete before error handling, but Ansible's behavior is to immediately jump to rescue on the first failure.

How to eliminate wrong answers

Option A is wrong because the rescue section does not retry the failed task; it runs a separate set of tasks to handle the error, and retry logic would require a `until` loop or `retries` parameter on the task itself. Option C is wrong because the playbook does not fail immediately; the rescue section is designed to catch the error and continue execution, preventing a playbook failure unless the rescue itself fails. Option D is wrong because the remaining tasks in the block are skipped once a task fails; the rescue runs immediately, not after the block completes.

Practice this question →

Multi-Selectmedium

Which THREE of the following are valid attributes of the ansible.builtin.service module?

Select 3 answers

A.state

B.enabled

C.pattern

D.name

E.runlevel

AnswersA, B, D

Correct: state controls whether the service is started/stopped.

Why this answer

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

Exam trap

The trap here is that candidates confuse module-specific parameters (like `pattern` for `systemd` or `runlevel` for legacy init scripts) with the generic `service` module, which only supports `state`, `enabled`, `name`, and a few others like `arguments` and `use`.

Practice this question →

Multi-Selecteasy

Which two statements about Ansible roles are correct? (Select exactly 2.)

Select 2 answers

A.Roles must have a meta/main.yml file.

B.Roles are a type of playbook.

C.Roles can include tasks, handlers, variables, and defaults.

D.Roles cannot be used with include_role.

E.Roles can be installed from Galaxy.

AnswersC, E

Roles have a standard directory structure for these components.

Why this answer

Options C and E are correct. Roles can contain tasks, handlers, variables, and defaults (C). Roles can be installed from Ansible Galaxy (E).

Option A is incorrect because the meta/main.yml file is optional, not mandatory. Option B is incorrect because roles are not a type of playbook; they are a way to organize playbook content. Option D is incorrect because roles can be used with include_role or import_role.

Exam trap

A common trap is assuming that meta/main.yml is required for all roles. While it is often used for dependencies and metadata, it is optional. Another trap is thinking that roles cannot be used dynamically (e.g., with include_role), but they can.

Practice this question →

MCQmedium

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?

A.Set `max_fail_percentage` in the play to 0 and use `ignore_errors: yes` with a rescue block.

B.Use the `throttle` keyword to limit concurrent tasks and rely on idempotency.

C.Set `serial: 1` on the play to ensure only one host is processed at a time and rely on idempotency.

D.Use the `until` loop with `retries` and `delay` parameters on the task.

AnswerD

The `until` loop with `retries` and `delay` retries the task until a condition is met or retries are exhausted, ideal for transient failures.

Why this answer

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

Exam trap

The trap here is that candidates confuse concurrency controls (`serial`, `throttle`) or error-handling directives (`ignore_errors`, `max_fail_percentage`) with the retry mechanism, which is specifically implemented via the `until` loop with `retries` and `delay` parameters.

How to eliminate wrong answers

Option A is wrong because `max_fail_percentage` controls the percentage of hosts that can fail before the play aborts, not task retries; combining `ignore_errors: yes` with a rescue block would suppress errors but not implement retry logic. Option B is wrong because the `throttle` keyword limits the number of concurrent task executions, which is unrelated to retrying failed tasks. Option C is wrong because `serial: 1` processes hosts one at a time to control rolling updates or concurrency, not to retry tasks on failure.

Practice this question →

MCQhard

A playbook uses an Ansible collection that includes a custom module. The module's documentation is missing. What is the best way to locate the module's source code?

A.Run ansible-doc <module name>.

B.Search the Ansible Galaxy website.

C.Navigate to the collection's plugin directory on the control node.

D.Look in the roles directory.

AnswerC

Source code is in the collection's modules subdirectory.

Why this answer

The source code for custom modules in an Ansible collection is located in the collection's plugin directory on the control node. Option A is not the best choice because `ansible-doc` relies on documentation strings; if the module's documentation is missing, it may not provide useful information. Option B is incorrect because the Ansible Galaxy website hosts collections but does not necessarily provide direct access to source code without documentation.

Option D is wrong because the roles directory contains roles, not module plugins.

Practice this question →

MCQeasy

An administrator wants to reuse a set of tasks across multiple playbooks. Which Ansible approach is most appropriate?

A.Encrypting the tasks with Ansible Vault.

B.Creating a role with tasks in tasks/main.yml.

C.Using ansible-doc to document the tasks.

D.Writing a custom module in Python.

AnswerB

Correct: Roles encapsulate tasks, variables, handlers, and are designed for reuse across playbooks.

Why this answer

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

Exam trap

The trap here is that candidates may confuse Ansible Vault's encryption capability with code reuse, or think that writing a custom module is a simpler way to bundle tasks, when in fact roles are the explicit, built-in solution for task reuse in Ansible.

How to eliminate wrong answers

Option A is wrong because Ansible Vault encrypts sensitive data (e.g., passwords, keys) but does not provide a mechanism to reuse tasks across playbooks; it is a security feature, not a code reuse feature. Option C is wrong because `ansible-doc` is a command-line tool that displays documentation for installed modules and plugins; it does not enable task reuse or packaging. Option D is wrong because writing a custom Python module extends Ansible's capabilities with new, atomic actions, but it is not the intended or most appropriate way to reuse a set of tasks; roles are designed specifically for that purpose.

Practice this question →

Matchingmedium

Match each Ansible fact variable to its description.

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

Concepts

Matches

Fully qualified domain name

OS family (e.g., RedHat)

Total memory in MB

Number of CPU cores

Default IPv4 interface info

Why these pairings

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

Practice this question →

MCQeasy

Refer to the exhibit. An administrator wants to view the decrypted value of 'db_password' without modifying the file. Which command should be used?

A.ansible-vault rekey file.yml

B.ansible-vault decrypt file.yml

C.ansible-vault view file.yml

D.ansible-vault edit file.yml

AnswerC

Correct: view displays decrypted content to stdout.

Why this answer

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

Exam trap

The trap here is that candidates often confuse `ansible-vault view` with `ansible-vault decrypt`, mistakenly thinking they must permanently decrypt the file to see its contents, when `view` provides a read-only decrypted output without altering the file.

How to eliminate wrong answers

Option A is wrong because `ansible-vault rekey` changes the vault password used to encrypt the file, not decrypt or display its contents. Option B is wrong because `ansible-vault decrypt` permanently decrypts the file and writes the plaintext to disk, which modifies the file. Option D is wrong because `ansible-vault edit` decrypts the file, opens it in an editor, and re-encrypts it upon saving, which modifies the file even if no changes are made.

Practice this question →

MCQeasy

An Ansible playbook uses the lineinfile module to ensure a specific line is present in a configuration file. However, after running the playbook multiple times, the line is duplicated each time. Which option best explains this behavior?

A.The lineinfile module is missing the regexp parameter, so it adds the line every run.

B.The state parameter is set to 'append' instead of 'present'.

C.The backup parameter is not set, causing file corruption.

D.The insertafter parameter is incorrectly set to EOF, causing multiple adds.

AnswerA

Without a regexp, lineinfile cannot detect existing line, so it appends each time.

Why this answer

The lineinfile module without a regexp parameter cannot identify an existing line to match, so it adds the line every time the playbook runs, causing duplicates. Option B is incorrect because 'append' is not a valid state for lineinfile; valid states are 'present' (default) and 'absent'. Option C is incorrect because the backup parameter only creates a backup file and does not affect line duplication.

Option D is incorrect because insertafter=EOF would place the line at the end of the file, but without a regexp, the module still cannot detect an existing matching line and will add it each run.

Practice this question →

MCQhard

Refer to the exhibit. A playbook targeting the 'webservers' group uses '{{ http_port }}'. What will be the value of 'http_port' on 'web2'?

A.8080

B.80

C.80, because the group variable overrides host variable.

D.Undefined, causing an error

AnswerA

Correct: Host variable http_port=8080 overrides the group variable.

Why this answer

In Ansible, host variables take precedence over group variables. The inventory defines 'web2' with 'http_port: 8080' as a host variable, while the 'webservers' group defines 'http_port: 80' as a group variable. Since host variables override group variables, the value of 'http_port' on 'web2' is 8080.

Exam trap

The trap here is that candidates may confuse Ansible's variable precedence and incorrectly think group variables override host variables, leading them to choose the group default value '80' instead of the host-specific value '8080'.

How to eliminate wrong answers

Option B is wrong because it assumes the group variable value '80' is used, but host variables override group variables in Ansible's variable precedence. Option C is wrong because it incorrectly states that the group variable overrides the host variable; in reality, host variables have higher precedence than group variables. Option D is wrong because 'http_port' is defined both as a host variable for 'web2' and as a group variable for 'webservers', so it is not undefined and will not cause an error.

Practice this question →

Multi-Selecteasy

Which TWO statements about Ansible roles are correct?

Select 2 answers

A.Ansible roles follow a predefined directory structure.

B.Roles enforce an execution order for tasks based on file naming.

C.A role can only be included once in a playbook.

D.Roles cannot have dependencies on other roles.

E.Roles can be downloaded from Ansible Galaxy.

AnswersA, E

Roles require a specific directory layout (tasks, handlers, etc.).

Why this answer

Ansible roles enforce a predefined directory structure (e.g., tasks/, handlers/, vars/, defaults/, meta/, templates/, files/) that organizes automation content into reusable components. This structure is required for Ansible to automatically locate and load role resources, making option A correct.

Exam trap

The trap here is that candidates confuse the static file-based ordering of tasks within a role (which is sequential in main.yml) with a non-existent naming convention, leading them to incorrectly select option B.

Practice this question →

Multi-Selecthard

Which THREE of the following are valid uses of the 'ansible.builtin.include_role' module?

Select 3 answers

A.Pass variables to the included role using the 'vars' keyword.

B.Include a role from a collection by specifying 'namespace.collection.role_name'.

C.Dynamically set the role name using a variable without the 'name' parameter.

D.Conditionally include a role based on a variable.

E.Apply tags to all tasks within the included role.

AnswersA, B, D

Variables can be passed to the role via the 'vars' parameter.

Why this answer

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

Exam trap

The trap here is that candidates often confuse 'include_role' with 'import_role', assuming that tags applied to the include statement will automatically apply to all tasks inside the role, but in Ansible, tags on a dynamic include only affect the include task itself, not the included tasks.

Practice this question →

MCQeasy

An administrator needs to securely store a database password used across multiple roles in a shared repository. Which approach is recommended?

A.Use ansible-vault to encrypt the password string and store it in a file, then include_vars.

B.Use a lookup plugin to fetch from a secrets manager.

C.Store the password in an environment variable on the controller.

D.Hardcode the password in the playbook and use .gitignore.

AnswerA

ansible-vault is the standard way to encrypt sensitive data.

Why this answer

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

Exam trap

The trap here is that candidates may confuse 'secure storage in a repository' with external secrets managers (Option B), but the question explicitly limits the context to a shared repository, making ansible-vault the correct built-in solution.

How to eliminate wrong answers

Option B is wrong because while a lookup plugin to fetch from a secrets manager is a valid approach, the question specifies a 'shared repository' (e.g., Git), not an external secrets management service; the recommended approach for repository-based storage is ansible-vault. Option C is wrong because storing the password in an environment variable on the controller is insecure—environment variables can be leaked via process listings, logs, or debugging tools, and they are not encrypted at rest. Option D is wrong because hardcoding the password in the playbook and using .gitignore does not prevent the password from being visible in the playbook file itself, and .gitignore only prevents accidental commits, not exposure to anyone with access to the file system.

Practice this question →

MCQmedium

You have an Ansible playbook that uses the 'lineinfile' module to manage the /etc/ssh/sshd_config file. The playbook runs without errors, but after execution, the SSH service becomes unreachable on some hosts. Investigation reveals that the file contains duplicate lines for 'Port 22' and 'PermitRootLogin no'. The playbook uses the following task: - name: Ensure SSH settings ansible.builtin.lineinfile: path: /etc/ssh/sshd_config regexp: "^{{ item.key }}" line: "{{ item.key }} {{ item.value }}" loop: - { key: 'Port', value: '22' } - { key: 'PermitRootLogin', value: 'no' } The playbook is run multiple times. What is the most likely cause of the duplicate lines?

A.The regexp pattern does not match the existing lines exactly, causing new lines to be added instead of replacing.

B.The 'lineinfile' module is not idempotent when used with loops.

C.The loop should use 'with_items' instead of 'loop' for proper idempotence.

D.The 'line' parameter should use backreferences to avoid duplication.

AnswerA

If the line has leading spaces or is not at the start, it may not match.

Why this answer

The regexp pattern `^{{ item.key }}` matches only the start of a line (e.g., `^Port` or `^PermitRootLogin`), but the existing lines in `/etc/ssh/sshd_config` may have leading spaces or tabs (common in SSH config files). Since the regex does not match the actual line due to whitespace, the `lineinfile` module inserts a new line instead of replacing the existing one. Each playbook run adds another duplicate, eventually causing SSH to fail due to conflicting directives.

Exam trap

The trap here is that candidates assume `regexp` with `^` will match any line starting with the key, but they overlook that SSH config files often have leading whitespace, causing the module to add duplicate lines instead of replacing.

How to eliminate wrong answers

Option B is wrong because the `lineinfile` module is inherently idempotent when used correctly; the issue is not with loops but with the regexp pattern failing to match. Option C is wrong because `loop` and `with_items` are functionally equivalent in modern Ansible (both are converted to the same internal structure), so switching to `with_items` would not fix the regexp mismatch. Option D is wrong because backreferences are used in `regexp` to capture and reuse parts of the matched line, but the problem here is that the regexp does not match at all due to whitespace; backreferences would not help if the pattern fails to match.

Practice this question →

MCQhard

Refer to the exhibit. The playbook fails with an error about the package list. What is the issue?

A.The variable 'packages' is not accessible because it is defined in a vars_file.

B.The variable 'packages' is being converted to a string by the Jinja2 template, resulting in a list literal string.

C.The 'yum' module requires the 'name' parameter to be a comma-separated string, not a list.

D.The 'yum' module should use 'pkg' instead of 'name'.

AnswerB

Using "{{ packages }}" produces a string representation of the list. The correct approach is to use `name: "{{ item }}"` with a loop or pass the list directly without quotes.

Why this answer

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

Practice this question →

Multi-Selectmedium

Which three methods can be used to pass variables to an Ansible playbook? (Select exactly 3.)

Select 3 answers

A.In the ansible.cfg file.

B.In the role's vars/main.yml.

C.In the playbook's vars_files directive.

D.In the inventory file variables.

E.Using the --extra-vars command line option.

AnswersC, D, E

vars_files includes YAML/JSON files with variables.

Why this answer

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

Exam trap

The trap here is that candidates often confuse role-level variable files (like `vars/main.yml`) with playbook-level variable passing methods, or mistakenly think that `ansible.cfg` can hold variables, when in fact it only holds configuration directives.

Practice this question →

MCQhard

A playbook uses the 'include_tasks' module to dynamically include tasks based on a variable. The playbook runs successfully on some hosts but fails on others with a 'template error' message. What is the most likely cause?

A.The included task file does not exist on the control node.

B.The variable used in the 'include_tasks' path has a Jinja2 template error.

C.The included task file has incorrect permissions.

D.The included tasks contain a syntax error.

AnswerB

Template errors occur when Jinja2 syntax is invalid.

Why this answer

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

Exam trap

The trap here is that candidates often confuse the source of the template error, assuming it comes from the content of the included tasks (option D) rather than from the variable used in the include path itself, which is evaluated before the included file is even accessed.

How to eliminate wrong answers

Option A is wrong because if the included task file does not exist on the control node, Ansible would produce a 'file not found' or 'could not find or access' error, not a 'template error'. Option C is wrong because file permissions on the control node affect whether Ansible can read the file, but a permissions issue would result in a 'permission denied' error, not a Jinja2 template error. Option D is wrong because a syntax error inside the included tasks would cause a playbook failure when those tasks are parsed or executed, but the error message would be a YAML or Ansible syntax error, not a 'template error' from the include path resolution.

Practice this question →

MCQmedium

An organization uses Ansible to manage an AWS EC2 environment. The Ansible control node runs on a Linux server, and the team uses a dynamic inventory script (ec2.py) to automatically populate hosts. Recently, they need to run a playbook only against EC2 instances that have a specific tag, 'Environment', set to 'production'. The team has placed the ec2.ini configuration file in the same directory as the inventory script. However, when they run the playbook with '-i ec2.py', the playbook runs against all instances instead of only production ones. The team verifies that the tag exists on the correct instances and that the environment variable AWS_PROFILE is set correctly. Which action should resolve the issue?

A.Set the environment variable 'EC2_TAGS=Environment=production' before running the playbook.

B.Modify the ec2.ini file to include 'filters = tag:Environment=production' under the [ec2] section.

C.Use the '--limit' option with the playbook command to specify the tag.

D.Add the option 'hostname = tag_Name' to the ec2.ini file.

AnswerB

This restricts the inventory to instances with the specified tag.

Why this answer

The ec2.py dynamic inventory script uses ec2.ini settings to filter instances. To filter by tags, the 'regions_exclude' and 'destination_variable' are set, but the 'filters' setting inside the 'ec2' section must be configured to include 'tag:Environment=production'. Option B correctly identifies that the ec2.ini must be modified with the 'filters' option.

Option A is incorrect because 'hostname' is for naming hosts, not filtering. Option C would not filter by the tag. Option D is unrelated.

Practice this question →

MCQeasy

An Ansible playbook uses a 'block' to group multiple tasks and includes a 'rescue' section. If a task inside the block fails, what will happen?

A.the rescue section runs and then the playbook resumes with the next task after the block

B.the block is re-executed from the beginning

C.the rescue section runs, and the playbook continues with tasks after the block

D.the playbook stops immediately

AnswerC

Correct: rescue handles failures and then execution continues after the block.

Why this answer

In Ansible, a 'block' groups tasks, and a 'rescue' section defines tasks to run if any task in the block fails. When a task inside the block fails, the rescue section executes, and then the playbook continues with the next task after the block. Option C correctly describes this behavior.

Option A is incorrect because the rescue does run, but the playbook continues after the block, not just with the next task. Option B is incorrect because the block is not re-executed. Option D is incorrect because the playbook does not stop; it continues after the rescue.

Practice this question →

Multi-Selectmedium

Which TWO statements about Ansible collections are correct?

Select 2 answers

A.Collections cannot be versioned.

B.Collections provide a way to package and distribute Ansible content.

C.Collections replace the need for inventory files.

D.Collections can only contain modules and roles.

E.Collections can be published to Ansible Galaxy or Automation Hub.

AnswersB, E

Collections are the standard packaging format.

Why this answer

Ansible collections are a distribution format for Ansible content that allows packaging and distributing playbooks, roles, modules, and plugins. They enable users to bundle related automation content into a single, versioned package that can be shared via Ansible Galaxy or Automation Hub. This makes option B correct because collections are explicitly designed for packaging and distribution.

Exam trap

Red Hat often tests the misconception that collections are limited to modules and roles, but the trap here is that collections can also include plugins, playbooks, and documentation, making option D a common distractor.

Practice this question →

MCQeasy

Given the inventory above, which user will Ansible use when connecting to 'web2'?

A.dbadmin

B.The system default user from ansible.cfg.

C.deploy

D.root

AnswerC

webservers group sets ansible_user=deploy.

Why this answer

The group vars for webservers set ansible_user=deploy. Option A is wrong because host vars are not set. Option B is wrong because root is default only if not set.

Option D is wrong because dbadmin is for dbservers.

Practice this question →

MCQhard

A company has a large infrastructure with over 1000 servers. They run a playbook that configures NTP on all servers. The playbook takes over 30 minutes due to sequential execution. The team wants to reduce execution time. Which approach should they take?

A.Use serial: 10 to batch hosts.

B.Set forks: 50 and strategy: free.

C.Use include_tasks to parallelize tasks.

D.Use ansible-pull on each server.

AnswerB

More forks increase concurrent hosts; free strategy removes batching.

Why this answer

Increasing forks and using free strategy maximizes parallelism. Option A (serial) still processes batches sequentially. Option C (ansible-pull) shifts the workload but may not be faster.

Option D (include_tasks) does not affect parallelism.

Practice this question →