EX294 Manage task execution and roles — Timed 20 Questions

Question 1

Refer to the exhibit. The playbook fails with an error. What is the most likely cause?

Accepted Answer

import_tasks cannot be used with a loop.. `import_tasks` is a static import that is processed at playbook parse time, before any variables or loops are evaluated. Ansible does not support using `import_tasks` inside a loop (`loop:` or `with_items:`) because the import occurs once during parsing, not dynamically per iteration. To run tasks repeatedly, you must use `include_tasks`, which is processed dynamically at runtime and supports loops.

Answer

import_tasks must be placed in a role.

Answer

The loop variable should be referenced as '{{ item }}' without quotes.

Answer

The file names must be literal without templates.

Question 2

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 3

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 4

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?

Accepted Answer

The task lacks 'become: yes' but has 'become_user: root'. Add 'become: yes' to the task.. 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.

Answer

The remote path does not exist. Use 'remote_src: yes' to copy from remote.

Answer

The local source file is not readable by the user running ansible-playbook. Change permissions on the source file.

Answer

The remote file is owned by root and the destination directory is not writable by ansible. Use 'become: yes' and set 'owner: ansible'.

Question 5

Which TWO statements about Ansible roles are true?

Accepted Answer

A role can include tasks, handlers, variables, templates, and files.. 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.

Answer

Roles are defined directly inside a playbook using the 'roles' keyword.

Answer

Roles can only be invoked using the 'include_role' module.

Answer

Variables defined in a role's vars/main.yml cannot be overridden by playbook variables.

Question 6

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

Accepted Answer

Using the 'when' conditional. 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.

Answer

Using 'register' to store task output

Answer

Using the 'with_items' loop

Question 7

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

Accepted Answer

A dictionary with details about the user, such as uid, gid, and groups.. 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.

Answer

Just the username 'jdoe'.

Answer

The entire playbook YAML structure.

Answer

The string 'true' if the user was created successfully.

Question 8

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 9

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 10

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 11

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?

Accepted Answer

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

Answer

The repository URL might be incorrect on some servers. Use the 'uri' module to test connectivity to the repository.

Answer

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.

Answer

Add 'disable_gpg_check: yes' to the task to bypass the GPG check temporarily.

Question 12

Which TWO statements about Ansible roles are correct?

Accepted Answer

Roles must follow a specific directory structure.. 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.

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.

Question 16

Match each systemd unit type to its description.

Accepted Answer

service: Manages a system service (daemon). 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.

Answer

service: Triggers activation of other units based on time

Answer

timer: Manages a system service

Question 17

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?

Accepted Answer

Use the 'pre_tasks' section in the playbook to call the role.. 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.

Answer

Use the 'any_errors_fatal' setting.

Answer

Use role dependencies with 'allow_duplicates: no'.

Answer

Set the 'order' parameter in the role definition.

Question 18

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?

Accepted Answer

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

Answer

include_role

Answer

import_role

Answer

import_tasks

Question 19

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

Accepted Answer

Each host runs through the playbook independently of other hosts.. 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.

Answer

Playbook runs tasks on hosts in batches of 1.

Answer

Strategy is deprecated and replaced by 'linear'.

Answer

All hosts run the same task at the same time, then move to the next task.

Question 20

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?

Accepted Answer

Pass the variable as a parameter to the role in the playbook.. 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.

Answer

Set the variable in the inventory host_vars.

Answer

Set the variable in the role's vars/main.yml.

Answer

Set the variable in the playbook's vars section.