EX294 Manage task execution and roles — 10 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.