EX294 Manage task execution and roles — Timed 15 Questions

Question 1

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.. Option A is correct because 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 2

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 3

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 4

Which TWO statements about Ansible roles are true?

Accepted Answer

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

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

Accepted Answer

Using the 'when' conditional. Option A is correct because 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 6

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 7

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 8

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. Option B is correct because 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 9

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.. Option B is correct because 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 10

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.. Option A is correct because 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 11

Which TWO statements about Ansible roles are correct?

Accepted Answer

Roles must follow a specific directory structure.. Option A is correct because 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 12

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 13

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.. Option B is correct because 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 14

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

Question 15

Match each systemd unit type to its description.