Courseiva

CCNA Manage task execution and roles Questions

68 questions · Manage task execution and roles · All types, answers revealed

Practice these questionsDomain overviewAll questions
1
MCQmedium

An Ansible playbook includes multiple roles. The administrator wants to ensure that a specific role's tasks are executed before any other roles, even if the roles are listed in a different order in the playbook. Which approach should be used?

A.Use the 'any_errors_fatal' setting.
B.Use role dependencies with 'allow_duplicates: no'.
C.Set the 'order' parameter in the role definition.
D.Use the 'pre_tasks' section in the playbook to call the role.
AnswerD

pre_tasks run before any roles, guaranteeing execution order.

Why this answer

The 'pre_tasks' section in an Ansible playbook runs before any roles listed in the 'roles' section, regardless of the order in which roles are defined. This allows the administrator to execute a specific role's tasks first by calling it within 'pre_tasks', ensuring it runs before all other roles.

Exam trap

The trap here is that candidates may think role ordering can be controlled via a parameter within the role definition itself, but Ansible relies on the playbook section order ('pre_tasks', 'roles', 'post_tasks') to enforce execution sequence.

How to eliminate wrong answers

Option A is wrong because 'any_errors_fatal' is a play-level keyword that stops execution on any task failure, not a mechanism to control task ordering. Option B is wrong because role dependencies with 'allow_duplicates: no' control whether a role can be included multiple times, not the execution order relative to other roles. Option C is wrong because there is no 'order' parameter in a role definition; Ansible roles do not support a built-in ordering parameter.

Practice this question →
2
MCQhard

Refer to the exhibit. The administrator observes the output and is concerned because the 'Check on async job' task shows 'finished: 0'. What does this indicate?

A.The async job was not started.
B.The async job failed.
C.The async job has completed successfully.
D.The async job is still running.
AnswerD

finished: 0 means the job is still in progress.

Why this answer

In the context of ansible async jobs, 'finished: 0' indicates that the job has not completed yet and is still running. A value of '1' would mean the job finished. Therefore, the administrator's concern that the job shows 'finished: 0' is correct because it means the task is still in progress.

Practice this question →
3
MCQhard

An administrator is designing a role that needs to execute a set of tasks conditionally based on whether a package is installed. Which approach is best practice?

A.Use the stat module to check package file existence
B.Use the command module to check package status
C.Use ansible_facts.packages
D.Use the package_facts module
AnswerD

package_facts gathers installed package information and is designed for this purpose.

Why this answer

The `package_facts` module is the best practice for gathering package installation status in Ansible. It populates the `ansible_facts.packages` variable with structured data about installed packages, allowing you to conditionally execute tasks using `when` statements without relying on external commands or file checks. This approach is idempotent, efficient, and aligns with Ansible's declarative philosophy.

Exam trap

The trap here is that candidates confuse `ansible_facts.packages` (which is a variable that must be populated by `package_facts`) with a pre-existing fact, leading them to choose option C without realizing the module is required first.

How to eliminate wrong answers

Option A is wrong because the `stat` module checks file existence, not package installation status; a package may be installed without its files in a predictable location, or files may exist from a different source. Option B is wrong because the `command` module is not idempotent and requires parsing command output (e.g., `rpm -q`), which is fragile, platform-specific, and violates Ansible's best practices of using dedicated modules. Option C is wrong because `ansible_facts.packages` is not automatically populated; it is only available after running the `package_facts` module or if the `gather_subset` includes `packages`, which is not the default and not a direct method to check package status.

Practice this question →
4
MCQmedium

Refer to the exhibit. A role 'timezone' sets the timezone twice to different values. The role also depends on 'ntp'. After running a playbook that applies this role to server1, what is the timezone on server1?

A.The timezone is not set because of the dependency on ntp.
B.UTC
C.America/New_York
D.An error occurs because two tasks set the timezone.
AnswerC

The last task sets the timezone to America/New_York.

Practice this question →
5
MCQhard

Refer to the exhibit. A playbook uses the 'webserver' role. The administrator runs the playbook and notices that the firewall configuration is not applied as expected. What is the most likely cause?

A.The handler is not triggered because the task uses 'notify' but the handler is in a different role.
B.The handler is not included in the role because handlers/main.yml is not automatically loaded.
C.The 'permanent: yes' option requires a reload of firewalld, but the handler restarts the service instead of reloading it.
D.The handler name 'restart firewalld' does not match the notification 'restart firewalld'.
AnswerC

For permanent firewall changes, firewalld needs to be reloaded (firewalld reload), not restarted, to apply changes immediately.

Practice this question →
6
MCQmedium

A team is writing an Ansible role to configure a web server. They want to include default variables that can be easily overridden by playbook variables. Which directory and file should they use to define these variables?

A.vars/defaults.yml
B.defaults/main.yml
C.default_vars/main.yml
D.vars/main.yml
AnswerB

This file contains variables with the lowest precedence, allowing easy override.

Why this answer

In Ansible roles, default variables are defined in the `defaults/main.yml` file. These variables have the lowest precedence, meaning they can be easily overridden by playbook variables, inventory variables, or any other variable source with higher precedence. This design allows role authors to provide sensible defaults while giving users the flexibility to customize behavior without modifying the role itself.

Exam trap

The trap here is that candidates confuse the `defaults/` directory (lowest precedence) with the `vars/` directory (higher precedence), or they invent non-standard directory names like `default_vars/`, because the exam tests precise knowledge of the Ansible role directory structure and variable precedence rules.

How to eliminate wrong answers

Option A is wrong because `vars/defaults.yml` is not a standard Ansible role directory structure; Ansible expects default variables in a `defaults` directory, not a `vars` directory. Option C is wrong because `default_vars/main.yml` uses an incorrect directory name; the correct directory is `defaults`, not `default_vars`. Option D is wrong because `vars/main.yml` is used for role variables that have higher precedence and are not intended to be easily overridden by playbook variables; placing defaults in `vars/` would make them harder to override, defeating the purpose of easily overridable defaults.

Practice this question →
7
MCQmedium

An administrator wants to run a playbook that executes tasks in parallel across multiple hosts but wants to limit the number of simultaneous hosts to 5. Which directive should be set?

A.poll
B.serial
C.throttle
D.forks
AnswerB

serial: 5 limits the batch of hosts to 5 at a time.

Why this answer

The `serial` directive in Ansible controls the number of hosts that execute a play at a time, allowing you to limit concurrency. Setting `serial: 5` ensures that only 5 hosts run tasks simultaneously, with the playbook completing in batches of 5 until all hosts are processed.

Exam trap

The trap here is confusing `forks` (which controls connection parallelism) with `serial` (which controls play-level batch execution), leading candidates to incorrectly choose `forks` when they need to limit simultaneous host execution per play.

How to eliminate wrong answers

Option A is wrong because `poll` is used with asynchronous tasks to set the interval for checking job status, not to limit simultaneous host execution. Option C is wrong because `throttle` limits the number of concurrent task executions per task or block, but it does not control the batch size of hosts across an entire play; it applies at a finer granularity. Option D is wrong because `forks` defines the maximum number of parallel connections Ansible makes to hosts, but it does not enforce a strict batch limit; with `forks` set to 5, Ansible could still start tasks on more than 5 hosts if the play has multiple tasks, as it controls parallelism at the connection level, not the play-level batch size.

Practice this question →
8
MCQhard

Refer to the exhibit. An administrator runs the playbook but the wait_for task fails. What is the most likely cause?

A.The ansible_facts variable may not be available because fact gathering is disabled.
B.The http_port variable is misspelled.
C.The wait_for module requires the 'port' parameter to be an integer.
D.The delegate_to should be set to the remote host.
AnswerA

Correct: without gather_facts: yes, ansible_facts is empty.

Why this answer

The playbook uses `ansible_facts['ansible_tcpip_socket']['port']` to supply the port number to the `wait_for` module. If fact gathering is disabled (e.g., via `gather_facts: no` at the play level or `ANSIBLE_GATHERING=explicit`), the `ansible_facts` dictionary is empty, so the variable resolves to `None` or an undefined value, causing the task to fail. The error is not a syntax or type issue but a missing fact dependency.

Exam trap

The EX294 exam often tests the dependency between fact gathering and fact-based variables, trapping candidates who assume the error is a simple type mismatch or misspelling rather than a missing fact collection step.

How to eliminate wrong answers

Option B is wrong because the variable name `http_port` is not used in the playbook; the task references `ansible_facts['ansible_tcpip_socket']['port']`, so a misspelling of `http_port` is irrelevant. Option C is wrong because the `wait_for` module does accept the `port` parameter as a string (e.g., `'80'`) and will convert it internally; the error is not due to type mismatch. Option D is wrong because `delegate_to` is used to run a task on a different host, but the `wait_for` task is already targeting the remote host via `hosts: all`; delegating to the remote host would be redundant and not fix the missing fact issue.

Practice this question →
9
Matchingmedium

Match each systemd unit type to its description.

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

Concepts
Matches

Background daemon or process

IPC or network socket

Time-based activation

Filesystem mount point

Group of units for synchronization

Why these pairings

Common systemd unit types include service (manages daemons), socket (manages IPC/network sockets), timer (schedules events), and mount (controls mount points). Be careful not to confuse timer with service.

Practice this question →
10
Multi-Selecthard

An administrator is debugging a playbook that uses multiple roles and wants to limit execution to a specific set of tasks. Which three methods can be used to filter task execution? (Choose three.)

Select 3 answers
A.Use the '--tags' command-line option.
B.Use the '--skip-tags' command-line option.
C.Use the '--check' command-line option.
D.Use the '--step' command-line option.
E.Use the '--start-at-task' command-line option.
AnswersA, B, E

--tags filters tasks by specified tags.

Why this answer

The '--tags' command-line option allows you to specify a subset of tasks to execute based on tags assigned to tasks or roles. When you run ansible-playbook with '--tags', only tasks that have a matching tag (or are tagged with 'always') will run, effectively filtering execution to a specific set of tasks.

Exam trap

The trap here is confusing options that control execution flow (like '--step' or '--check') with options that actually filter which tasks are included or excluded from the run, leading candidates to select non-filtering options.

Practice this question →
11
Multi-Selecthard

Which THREE are valid methods to control task execution in Ansible?

Select 3 answers
A.Using the 'when' conditional
B.Using 'block' to group tasks for error handling
C.Using 'register' to store task output
D.Using 'loop' to iterate over a list
E.Using the 'with_items' loop
AnswersA, B, D

'when' controls task execution based on conditions.

Why this answer

The 'when' conditional in Ansible allows you to control whether a task runs based on the evaluation of a condition, such as a variable, fact, or the result of a previous task. This is a primary method for conditional execution, enabling tasks to be skipped when the condition is false, directly controlling task execution flow.

Exam trap

The trap here is that candidates confuse 'register' (which stores output) with a control flow mechanism, or they mistakenly think 'with_items' is still a valid method for controlling task execution, when in fact the exam expects knowledge of the modern 'loop' keyword and the deprecation of 'with_items'.

Practice this question →
12
MCQhard

A playbook includes a long-running task that should not block the rest of the playbook. The administrator wants to start the task and later check its status. Which method should be used?

A.Use the 'async' keyword with 'poll: 0' and then use async_status module.
B.Use 'delegate_to: localhost' and 'run_once'.
C.Use a separate playbook invoked with 'ansible-playbook' via command module.
D.Use 'throttle' to limit execution.
AnswerA

async with poll=0 starts the task and returns immediately; async_status checks the result later.

Why this answer

Setting `poll: 0` with the `async` keyword launches the task in the background without waiting for it to complete, and the `async_status` module can then be used later to check the task's status by referencing its job ID. This allows the playbook to continue executing other tasks while the long-running task runs asynchronously.

Exam trap

The trap here is that candidates confuse `async` with `throttle` or `delegate_to`, thinking any concurrency-related keyword will make a task non-blocking, when only `async` with `poll: 0` achieves true background execution.

How to eliminate wrong answers

Option B is wrong because `delegate_to: localhost` and `run_once` control where a task runs and how many times it executes, but they do not prevent a long-running task from blocking the playbook; the task still runs synchronously. Option C is wrong because using a separate playbook invoked via the `command` module with `ansible-playbook` is an anti-pattern that bypasses Ansible's built-in async support, adds unnecessary complexity, and still blocks until the subprocess finishes unless manually backgrounded. Option D is wrong because `throttle` limits the number of concurrent task executions but does not make a task non-blocking; the task still runs synchronously within its throttle slot.

Practice this question →
13
MCQmedium

An administrator wants to use an Ansible role from Ansible Galaxy but the role has a dependency on another role that is already installed. What should be done to avoid conflicts?

A.Set 'allow_duplicates: false' in the parent role's meta/main.yml.
B.Define the dependency as a collection.
C.Use 'galaxy install --force' to overwrite.
D.No action needed; Ansible handles duplicates automatically.
AnswerA

This prevents the role from running multiple times if already listed.

Why this answer

(set allow_duplicates: false) is correct to prevent the dependency from running twice. Option B (force install) overwrites but doesn't prevent duplicate execution. Option C (collection) is a different concept.

Option D (no action) would cause the role to run twice by default.

Practice this question →
14
MCQhard

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

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

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
15
Multi-Selecteasy

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

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

Role dependencies are defined in meta/main.yml.

Why this answer

The meta/main.yml file within a role is specifically designed to declare role dependencies. When Ansible encounters this file, it automatically resolves and executes the listed dependent roles before the current role, ensuring required tasks, variables, or handlers are available. This is a core feature for modularizing and reusing automation logic across playbooks.

Exam trap

The trap here is that candidates often confuse the priority of role variables (vars/main.yml) with default variables (defaults/main.yml), mistakenly thinking playbook vars can override role vars, when in fact defaults have the lowest priority and role vars are higher than playbook vars.

Practice this question →
16
Multi-Selecthard

Which TWO statements about Ansible role defaults are true?

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

Defaults are defined in defaults/main.yml.

Why this answer

Ansible role defaults are defined in the defaults/main.yml file within the role directory structure. These defaults provide the most basic variable values that can be easily overridden by any other variable source, ensuring flexibility in role usage.

Exam trap

The EX294 exam often tests the distinction between role defaults and role vars, where candidates mistakenly think defaults have higher priority or cannot be overridden, but in reality defaults are the lowest priority and designed to be overridden by any other variable source.

Practice this question →
17
MCQhard

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

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

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

Why this answer

(Until loop with retries and delay) is correct. The 'until' loop in Ansible allows a task to be retried until a condition is met, with configurable retries and delay. Option B (failed_when) defines when a task is considered failed but does not provide retry functionality.

Option C (block/rescue) is used for error handling but does not retry the original task. Option D (async with poll) is for running tasks asynchronously and polling for completion, but it does not inherently retry on failure.

Practice this question →
18
MCQeasy

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

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

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

Why this answer

The `--vault-password-file` flag allows Ansible to read the vault password from a file with restricted permissions, enabling non-interactive decryption of `vault.yml` without exposing the password in the process list or requiring manual input. This method is secure when the vault password file has proper permissions (e.g., 600) and is stored in a controlled location.

Exam trap

The trap here is that candidates may confuse the `--vault-password-file` flag with setting the `ANSIBLE_VAULT_PASSWORD_FILE` environment variable, but the question explicitly asks for the method used when running the playbook, making the command-line flag the correct choice.

How to eliminate wrong answers

Option A is wrong because `include_vars` alone cannot decrypt an encrypted vault file; it requires the vault password to be provided via a password file, `--ask-vault-pass`, or `ANSIBLE_VAULT_PASSWORD_FILE`. Option B is wrong because `--ask-vault-pass` prompts for the password interactively, which is not suitable for automation or when the password is already stored in a file with restricted permissions. Option D is wrong because setting `ANSIBLE_VAULT_PASSWORD_FILE` in the user's profile is a valid method, but it is not a command-line option and does not directly answer how to securely load variables when running the playbook; the question specifically asks for the method used when running the playbook, and the `--vault-password-file` flag is the direct command-line approach.

Practice this question →
19
MCQmedium

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

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

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

Why this answer

The credential type 'Machine' is used for SSH or WinRM connections to hosts. The 'mysql_db' module requires database credentials to connect to a MySQL database, not SSH credentials. The correct credential type is 'Database', which provides the username and password for direct database access.

Changing the credential type to 'Database' and assigning it to the job template resolves the authentication failure. Option B is incorrect because extra variables do not change the credential type; the module still looks for a credential of the appropriate type. Option C is incorrect because machine credentials do not support SSH keys for database passwords.

Option D is incorrect because Ansible Vault encrypts data but does not change the credential type needed by the module.

Practice this question →
20
MCQhard

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

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

Correct. This command installs all roles from the requirements file into the specified `./roles` directory.

Why this answer

`ansible-galaxy install -r requirements.yml --roles-path ./roles` reads the requirements file and specifies the target directory for role installation. Option A is incorrect because it uses `collection install`, which installs collections, not roles. Option C is incorrect because `-p .` installs roles into the current directory, not the `roles` subdirectory.

Option D is incorrect because while it installs roles, the `--force` flag is unnecessary and may overwrite existing roles without need.

Practice this question →
21
MCQeasy

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

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

flush_handlers triggers all notified handlers right away.

Why this answer

The 'meta: flush_handlers' task in Ansible is used to force any pending handler notifications to run immediately at that point in the play, rather than waiting until the end of the play. This is correct because it ensures that handlers triggered by earlier tasks execute right away, which is essential when subsequent tasks depend on the state changes those handlers make (e.g., restarting a service before configuring it further).

Exam trap

The trap here is that candidates confuse 'flush_handlers' with simply waiting for handlers to complete (Option C), not realizing that flush_handlers actively forces immediate execution of the handler queue, rather than passively waiting for the default end-of-play execution.

How to eliminate wrong answers

Option A is wrong because 'restart services immediately' is not a direct purpose of flush_handlers; handlers may include restarts, but flush_handlers forces all pending handlers to run, not just restarts. Option B is wrong because 'clear the handler queue' is the opposite of what flush_handlers does—it executes the queue, not empties it without execution. Option C is wrong because 'wait for handlers to complete' describes a passive behavior, whereas flush_handlers actively triggers execution of pending handlers at that point in the play.

Practice this question →
22
MCQeasy

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

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

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

Why this answer

The 'vars' keyword under a role inclusion in Ansible allows you to override the default variables defined within that specific role. This is done at the point of inclusion, providing role-specific variable overrides without affecting other roles or the playbook's global variable scope.

Exam trap

The trap here is that candidates often confuse the 'vars' keyword under a role inclusion with setting global playbook variables, but it only overrides variables for that specific role instance.

How to eliminate wrong answers

Option A is wrong because 'vars' under a role inclusion does not set variables for the common role; it only affects the specific role being included. Option B is wrong because 'vars' does not define new variables for the playbook as a whole; it only provides variables to the included role. Option C is wrong because 'vars' under a single role inclusion does not set variables for all roles in the play; each role inclusion can have its own 'vars' block, and they are isolated to that role.

Practice this question →
23
MCQmedium

Refer to the exhibit. When the playbook runs on target1, which value will nginx_port have in the role?

A.443 (from playbook vars)
B.8080 (from vars/main.yml)
C.9090 (from host vars)
D.80 (from defaults/main.yml)
AnswerC

Host vars have higher precedence than playbook and role vars.

Why this answer

Ansible variable precedence dictates that host variables (in this case, from host_vars) override role defaults, role vars, and playbook vars. Since nginx_port is defined in host_vars for target1 with value 9090, that value takes highest precedence among the listed sources, so the role will use 9090.

Exam trap

Red Hat often tests the misconception that role vars (vars/main.yml) or playbook vars always override host_vars, when in fact host_vars have higher precedence than both role vars and playbook vars.

How to eliminate wrong answers

Option A is wrong because playbook vars have lower precedence than host vars; even though the playbook sets nginx_port to 443, host_vars override it. Option B is wrong because vars/main.yml within a role have lower precedence than host vars; the role's internal variable file sets 8080, but host_vars take priority. Option D is wrong because defaults/main.yml have the lowest precedence in Ansible's variable precedence hierarchy; the default value of 80 is overridden by any higher-precedence definition, including host_vars.

Practice this question →
24
MCQhard

An administrator wants to define role dependencies. In which file should they place the dependencies declaration?

A.vars/main.yml
B.defaults/main.yml
C.tasks/main.yml
D.meta/main.yml
AnswerD

Role metadata, including dependencies, is defined in meta/main.yml.

Why this answer

Role dependencies in Ansible are declared in the `meta/main.yml` file using the `dependencies` key. This allows you to specify other roles that must be executed before the current role, ensuring prerequisite tasks are run automatically.

Exam trap

The trap here is that candidates often confuse `meta/main.yml` with `tasks/main.yml` or variable files, assuming dependencies are defined in the task list or variable defaults, but Ansible specifically reserves `meta/main.yml` for role metadata including dependencies, author info, and supported platforms.

How to eliminate wrong answers

Option A is wrong because `vars/main.yml` is used to define variables for the role, not dependencies. Option B is wrong because `defaults/main.yml` is used to set default variable values, which have the lowest precedence and are not for dependencies. Option C is wrong because `tasks/main.yml` contains the main list of tasks to execute in the role, not dependency declarations.

Practice this question →
25
MCQmedium

A playbook uses a loop to create multiple users. The administrator notices that if one user creation fails, the entire playbook stops. Which directive should be used to continue executing remaining iterations?

A.max_fail_percentage
B.any_errors_fatal
C.ignore_errors
D.failed_when
AnswerC

ignore_errors tells Ansible to continue despite failures for that task, including within a loop.

Why this answer

`ignore_errors` is a directive that, when set to `yes` on a task, allows Ansible to continue executing subsequent iterations of a loop even if that specific task fails. This ensures that a failure in creating one user does not halt the entire playbook, as Ansible will record the failure but proceed with the remaining items in the loop.

Exam trap

The trap here is that candidates often confuse `ignore_errors` with `failed_when` or `any_errors_fatal`, thinking that custom failure conditions or global error handling will allow loop continuation, but only `ignore_errors` directly permits the playbook to proceed past a failed task within a loop.

How to eliminate wrong answers

Option A is wrong because `max_fail_percentage` is a directive used with the `serial` keyword to control how many hosts can fail before the playbook stops; it does not apply to individual task failures within a loop. Option B is wrong because `any_errors_fatal` causes the playbook to stop on any error from a task across all hosts, which would halt execution on the first failure, not continue iterations. Option D is wrong because `failed_when` defines custom failure conditions for a task but does not prevent the playbook from stopping; it only changes what constitutes a failure, and without `ignore_errors`, the playbook still halts on that failure.

Practice this question →
26
MCQmedium

Refer to the exhibit. The playbook runs successfully. What will the debug task output?

A.Just the username 'jdoe'.
B.A dictionary with details about the user, such as uid, gid, and groups.
C.The entire playbook YAML structure.
D.The string 'true' if the user was created successfully.
AnswerB

The user module returns a dictionary with user attributes.

Why this answer

The debug task outputs the registered variable from the user module. By default, the user module returns a dictionary containing user account details such as uid, gid, groups, and home directory when the state is 'present'. Since the playbook runs successfully, the registered variable holds this dictionary, making option B correct.

Exam trap

Red Hat often tests the misconception that the debug task outputs a simple success message or a single value, when in fact it outputs the full return dictionary from the module.

How to eliminate wrong answers

Option A is wrong because the debug task does not output just the username; the user module returns a dictionary with multiple attributes, not a single string. Option C is wrong because the debug task outputs the contents of the registered variable, not the entire playbook YAML structure. Option D is wrong because the user module does not return a boolean string 'true'; it returns a dictionary on success, and the debug task will display that dictionary, not a success indicator.

Practice this question →
27
Multi-Selectmedium

An administrator has a playbook with tasks tagged 'install', 'configure', and 'service'. There are no untagged tasks. They want to run only the tasks tagged 'install' and 'configure', skipping 'service'. Which three commands will achieve this? (Choose three.)

Select 3 answers
A.ansible-playbook site.yml --tags install,configure
B.ansible-playbook site.yml --tags configure --skip-tags install,service
C.ansible-playbook site.yml --skip-tags service
D.ansible-playbook site.yml --tags install --skip-tags service
E.ansible-playbook site.yml --tags install --tags configure
AnswersA, C, E

Runs tasks with either install or configure tag.

Why this answer

Options A, C, and E are correct. Option A uses a comma-separated list with `--tags` to run tasks tagged 'install' or 'configure'. Option C uses `--skip-tags service` to exclude the 'service' tag, running all other tags (install and configure).

Option E uses multiple `--tags` options, which Ansible combines with OR logic, effectively running tasks matching either 'install' or 'configure'. Options B and D are incorrect: B runs only 'configure' tasks (since it skips install and service), and D runs only 'install' tasks (since it specifies only that tag and skips service).

Exam trap

The trap is that candidates may think multiple `--tags` options only take the last value, but Ansible combines all `--tags` values. Additionally, `--skip-tags` can be used alone without `--tags` to exclude specific tags.

Practice this question →
28
MCQmedium

Refer to the exhibit. The administrator wants to run a playbook that installs a package on all webservers. Which command will use the existing configuration and inventory correctly?

A.ansible-playbook -e 'ansible_python_interpreter=/usr/bin/python3' site.yml
B.ansible-playbook site.yml
C.ansible webservers -m package -a 'name=httpd state=present'
D.ansible-playbook -i inventory site.yml
AnswerB

ansible-playbook reads ansible.cfg automatically, using the defined inventory.

Why this answer

The ansible.cfg sets inventory=./inventory and roles_path=./roles. The playbook should be run with ansible-playbook, which reads the configuration automatically. The -i flag is not needed because inventory is defined in ansible.cfg.

Practice this question →
29
MCQeasy

Which directive in an Ansible playbook ensures that a task runs only on the first host in a batch, and results are applied to all hosts?

A.run_once
B.any_errors_fatal
C.throttle
D.delegate_to: localhost
AnswerA

run_once runs the task on the first host and applies results to all hosts.

Why this answer

Option A (run_once) is correct. The `run_once` directive ensures that a task is executed only once for the entire batch, typically on the first host, and the results are then applied to all hosts in the play. Option B (any_errors_fatal) is incorrect; it causes the play to abort if any task fails on any host, unrelated to running a task once.

Option C (throttle) is incorrect; it limits the number of hosts that execute the task concurrently but does not ensure single execution. Option D (delegate_to: localhost) is incorrect; it delegates execution to the localhost but still runs on every host in the batch unless combined with `run_once`.

Practice this question →
30
MCQmedium

A team develops a custom Ansible role 'webserver' that depends on another role 'common'. They want to ensure that when 'webserver' is used, 'common' is automatically installed from the same Galaxy server. Which approach should they use?

A.Add a requirements.yml file in the role's root directory specifying common.
B.Add a dependencies: ['common'] to the role's meta/main.yml file.
C.Use ansible-galaxy install webserver --with-dependencies to install common separately.
D.Include the 'common' role in the playbook before 'webserver'.
AnswerB

Correct: Role dependencies in meta/main.yml are automatically installed.

Why this answer

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

Exam trap

The trap here is that candidates confuse role dependencies (declared in `meta/main.yml`) with playbook-level role ordering or external requirements files, leading them to choose options that manage execution order or manual installation instead of automatic dependency resolution.

How to eliminate wrong answers

Option A is wrong because a `requirements.yml` file in the role's root directory is not automatically processed by Ansible when installing a role; it is used at the project or playbook level to define external role collections for `ansible-galaxy install -r`. Option C is wrong because `--with-dependencies` is not a valid flag for `ansible-galaxy install`; dependencies are resolved automatically from `meta/main.yml` without requiring a separate flag. Option D is wrong because including 'common' in the playbook before 'webserver' only controls execution order at runtime, not installation; it does not ensure 'common' is installed from Galaxy automatically.

Practice this question →
31
MCQmedium

Refer to the exhibit. The administrator defines a default variable 'db_port' in the role's defaults/main.yml. However, the playbook sets 'db_port: 3307' as a role parameter. After running the playbook, what is the value of 'db_port' on the target host?

A.Undefined
B.3307
C.An error occurs because of conflicting definitions.
D.3306
AnswerB

Role parameters in the playbook have higher precedence than defaults.

Practice this question →
32
Multi-Selectmedium

Which TWO of the following statements about Ansible roles are correct?

Select 2 answers
A.Role names must be prefixed with 'ansible-role-' when published to Ansible Galaxy.
B.Variables in 'defaults/main.yml' have the lowest precedence and can be overridden by inventory variables.
C.Role dependencies are defined in the 'meta/main.yml' file.
D.The 'include_role' module can only be used for static imports.
E.A role's tasks are executed before any 'pre_tasks' defined in the playbook.
AnswersB, C

Correct: defaults have the lowest precedence.

Why this answer

Variables in defaults/main.yml have the lowest precedence and can be overridden by inventory variables. Role dependencies are defined in meta/main.yml. The other options are incorrect: pre_tasks run before roles, include_role is dynamic, and the naming convention is not mandatory.

Practice this question →
33
MCQmedium

A DevOps engineer wants to run an Ansible playbook inside a specific execution environment (EE) that includes custom collections. The EE image is stored in a private registry requiring authentication. The engineer has configured a container credential file. Which command will execute the playbook using the EE and the credential file?

A.ansible-navigator run -m stdout --ce docker --container-image registry.example.com/custom-ee --container-auth-file auth.json
B.ansible-navigator run -m stdout --ce docker --container-image registry.example.com/custom-ee --container-auth-file credentials.yml
C.ansible-navigator run --pp never --ce docker --container-image registry.example.com/custom-ee
D.ansible-navigator run -m stdout --pp never --ce docker --container-image registry.example.com/custom-ee --container-credential-file credentials.yml
AnswerA

Correct: --container-auth-file specifies the authentication file for registry access.

Why this answer

`ansible-navigator` uses the `--container-auth-file` flag to specify a container credential file (typically in JSON format) for authenticating to a private registry. The `-m stdout` flag sets the execution mode to stdout, and `--ce docker` selects Docker as the container engine. This command correctly references the EE image and the auth file, enabling the playbook to run inside the authenticated custom execution environment.

Exam trap

The trap here is that candidates confuse `--container-auth-file` (the correct flag for a JSON auth file) with `--container-credential-file` (a nonexistent flag) or assume YAML is acceptable, leading them to pick options B or D.

How to eliminate wrong answers

Option B is wrong because it uses `--container-auth-file credentials.yml`, but the container credential file must be in JSON format (as generated by `podman login` or `docker login`), not YAML. Option C is wrong because it omits the `--container-auth-file` flag entirely, so ansible-navigator cannot authenticate to the private registry and will fail to pull the EE image. Option D is wrong because it uses `--container-credential-file credentials.yml`, which is not a valid flag; the correct flag is `--container-auth-file`, and the file must be JSON, not YAML.

Practice this question →
34
MCQhard

What is the most likely cause of the failure?

A.The --check flag prevents role variable resolution.
B.The nginx role's defaults or vars do not define 'nginx_version'.
C.The host web1 is not configured to use the nginx role.
D.The nginx role was not included in the playbook correctly.
AnswerB

The variable is undefined in the role's defaults or vars files.

Why this answer

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

Exam trap

The trap here is that candidates often assume the `--check` flag is the culprit for any failure during a dry run, but Ansible's check mode still resolves all variables and validates templates, so a missing variable error is not caused by the check flag itself.

How to eliminate wrong answers

Option A is wrong because the `--check` flag does not prevent role variable resolution; it only skips the execution of modules that would make changes, while variable resolution still occurs normally. Option C is wrong because the host web1 does not need to be 'configured to use the nginx role' in a separate step; roles are applied via the playbook's `roles:` directive or `include_role`, and the error is about a missing variable, not role assignment. Option D is wrong because the error message does not indicate a syntax or inclusion issue with the role; it specifically points to an undefined variable, meaning the role was included but its variable definitions are incomplete.

Practice this question →
35
MCQeasy

A playbook includes multiple roles. The administrator wants to skip a specific role during execution. Which technique should they use?

A.Add a condition to each task in the role
B.Use the '--limit' option to exclude hosts
C.Use tags on the role and run with --tags
D.Use tags on the role and run with --skip-tags
AnswerD

--skip-tags excludes tasks with the specified tags.

Why this answer

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

Exam trap

Candidates often confuse --tags and --skip-tags, mistakenly choosing --tags when the goal is to skip a role.

How to eliminate wrong answers

Option A is wrong because adding a condition to each task in the role is inefficient, error-prone, and violates DRY principles; it requires modifying every task and does not leverage Ansible's built-in role-skipping mechanisms. Option B is wrong because `--limit` filters hosts, not roles or tasks; it cannot skip a specific role within a playbook that targets multiple hosts. Option C is wrong because using `--tags` includes only tagged items, but the question asks to skip a specific role, not to include only certain roles; `--tags` would require tagging all other roles and tasks, which is impractical and opposite to the goal.

Practice this question →
36
MCQeasy

An Ansible playbook needs to ensure a service is enabled and running on boot. Which combination of parameters should be used with the 'systemd' module?

A.enabled: yes, state: reloaded
B.enabled: yes, state: started
C.enabled: yes, daemon_reload: yes
D.enabled: yes, state: restarted
AnswerB

This ensures the service is enabled and running.

Why this answer

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

Exam trap

The trap here is that candidates often confuse 'enabled' with 'state' or assume 'daemon_reload' or 'reloaded' can substitute for starting the service, but only the combination of 'enabled: yes' and 'state: started' fully satisfies the requirement for both boot persistence and current running state.

How to eliminate wrong answers

Option A is wrong because 'state: reloaded' only reloads the service's configuration without starting it if it is not running, and it does not guarantee the service is enabled on boot. Option C is wrong because 'daemon_reload: yes' only reloads the systemd manager configuration (e.g., after adding new unit files) but does not start the service or enable it on boot. Option D is wrong because 'state: restarted' restarts the service if it is running but does not ensure it is enabled to start on boot, and it will fail if the service is not already running.

Practice this question →
37
Drag & Dropmedium

Drag and drop the steps to configure a logical volume (LV) using LVM on a new disk in the correct order.

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

Steps
Order
1Step 1
2Step 2
3Step 3
4Step 4

Why this order

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

Practice this question →
38
MCQhard

A playbook uses ansible.builtin.import_playbook to include other playbooks. The administrator needs to pass variables to the imported playbook. Which approach is valid?

A.Use ansible.builtin.include_vars inside the imported playbook
B.Set variables using set_fact before the import
C.Use group_vars or host_vars
D.Add a 'vars' block to the import_playbook statement
AnswerD

import_playbook: other.yml vars: { key: value } is the correct syntax.

Why this answer

`ansible.builtin.import_playbook` supports a `vars` keyword directly in the import statement, allowing you to pass variables to the imported playbook at the time of import. This is the only built-in method that passes variables into the imported playbook's scope without relying on external files or facts.

Exam trap

A common trap is the misconception that `set_fact` or `include_vars` can pass variables into an imported playbook, but `import_playbook` creates a new play scope that does not inherit facts or variables set in the parent play unless explicitly passed via the `vars` keyword.

How to eliminate wrong answers

Option A is wrong because `include_vars` loads variables from a file into the current play's scope, but it does not pass those variables into an imported playbook; the imported playbook runs in its own scope and does not inherit variables set by `include_vars` in the parent playbook. Option B is wrong because `set_fact` sets host-level facts for the current play's hosts, but `import_playbook` runs in a separate play context and does not inherit facts set before the import; facts are per-host and per-play, not passed across play imports. Option C is wrong because `group_vars` and `host_vars` are static variable sources that apply to all plays targeting those groups/hosts, but they are not a method to pass variables specifically at the `import_playbook` statement; they are a general variable precedence mechanism, not a direct parameter passing approach.

Practice this question →
39
MCQhard

Refer to the exhibit. An administrator runs a playbook in check mode and receives the shown output. What should be done to fix the failure while maintaining idempotency?

A.Modify the deploy role to use the force parameter when copying files.
B.Add a task in the apache role to create the /var/www/html directory using the file module.
C.Run the playbook without check mode to force the deployment.
D.Add a pre_task in the playbook to create /var/www/html before roles execute.
AnswerB

The apache role should ensure the document root exists before deploying files.

Why this answer

The deploy role fails because /var/www/html does not exist. The apache role should ensure the directory exists, typically by including a task to create it. Adding a file module task in the apache role to create /var/www/html would fix the issue.

Practice this question →
40
MCQhard

Refer to the exhibit. An administrator runs an Ansible playbook and receives the error shown. The playbook uses a variable 'vault_httpd_port' that should be stored in an encrypted vault file. Which step should the administrator take first to resolve the issue?

A.Re-encrypt the vault file with a different password.
B.Add 'vault_httpd_port' to the group_vars/all.yml file without encryption.
C.Use the --ask-vault-pass option again with a different password.
D.Ensure the vault file is referenced in the playbook using include_vars or vars_files, and that the vault password is correct.
AnswerD

The vault file must be included in the playbook, and the vault password must be provided correctly.

Practice this question →
41
Multi-Selecteasy

An Ansible playbook that installs packages and configures services is not idempotent. Which two practices should be implemented to make it idempotent? (Choose two.)

Select 2 answers
A.Use notify handlers to restart services only on change.
B.Use the command module with the 'creates' parameter.
C.Use state=present for package installation.
D.Use check_mode: yes to preview changes.
E.Set always_run: yes on tasks.
AnswersB, C

creates makes the command run only if a specified file is missing, ensuring idempotency.

Why this answer

Using the command module with the 'creates' parameter makes the task idempotent by skipping execution if the specified file or directory already exists. This prevents the command from running repeatedly and causing unintended changes. Option C is correct because setting state=present for package installation ensures that the package manager only installs the package if it is not already installed, making the task idempotent.

Exam trap

The trap here is that candidates often confuse 'notify handlers' with idempotence, thinking that restarting a service only on change makes the playbook idempotent, but idempotence applies to the task itself, not the handler.

Practice this question →
42
MCQeasy

In an Ansible playbook, the 'strategy' parameter is set to 'free'. What behavior does this strategy produce?

A.Playbook runs tasks on hosts in batches of 1.
B.Strategy is deprecated and replaced by 'linear'.
C.All hosts run the same task at the same time, then move to the next task.
D.Each host runs through the playbook independently of other hosts.
AnswerD

Free strategy allows hosts to run tasks as fast as they can, not waiting for others.

Why this answer

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

Exam trap

The trap here is confusing the 'free' strategy with the 'serial' parameter or the default 'linear' strategy, leading candidates to incorrectly associate batching or synchronized task execution with 'free'.

How to eliminate wrong answers

Option A is wrong because the 'free' strategy does not run tasks in batches of 1; that behavior is achieved by setting the 'serial' parameter to 1, which controls batch size, not the strategy. Option B is wrong because the 'free' strategy is not deprecated and is still fully supported; the 'linear' strategy is the default, not a replacement for 'free'. Option C is wrong because it describes the 'linear' strategy, where all hosts execute the same task simultaneously before moving to the next task; the 'free' strategy allows hosts to proceed independently.

Practice this question →
43
Multi-Selecteasy

Which TWO elements can be used to include external task files in a playbook?

Select 2 answers
A.import_tasks
B.include_tasks
C.include_vars
D.add_host
E.include_role
AnswersA, B

import_tasks statically includes a task file.

Why this answer

Both `import_tasks` and `include_tasks` are Ansible directives used to incorporate external task files into a playbook. `import_tasks` statically loads and parses the tasks at playbook parse time, meaning all tasks are treated as if they were written directly in the playbook. `include_tasks` dynamically loads tasks at runtime, allowing for conditional includes and loops that are evaluated when the task is executed.

Exam trap

The trap here is that candidates often confuse `include_tasks` and `import_tasks` with variable-loading or inventory-modifying modules, or they mistakenly think `include_role` can be used to include arbitrary task files instead of entire roles.

Practice this question →
44
MCQeasy

Refer to the exhibit. A playbook already includes the 'common' role in its roles list. The current role depends on 'common' with 'allow_duplicates: false'. How many times will the 'common' role run?

A.Once.
B.Not at all.
C.Depends on the order of roles.
D.Twice.
AnswerA

Because allow_duplicates: false prevents the role from running multiple times.

Why this answer

The 'common' role is already listed in the playbook's roles list, and the current role declares a dependency on 'common' with 'allow_duplicates: false'. In Ansible, when a role dependency is defined with 'allow_duplicates: false', Ansible checks if the role has already been executed in the current play. Since 'common' is already in the roles list, it will not run again, resulting in a single execution.

Exam trap

Red Hat often tests the misconception that role dependencies always run regardless of duplicates, or that the order of roles in the playbook affects duplicate detection, when in fact 'allow_duplicates: false' is a global setting that prevents any role from running more than once per play.

How to eliminate wrong answers

Option B is wrong because the 'common' role is explicitly listed in the playbook's roles, so it will run at least once; dependencies do not prevent the initial role execution. Option C is wrong because the 'allow_duplicates: false' setting is evaluated globally across all roles and dependencies, not based on the order of roles; the role will run only once regardless of order. Option D is wrong because 'allow_duplicates: false' explicitly prevents duplicate runs, so the role cannot run twice even if it appears both as a direct role and as a dependency.

Practice this question →
45
MCQeasy

You are managing a web application deployment using Ansible. The application requires a specific version of a library (libapp) to be installed on all web servers. Your current playbook uses the role 'web' which includes a task to install libapp version 1.2. However, after a recent update, the role's defaults now specify libapp version 2.0, but you must keep version 1.2 for compatibility. You have defined a variable 'lib_version' in the playbook's vars section with value '1.2'. The role's task uses the variable 'libapp_version' (not 'lib_version'). The play fails because 'libapp_version' is undefined. What is the best way to resolve this issue without modifying the role?

A.Modify the role's defaults/main.yml to set libapp_version to 1.2.
B.Use the playbook to set libapp_version as a variable for the role: either in the play vars section or by passing it as a role parameter.
C.Rename your playbook variable from lib_version to libapp_version in the play vars.
D.Create a file roles/web/vars/main.yml with libapp_version: 1.2.
AnswerB

You can set libapp_version in the play's vars or as a role parameter without modifying the role.

Why this answer

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

Exam trap

The trap here is that candidates may confuse variable names (lib_version vs libapp_version) and attempt to rename variables or modify role defaults, rather than understanding that the correct solution is to set the exact variable expected by the role at the playbook level.

How to eliminate wrong answers

Option A is wrong because modifying the role's defaults/main.yml directly changes the role, which violates the requirement to not modify the role. Option C is wrong because renaming the playbook variable from `lib_version` to `libapp_version` does not address the issue; the role's task uses `libapp_version`, and simply renaming the variable in the playbook's vars section would still leave `libapp_version` undefined unless the variable is explicitly set. Option D is wrong because creating a file roles/web/vars/main.yml modifies the role's internal structure, which is not allowed per the requirement to not modify the role.

Practice this question →
46
Multi-Selectmedium

Which THREE directives can be used to modify loop behavior in Ansible?

Select 3 answers
A.ignore_errors
B.loop_control
C.when
D.rescue
E.always
AnswersA, B, C

ignore_errors causes Ansible to continue to the next item even if the current one fails.

Why this answer

A is correct because `ignore_errors` is a directive that modifies loop behavior by allowing the task to continue processing subsequent items in the loop even if one iteration fails. This is commonly used when you want to gather information from multiple hosts or resources and don't want a single failure to halt the entire loop execution.

Exam trap

The trap here is that candidates confuse block-level directives (`rescue`, `always`) with loop modifiers, because they appear in similar task execution contexts but serve entirely different purposes. In the Red Hat EX294 exam, this distinction is frequently tested.

Practice this question →
47
MCQhard

A developer wants to reuse a set of tasks that conditionally include other task files based on variables defined per host. Which method should be used to ensure the included tasks are evaluated per host at runtime?

A.include_tasks
B.include_role
C.import_role
D.import_tasks
AnswerA

include_tasks is dynamic and evaluates per host at runtime.

Why this answer

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

Exam trap

The trap here is that candidates confuse static imports (import_tasks, import_role) with dynamic includes (include_tasks, include_role), not realizing that static imports are resolved at parse time and cannot handle per-host conditional logic at runtime.

How to eliminate wrong answers

Option B (include_role) is wrong because it dynamically includes an entire role at runtime, not a set of tasks that conditionally include other task files; it is designed for role reuse, not granular task file inclusion based on per-host variables. Option C (import_role) is wrong because it statically imports a role at playbook parse time, meaning all tasks and dependencies are pre-processed and cannot be conditionally evaluated per host at runtime. Option D (import_tasks) is wrong because it statically imports task files at parse time, so any conditional logic or variable-based inclusion is resolved before the playbook runs, preventing per-host runtime evaluation.

Practice this question →
48
MCQmedium

Your team uses ansible-pull to manage configuration of a large number of remote nodes. Each node is configured to pull the latest playbook from a Git repository every 30 minutes. Recently, some nodes started reporting 'ERROR! the role 'base' was not found'. The playbook depends on roles from a requirements.yml file that is stored in the same repository. The ansible-pull command on each node uses the default roles path (~/.ansible/roles). The Git repository contains the requirements.yml file but does not contain the actual role directories. What is the most likely cause and solution?

A.Run ansible-galaxy install on the control node and distribute the roles via a separate channel.
B.Add the role directories directly to the Git repository and modify the playbook to reference them with a relative path.
C.Add a pre_task to the playbook that runs 'ansible-galaxy install -r requirements.yml' before the roles are used.
D.Set the 'roles_path' in ansible.cfg on each node to include the repository's roles directory.
AnswerC

Correct: This ensures roles are installed from Galaxy during the pull execution.

Why this answer

Ansible-pull does not automatically install roles from requirements.yml; the playbook should include a pre_task that runs 'ansible-galaxy install -r requirements.yml' before using the roles. Option A is incorrect because the roles are already in the repository? No, they are not. Option B is incorrect because ansible-pull does not use a local roles path by default; the issue is missing installation.

Option D is incorrect because the control node is not involved in ansible-pull.

Practice this question →
49
MCQeasy

An administrator wants to ensure a role's tasks are executed only on certain hosts. Which approach should they use?

A.Set host_vars for each target host
B.Set group_vars for the target group
C.Use a 'when' condition in the role's tasks
D.Use tags on the role
AnswerC

A when condition can evaluate inventory or fact data to determine if a task runs on a particular host.

Why this answer

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

Exam trap

The trap here is that candidates often confuse variable scoping (host_vars/group_vars) with conditional execution, assuming that setting variables for a host or group inherently limits task execution to those hosts, when in fact variables only provide data and do not control task flow without an explicit 'when' condition.

How to eliminate wrong answers

Option A is wrong because setting host_vars for each target host defines variables per host but does not control task execution; tasks will still run on all hosts unless a 'when' condition references those variables. Option B is wrong because group_vars define variables for all hosts in a group, but tasks will execute on every host in that group unless a 'when' condition is added; group_vars alone cannot restrict execution to a subset of hosts within the group. Option D is wrong because tags on a role are used to selectively include or exclude tasks during playbook runs via the '--tags' or '--skip-tags' options, but they do not enforce host-based restrictions; tags control which tasks run globally, not which hosts they run on.

Practice this question →
50
MCQhard

You are responsible for managing a large fleet of web servers running Red Hat Enterprise Linux 8. You have an Ansible playbook that deploys a custom web application. The playbook uses several roles from Ansible Galaxy and includes tasks that require root privileges. Recently, users reported that the deployment fails intermittently with the error 'Timeout (12s) waiting for privilege escalation prompt'. You suspect that the issue is related to the become method and the SSH connection. The current inventory uses 'ansible_user: deploy' and 'ansible_become: yes' with default settings. The 'deploy' user has sudo privileges with NOPASSWD for all commands. However, the timeout occurs only on high-latency connections. Which change would most effectively resolve the timeout issue?

A.Increase 'forks' to 20 to run more tasks in parallel.
B.Enable pipelining by setting 'pipelining = True' in ansible.cfg.
C.Set 'ansible_become_password' in the inventory.
D.Set ansible_become_timeout to a higher value in the inventory.
AnswerD

Increasing the general 'timeout' in ansible.cfg controls the SSH connection timeout, not the become timeout. Therefore, it does not solve the privilege escalation timeout issue.

Why this answer

The error 'Timeout (12s) waiting for privilege escalation prompt' is specifically about the become timeout, not the general SSH timeout. The correct fix is to increase the become timeout by setting 'ansible_become_timeout' to a higher value in the inventory or playbook. Option D correctly increases this timeout.

Option A (forks) only affects parallelism. Option B (pipelining) reduces SSH round trips but does not change the become timeout. Option C (become password) is unnecessary because the user already has NOPASSWD sudo access.

Practice this question →
51
Multi-Selectmedium

Which TWO statements about Ansible roles are true?

Select 2 answers
A.A role can include tasks, handlers, variables, templates, and files.
B.Roles are defined directly inside a playbook using the 'roles' keyword.
C.Roles can be reused across multiple playbooks.
D.Roles can only be invoked using the 'include_role' module.
E.Variables defined in a role's vars/main.yml cannot be overridden by playbook variables.
AnswersA, C

Roles organize these components in a standard structure.

Why this answer

Ansible roles are designed to organize automation content into a standardized directory structure that can include tasks, handlers, variables, templates, and files. This modular structure allows for better code reuse and maintainability, as each component is stored in its own subdirectory within the role.

Exam trap

Red Hat often tests the misconception that roles can only be invoked via 'include_role' or that role variables cannot be overridden, but in reality, roles support both static and dynamic inclusion, and vars/main.yml variables are overridable by higher-precedence variables like playbook vars.

Practice this question →
52
MCQeasy

You need to run an Ansible playbook every hour to update a dynamic inventory file from a CMDB API. The playbook is stored in /opt/ansible/update_inventory.yml. You want to schedule the execution using a cron job on the control node. The control node runs Red Hat Enterprise Linux 9. The playbook uses Ansible Vault to decrypt API credentials, and the vault password is stored in /etc/ansible/.vault_pass. Which cron entry will execute the playbook hourly?

A.0 * * * * /usr/bin/ansible-playbook --vault-password-file ~/.vault_pass /opt/ansible/update_inventory.yml
B.* * * * * /usr/bin/ansible-playbook --vault-password-file /etc/ansible/.vault_pass /opt/ansible/update_inventory.yml
C.0 * * * * /usr/bin/ansible --vault-password-file /etc/ansible/.vault_pass /opt/ansible/update_inventory.yml
D.0 * * * * /usr/bin/ansible-playbook --vault-password-file /etc/ansible/.vault_pass /opt/ansible/update_inventory.yml
AnswerD

Correct: Runs hourly with proper vault password file and playbook path.

Why this answer

It specifies the correct cron schedule (0 * * * * for hourly), uses the correct command (ansible-playbook), and points to the correct vault password file (/etc/ansible/.vault_pass) as specified in the stem. Option A uses the wrong vault password file path (~/.vault_pass). Option B uses the wrong schedule (every minute).

Option C uses the wrong command (ansible instead of ansible-playbook).

Practice this question →
53
MCQmedium

An Ansible role has a complex dependency tree. The administrator wants to ensure that dependencies are installed before the main role tasks. Which file should be used to define dependencies?

A.meta/main.yml
B.defaults/main.yml
C.tasks/main.yml
D.vars/main.yml
AnswerA

The meta directory contains main.yml for role metadata including dependencies.

Why this answer

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

Exam trap

The trap here is that candidates often confuse `meta/main.yml` with `tasks/main.yml` or `vars/main.yml`, mistakenly thinking dependencies can be defined in the same file as tasks or variables, when in fact only `meta/main.yml` supports the `dependencies` directive.

How to eliminate wrong answers

Option B is wrong because `defaults/main.yml` is used to define default variable values for the role, not dependencies. Option C is wrong because `tasks/main.yml` contains the main list of tasks to execute for the role, but it does not support dependency declarations. Option D is wrong because `vars/main.yml` is used to define variables with higher precedence than defaults, but it cannot define role dependencies.

Practice this question →
54
MCQhard

Refer to the exhibit. The administrator runs the playbook with the 'deploy' tag, but all tasks are skipped. What is the most likely reason?

A.The --tags option filters tasks; only tasks with the 'deploy' tag run, but none of the role tasks have that tag.
B.The role 'database' is not found in the roles_path.
C.The inventory host db1.example.com is not in the dbservers group.
D.The tags in the role tasks conflict with the play tags, causing a syntax error.
AnswerA

The play-level tag does not propagate to role tasks unless inherited via include_role or import_role.

Why this answer

The playbook site.yml sets tags: ['deploy'] at the play level. When running with --tags 'deploy', only tasks that have the 'deploy' tag (or no tags) would run. However, all tasks in the role have specific tags (packages, service, database), and none have the 'deploy' tag.

Tasks with tags that do not match the specified tag are skipped. To fix, either remove tags from the play or add the 'deploy' tag to the roles tasks.

Practice this question →
55
MCQeasy

A team is automating server configuration using Ansible. They have a custom role 'security' that updates firewall and SSH settings. They notice that when they apply the role to multiple hosts, the SSH configuration changes sometimes fail because the firewall blocks the SSH port before the SSH configuration is updated. They need to ensure that SSH configuration is updated first, then firewall rules are applied. They have defined both tasks in the same role. What should they do?

A.Use tags to control the sequence of tasks.
B.Split the role into two separate roles and use role dependencies to enforce order.
C.Use pre_tasks for SSH and post_tasks for firewall in the playbook.
D.Use the 'order' directive in the playbook to specify task order within the role.
AnswerB

Correct: role dependencies in meta/main.yml enforce execution order.

Why this answer

Role dependencies allow you to define that one role must be executed before another. By splitting the 'security' role into separate roles for SSH and firewall, and setting the firewall role to depend on the SSH role, Ansible will always execute the SSH role first, ensuring the SSH configuration is updated before firewall rules are applied. This enforces order at the role level, which is the correct approach when tasks within a single role cannot be reordered independently.

Exam trap

The trap here is that candidates often think tags or pre/post_tasks can reorder tasks within a role, but tags only filter tasks and pre/post_tasks operate at the play level, not within a role's internal task list.

How to eliminate wrong answers

Option A is wrong because tags are used for selective execution of tasks, not for controlling the sequence of tasks within a role; they cannot enforce a specific order between tasks. Option C is wrong because pre_tasks and post_tasks are play-level directives that run before or after all roles, not within a single role; they cannot reorder tasks inside the same role. Option D is wrong because there is no 'order' directive in Ansible playbooks; task order within a role is determined by the order they appear in the role's task files, and there is no built-in directive to change that order dynamically.

Practice this question →
56
MCQeasy

Refer to the exhibit. An Ansible playbook task fails with 'Missing sudo password'. The playbook runs against a server where the remote user 'admin' has sudo privileges but requires a password. Which configuration change would resolve this issue?

A.Set ansible_become_password or use the -K flag when running the playbook.
B.Change become_method to su to avoid password prompts.
C.Remove the become_user line and rely on default root.
D.Change become_user to root.
AnswerA

Correct: This provides the required sudo password.

Why this answer

The error 'Missing sudo password' occurs because Ansible needs the sudo password for the remote user. Option A provides the password either by setting ansible_become_password in inventory or using the -K flag to prompt for it. Option B is incorrect because switching to su does not solve the password issue and is unnecessary.

Option C is incorrect because removing become_user doesn't address the password requirement. Option D is incorrect because changing become_user to root doesn't provide the needed password.

Practice this question →
57
MCQmedium

An administrator sees this output during a playbook run. What can they conclude?

A.The task had ignore_errors set to yes
B.The playbook was run with the --ignore-errors command-line flag
C.The task was part of a block with rescue
D.The playbook was run with the --check flag
AnswerA

The fatal error followed by 'ignoring' indicates ignore_errors was enabled.

Why this answer

When a task fails in Ansible but the playbook continues execution and shows a 'changed' or 'ok' status instead of 'failed', it indicates that the task has `ignore_errors: yes` set. This directive tells Ansible to treat any failure as a success, allowing the play to proceed without interruption.

Exam trap

The RHCE exam often tests the distinction between `ignore_errors` and `rescue` blocks, where candidates mistakenly think a rescue block silently ignores errors, but in reality, rescue tasks run only after a failure is explicitly detected and the failed task is still reported as failed.

How to eliminate wrong answers

Option B is wrong because the `--ignore-errors` command-line flag does not exist in Ansible; the correct flag is `--force-handlers` or similar, and error ignoring is configured per task, not globally via CLI. Option C is wrong because a block with `rescue` would show a different output pattern: the failed task would still display as 'failed' before the rescue tasks run, and the rescue section would execute, not silently ignore the error. Option D is wrong because the `--check` flag performs a dry run and does not execute tasks; it would show 'skipped' or 'check mode' indicators, not a successful completion of a failing task.

Practice this question →
58
MCQeasy

Which ansible.cfg setting controls the number of parallel forks for task execution?

A.parallel
B.max_parallel
C.forks
D.threads
AnswerC

The 'forks' setting in ansible.cfg controls the number of parallel processes.

Why this answer

The `forks` setting in `ansible.cfg` (or the `ANSIBLE_FORKS` environment variable) controls the maximum number of parallel processes Ansible uses when executing tasks on remote hosts. By default, this value is 5, meaning Ansible will manage up to 5 hosts concurrently per playbook run. Increasing this value allows Ansible to operate on more hosts simultaneously, improving throughput in larger environments.

Exam trap

The trap here is that candidates may confuse Ansible's `forks` with generic terms like `parallel` or `threads`, or with similar settings from other configuration management tools, leading them to select a plausible-sounding but incorrect option.

How to eliminate wrong answers

Option A is wrong because `parallel` is not a valid Ansible configuration setting; Ansible uses the `forks` parameter to control parallelism. Option B is wrong because `max_parallel` does not exist in Ansible's configuration; it may be confused with a similar concept in other tools like Puppet or SaltStack. Option D is wrong because `threads` is not an Ansible configuration key; Ansible uses multiprocessing (fork-based) rather than threading for parallel execution, and `threads` is unrelated to the number of concurrent hosts.

Practice this question →
59
MCQeasy

Which best practice should be followed when using Ansible to manage task execution across multiple hosts?

A.Use 'ignore_errors: yes' on all tasks to prevent playbook failures.
B.Ensure tasks are idempotent so they can be run multiple times without changing the system state beyond the desired state.
C.Always use serial execution to avoid race conditions.
D.Write tasks that rely on the previous task's output to ensure correct order.
AnswerB

Idempotency is a core principle of Ansible.

Why this answer

Idempotency is a core principle of Ansible: running the same playbook multiple times should produce the same desired state without unintended side effects. This ensures predictable, safe task execution across multiple hosts, as Ansible modules are designed to check the current state before making changes.

Exam trap

The trap here is that candidates confuse 'ignore_errors' with a valid error-handling strategy, or assume serial execution is always safer, when in fact idempotency is the fundamental best practice that Ansible's design revolves around.

How to eliminate wrong answers

Option A is wrong because 'ignore_errors: yes' on all tasks would suppress legitimate failures, making debugging impossible and potentially leaving systems in an inconsistent or broken state. Option C is wrong because serial execution is not always necessary; Ansible's default parallel execution (via forks) is efficient and safe for idempotent tasks, and serial is only used for specific rolling-update scenarios. Option D is wrong because relying on previous task output creates tight coupling and non-idempotent workflows; Ansible encourages using facts, registered variables, and idempotent modules to maintain order without hard dependencies.

Practice this question →
60
MCQhard

Refer to the exhibit. The administrator notices that the handler 'restart httpd' runs even though the httpd service was already running. Which change would ensure the handler only runs if the service configuration changes?

A.Add a condition to the handler to check if httpd is already running.
B.Set the handler to 'state: reloaded' instead of 'restarted'.
C.Move the 'Ensure httpd is running' task before the handler notification.
D.Use a separate handler for configuration changes and notify it from tasks that modify configuration files.
AnswerD

This ensures restart only occurs when configuration changes, not on every httpd package update.

Why this answer

The handler is notified by the 'Install httpd' task, which changes only on initial installation or update. However, the handler runs after the 'Ensure httpd is running' task, which is unnecessary. To avoid restarting when the service is already running and no configuration changed, the administrator should add a 'listen' directive or use a separate handler for configuration changes.

Practice this question →
61
MCQeasy

A systems administrator needs to run a playbook that installs packages on a group of managed nodes. The playbook should run only on nodes that are part of the 'web_servers' group in the inventory. Which approach is best practice?

A.Set 'hosts: web_servers' in the play.
B.Set 'hosts: all' and use '--limit web_servers' when running ansible-playbook.
C.Set 'hosts: localhost' and delegate tasks to web_servers.
D.Set 'hosts: all' and use a 'when' condition to check if the node is in the web_servers group.
AnswerA

Directly targeting the group is the simplest and most readable approach.

Why this answer

Setting 'hosts: web_servers' in the play directly targets only the nodes in that inventory group, which is the simplest and most maintainable approach. This follows Ansible's best practice of declaring the target group explicitly in the playbook rather than relying on runtime flags or conditional logic, ensuring the playbook's intent is clear and portable.

Exam trap

The trap here is that candidates may overcomplicate the solution by choosing runtime flags or conditional logic, forgetting that Ansible's simplest and most explicit targeting method—setting 'hosts' to the group name—is both best practice and the most reliable for clarity and execution.

How to eliminate wrong answers

Option B is wrong because using '--limit web_servers' with 'hosts: all' is a runtime override that can be forgotten or misapplied, making the playbook less self-documenting and error-prone; it also requires the operator to remember the flag each time. Option C is wrong because setting 'hosts: localhost' and delegating tasks to web_servers is unnecessary complexity—delegation is meant for tasks that must run on the control node (e.g., fetching files), not for targeting a group of managed nodes. Option D is wrong because using a 'when' condition to check group membership (e.g., 'when: "web_servers" in group_names') still runs the play on all nodes, wasting resources and potentially causing failures on non-target nodes if tasks are not idempotent.

Practice this question →
62
MCQhard

Refer to the exhibit. The playbook uses the 'yum' module to install 'httpd' on a RHEL 8 system. Which of the following is the most likely cause of the failure?

A.The 'yum' module is deprecated for RHEL 8; must use 'dnf'.
B.The AppStream repository is not enabled on the target host.
C.The remote host does not have subscription-manager access.
D.The package name is misspelled; it should be 'apache2'.
AnswerB

httpd is in AppStream; if disabled, package won't be found.

Why this answer

On RHEL 8, the `yum` command is a symbolic link to `dnf`, and the `yum` Ansible module internally uses `dnf` as the backend. The most common cause of failure when installing a package like `httpd` on RHEL 8 is that the AppStream repository (which contains `httpd`) is not enabled or available on the target host. Without an enabled repository containing the package, the module cannot resolve and install it, leading to a failure.

Exam trap

The trap here is that candidates assume the `yum` module is deprecated or incompatible with RHEL 8, but the actual failure is almost always a repository availability issue, not the module itself.

How to eliminate wrong answers

Option A is wrong because the `yum` module is not deprecated for RHEL 8; it is fully functional and internally delegates to `dnf` on RHEL 8 systems, so using the `yum` module is valid. Option C is wrong because subscription-manager access is not required for installing `httpd`; the package is available from standard repositories (e.g., AppStream) and does not require a Red Hat subscription to be accessed. Option D is wrong because the package name `httpd` is correct for RHEL 8; `apache2` is the package name used on Debian-based systems, not on RHEL.

Practice this question →
63
MCQhard

A team has developed several roles that share common variables. They want to organize these variables in a central file. Where should they place this file so it is automatically loaded by all roles?

A.In the inventory directory as host_vars/localhost.yml
B.In a common role's vars/main.yml
C.In a common role's defaults/main.yml
D.In the playbook directory as group_vars/all.yml
AnswerD

group_vars/all.yml is automatically included and applies to all hosts.

Why this answer

Placing a file in the playbook directory as group_vars/all.yml makes it automatically loaded by all roles. Ansible automatically includes any YAML files in the group_vars directory that match group names, and the special group 'all' applies to every host. This centralizes shared variables without requiring explicit imports in each role.

Exam trap

Red Hat often tests the distinction between role-level variable files (vars/main.yml and defaults/main.yml) and global variable files (group_vars/all.yml), trapping candidates who think a common role's vars/main.yml is automatically loaded by all roles when in fact it requires explicit role dependencies or includes.

How to eliminate wrong answers

Option A is wrong because host_vars/localhost.yml applies only to the localhost host, not to all hosts targeted by roles. Option B is wrong because vars/main.yml in a common role would require every other role to explicitly depend on or include that role, which is not automatic. Option C is wrong because defaults/main.yml in a common role defines default variables with the lowest precedence, which can be overridden by any higher-precedence variable source, making it unsuitable for central shared variables that should be consistently applied.

Practice this question →
64
Multi-Selectmedium

An Ansible playbook uses the 'block' and 'rescue' directives. Which two statements are true about this construct? (Choose two.)

Select 2 answers
A.Rescue tasks are executed on all hosts in the play.
B.A rescue section executes only if the block tasks fail.
C.Blocks cannot be nested.
D.The 'always' section runs regardless of success or failure.
E.A block can have multiple rescue sections.
AnswersB, D

Rescue runs when a task in the block fails.

Why this answer

The 'rescue' section in an Ansible block is specifically designed to execute only when a task within the 'block' fails. This allows you to define error recovery or rollback steps that run only on hosts where the block encountered a failure, ensuring that successful hosts are not affected by rescue logic.

Exam trap

The trap here is that candidates often think 'rescue' runs on all hosts or that multiple rescue sections are allowed, confusing Ansible's block/rescue/always pattern with exception handling in programming languages like try-catch-finally.

Practice this question →
65
MCQhard

You are managing a fleet of 50 RHEL 8 servers that host a critical web application. Your Ansible control node runs RHEL 8 with Ansible 2.9. The application requires a specific package 'app-pkg' that is only available from a private YUM repository. The repository is configured on each server via a role 'repo_config'. Recently, after a security update, the repository GPG key was changed. Now, when you run the playbook to install 'app-pkg' on all servers, it fails on some servers with the error: "GPG check FAILED: key ID mismatch". On other servers, the installation succeeds. All servers have the same OS version and are configured identically via the same role. The playbook uses the 'yum' module with 'state: present'. You verify that the GPG key file on the control node is the correct new key and that the role copies it to the servers. What is the most likely cause and the best course of action?

A.Add a task before installing the package to clean the yum cache using the 'command' module: 'yum clean all'. This ensures the new GPG key is used.
B.The repository URL might be incorrect on some servers. Use the 'uri' module to test connectivity to the repository.
C.The role is not copying the new GPG key to all servers. Re-run the role with 'force: yes' to ensure the key is overwritten.
D.Add 'disable_gpg_check: yes' to the task to bypass the GPG check temporarily.
AnswerA

Cleaning the cache removes old key data, allowing the new key to be imported correctly.

Why this answer

The 'GPG check FAILED: key ID mismatch' error indicates that the yum cache on some servers still holds the old GPG key metadata. Running 'yum clean all' before installing the package forces yum to refresh its metadata and re-import the new GPG key from the repository, resolving the mismatch. Since the role copies the new key file, the issue is not the key file itself but stale cached metadata.

Exam trap

The trap here is that candidates assume the GPG key file itself is not being copied correctly (option C) or that a connectivity test (option B) is needed, when the real issue is stale yum cache metadata causing a key ID mismatch.

How to eliminate wrong answers

Option B is wrong because the error is specifically a GPG key mismatch, not a connectivity issue; the repository URL is irrelevant to GPG key validation. Option C is wrong because the role already copies the new key file, and the error persists despite the key being present; the problem is stale yum cache, not missing or outdated key files. Option D is wrong because disabling GPG check bypasses security entirely and is not a proper fix; it would allow installation but leave the system vulnerable and does not address the root cause of the key mismatch.

Practice this question →
66
Multi-Selectmedium

Which TWO statements about Ansible roles are correct?

Select 2 answers
A.Roles must follow a specific directory structure.
B.Roles can be shared via Ansible Galaxy.
C.Ansible Galaxy is a continuous integration tool for testing roles.
D.Role dependencies must be defined in a file named dependencies.yml.
E.Role names must have a .role extension.
AnswersA, B

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

Why this answer

Ansible roles enforce a specific directory structure (e.g., tasks/, handlers/, templates/, files/, vars/, defaults/, meta/, and library/) to organize automation content. This structure is mandatory for Ansible to correctly locate and load role components during playbook execution.

Exam trap

The trap here is that candidates confuse Ansible Galaxy as a CI tool because it has 'Galaxy' in its name, or assume role dependencies require a separate file like dependencies.yml, when in fact they must be placed in meta/main.yml.

Practice this question →
67
MCQhard

Refer to the exhibit. An administrator runs an Ansible playbook and gets an unreachable error. The administrator has set ansible.cfg as shown. Which configuration change would most likely resolve the issue?

A.Set 'become_ask_pass = false' in ansible.cfg.
B.Set 'host_key_checking = False' in ansible.cfg.
C.Set 'ask_pass = true' in ansible.cfg.
D.Add 'remote_user: root' to the playbook.
AnswerC

The error indicates SSH password authentication is failing; setting ask_pass = true allows Ansible to prompt for the SSH password.

Practice this question →
68
MCQmedium

A playbook uses roles with default variables. The administrator needs to override a default variable for a specific role only when that role is used. Which method should be used?

A.Set the variable in the inventory host_vars.
B.Pass the variable as a parameter to the role in the playbook.
C.Set the variable in the role's vars/main.yml.
D.Set the variable in the playbook's vars section.
AnswerB

Role parameters take precedence over defaults and are specific to that role invocation.

Why this answer

When you need to override a default variable for a specific role only when that role is used, the correct method is to pass the variable as a parameter to the role in the playbook using the `vars` keyword within the role declaration. This ensures the override applies exclusively to that role invocation, without affecting other roles or the global playbook scope.

Exam trap

The trap here is that candidates confuse the scope of playbook-level `vars` with role-specific parameter passing, assuming any variable set in the playbook's `vars` section will only affect the role, when in fact it applies to all tasks in the play.

How to eliminate wrong answers

Option A is wrong because setting the variable in inventory host_vars applies the value to all plays and roles targeting that host, not just a specific role invocation. Option C is wrong because modifying the role's vars/main.yml would change the default for every use of the role, defeating the purpose of a one-time override. Option D is wrong because setting the variable in the playbook's vars section makes it available to all roles and tasks in the play, not exclusively to the targeted role.

Practice this question →

Ready to test yourself?

Try a timed practice session using only Manage task execution and roles questions.

Start 20-question session