EX294 Manage task execution and roles Practice Test 3 — 15 Questions

Question 1

An administrator is designing a playbook that must use a role from Ansible Galaxy. The role requires variables to be passed at runtime, and the administrator wants to ensure that the role's default variables are overridden only when specific conditions are met. Which TWO methods can be used to pass variables to a role? (Choose two.)

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

Define the variables in the play's 'vars' section.. The two correct methods are defining variables in the play's 'vars' section and using the 'vars' keyword under the role in the 'roles' list. Both override role defaults. The other options either set defaults, use indirect fact setting, or are dynamic inclusion methods not specified in the scenario.

Answer

Use the 'set_fact' module before the role inclusion.

Answer

Define the variables in the role's 'defaults/main.yml' file.

Answer

Use the 'include_role' module with the 'vars' keyword.

Question 2

An administrator is writing a playbook that must execute a role named 'nginx' only on hosts that have the variable 'enable_nginx' set to true. The role should be executed after a task that gathers custom facts. Which two approaches will correctly conditionally execute the role? (Choose two.)

Accepted Answer

Use 'include_role' with a 'when' clause: '- include_role:
    name: nginx
  when: enable_nginx | bool'. Both a 'when' clause on a role entry under 'roles:' and a conditional 'include_role' task correctly execute a role only when the condition is true. The 'when' on 'roles:' applies to all tasks in the role, while 'include_role' dynamically includes the role based on the condition. 'import_role' is static and its 'when' applies to tasks but does not prevent parsing, which can cause issues. Using 'vars' to define 'when' is invalid, and 'meta: end_play' affects all hosts.

Answer

Define the role in 'roles:' and set a condition using 'vars' on the role entry: '- role: nginx
  vars:
    when: enable_nginx | bool'

Answer

Use a task with 'meta: end_play' before the role if the condition is false, and then include the role unconditionally.

Answer

Use 'import_role' with a 'when' clause: '- import_role:
    name: nginx
  when: enable_nginx | bool'

Question 3

A playbook uses `ansible.builtin.import_playbook` to include other playbooks. The administrator needs to pass variables to the imported playbooks so that they can use them. Which method should be used?

Accepted Answer

Pass variables using the `--extra-vars` command-line option when running the playbook.. To pass variables to playbooks imported with `ansible.builtin.import_playbook`, the `--extra-vars` command-line option is the correct method. Extra variables are globally available and have high precedence, ensuring they are accessible in the imported playbooks. Other methods like defining `vars` in the importing playbook or using `set_fact` do not propagate to separate playbooks.

Answer

Define the variables in the `vars` section of the importing playbook, and they will automatically be available to the imported playbooks.

Answer

Use the `vars` keyword directly on the `import_playbook` statement to pass variables to the imported playbook.

Answer

Use the `set_fact` module in the importing playbook to define variables, and they will be inherited by the imported playbooks.

Question 4

A playbook uses `import_role` to include a role named `db`. The role contains tasks that use variables `db_port` and `db_user`. The administrator wants to override these variables only for this import, without changing the role's defaults. Which syntax is correct?

Accepted Answer

- import_role:
    name: db
  vars:
    db_port: 5433
    db_user: admin. To override role variables for a specific import_role, use the vars keyword at the task level. This provides variables with higher precedence than role defaults. Other syntaxes either misuse parameters, use dynamic include instead of static import, or incorrectly use args instead of vars.

Answer

- import_role:
    name: db
  args:
    db_port: 5433
    db_user: admin

Answer

- include_role:
    name: db
  vars:
    db_port: 5433
    db_user: admin

Answer

- import_role:
    name: db
    db_port: 5433
    db_user: admin

Question 5

An administrator is creating a role that needs to execute a set of tasks conditionally based on whether a package is installed. The administrator wants to avoid duplicating the condition on every task. Which TWO methods can be used to group tasks and apply a condition to the entire group? (Choose two.)

Accepted Answer

Use a `block` with a `when` clause, and place all tasks inside the block.. To group tasks and apply a condition to the entire group, you can use a `block` with a `when` clause, which skips all tasks in the block if the condition is false. Alternatively, `include_tasks` with a `when` clause dynamically includes a file of tasks only if the condition is true, effectively grouping them. Both methods avoid duplicating the condition on each task.

Answer

Use a `block` with a `when` clause on the first task only, and rely on the condition being inherited by subsequent tasks.

Answer

Use a `block` with a `when` clause on the last task, and use `meta: flush_handlers` to apply the condition retroactively.

Answer

Use `import_tasks` with a `when` clause, and place all tasks in the imported file.

Question 6

An administrator is designing a playbook that must use a role from Ansible Galaxy. The role requires variables to be passed at runtime, and the administrator wants to ensure that the role's default variables are overridden only when specific conditions are met. Which TWO methods can be used to pass variables to a role? (Choose two.)

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

Use include_role in a loop with different vars for each iteration.. Dynamic inclusion with include_role allows looping with different variables, and include_tasks with a when condition enables runtime conditional task execution. Static imports do not support these behaviors effectively. Blocks with include_role do not provide looping with varying variables.

Answer

Use import_tasks with a when condition that references a runtime variable.

Answer

Use a block with a when condition and include_role inside it.

Answer

Use import_role with a loop to repeat the role with different vars.

Question 7

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?

Accepted Answer

Set 'hosts: web_servers' in the play.. 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.

Answer

Set 'hosts: all' and use '--limit web_servers' when running ansible-playbook.

Answer

Set 'hosts: localhost' and delegate tasks to web_servers.

Answer

Set 'hosts: all' and use a 'when' condition to check if the node is in the web_servers group.

Question 8

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?

Accepted Answer

defaults/main.yml. 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.

Answer

vars/defaults.yml

Answer

default_vars/main.yml

Answer

vars/main.yml

Question 9

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?

Accepted Answer

The AppStream repository is not enabled on the target host.. 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.

Answer

The 'yum' module is deprecated for RHEL 8; must use 'dnf'.

Answer

The remote host does not have subscription-manager access.

Answer

The package name is misspelled; it should be 'apache2'.

Question 10

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?

Accepted Answer

enabled: yes, state: started. 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.

Answer

enabled: yes, state: reloaded

Answer

enabled: yes, daemon_reload: yes

Answer

enabled: yes, state: restarted

Question 11

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

Accepted Answer

Ensure tasks are idempotent so they can be run multiple times without changing the system state beyond the desired state.. 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.

Answer

Use 'ignore_errors: yes' on all tasks to prevent playbook failures.

Answer

Always use serial execution to avoid race conditions.

Answer

Write tasks that rely on the previous task's output to ensure correct order.

Question 12

Which TWO statements about Ansible roles are correct?

Accepted Answer

Roles must follow a specific directory structure.. Option A is correct because Ansible roles rely on a defined directory layout (e.g., tasks/, handlers/, defaults/, vars/, files/, templates/, meta/, and the main.yml entry files) so that Ansible can automatically load each component without explicit includes. Option B is correct because Ansible Galaxy is the public repository and CLI for packaging, downloading, and sharing roles, so roles can indeed be distributed and installed via Galaxy (e.g., ansible-galaxy install). Option C is wrong because Ansible Galaxy is a role/content distribution hub, not a CI tool; CI for roles would be handled by tools like Jenkins, GitLab CI, or Molecule. Option D is wrong because role dependencies are declared in meta/main.yml under the dependencies key, not in a file named dependencies.yml. Option E is wrong because role names are plain directory names and do not use a .role extension.

Answer

Ansible Galaxy is a continuous integration tool for testing roles.

Answer

Role dependencies must be defined in a file named dependencies.yml.

Answer

Role names must have a .role extension.

Question 13

What is the most likely cause of the failure?

Accepted Answer

The nginx role's defaults or vars do not define 'nginx_version'.. 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.

Answer

The --check flag prevents role variable resolution.

Answer

The host web1 is not configured to use the nginx role.

Answer

The nginx role was not included in the playbook correctly.

Question 14

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?

Accepted Answer

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

Answer

Modify the role's defaults/main.yml to set libapp_version to 1.2.

Answer

Rename your playbook variable from lib_version to libapp_version in the play vars.

Answer

Create a file roles/web/vars/main.yml with libapp_version: 1.2.

Question 15

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

Accepted Answer

Create physical volume, then create volume group, then create logical volume, then format with filesystem, then mount the filesystem.. 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.

Answer

Create physical volume, then create logical volume, then create volume group, then format with filesystem, then mount the filesystem.

Answer

Create volume group, then create physical volume, then create logical volume, then format with filesystem, then mount the filesystem.

Answer

Create physical volume, then create volume group, then format with filesystem, then create logical volume, then mount the filesystem.