EX294 Implement advanced Ansible automation — 15 Questions

Question 1

An Ansible playbook fails intermittently when deploying web servers. The error message indicates that a required package is not available in the repository. Which approach would best ensure that the required packages are consistently available before the playbook runs?

Accepted Answer

Add a pre_task to run 'dnf update' or 'apt update' before the package installation.. Option C is correct because the intermittent failure is caused by the package metadata cache being stale or missing. Running 'dnf update' (RHEL/CentOS) or 'apt update' (Debian/Ubuntu) as a pre_task refreshes the repository index, ensuring that the package manager has the latest list of available packages before attempting installation. This directly resolves the 'package not available' error by synchronizing the local cache with the remote repository.

Answer

Set 'ignore_errors: yes' on the package installation task and handle the failure later.

Answer

Add retries and delay to the package installation task.

Answer

Use the 'get_url' module to download the package from an external source and install it manually.

Question 2

An administrator wants to reuse a set of tasks that configure a firewall across multiple playbooks. Which Ansible feature should be used to achieve this?

Accepted Answer

Create a role for firewall configuration.. A role is the correct Ansible feature for reusing a set of tasks across multiple playbooks. Roles provide a structured, self-contained directory layout for tasks, handlers, variables, templates, and files, allowing the firewall configuration logic to be packaged once and referenced in any playbook via the `roles:` directive or `import_role`/`include_role` modules.

Answer

Add the tasks to the inventory file under a group.

Answer

Define the tasks in a vars file and include it.

Answer

Define the tasks as handlers and notify them.

Question 3

A playbook uses the 'include_tasks' module to dynamically include tasks based on a variable. The playbook runs successfully on some hosts but fails on others with a 'template error' message. What is the most likely cause?

Accepted Answer

The variable used in the 'include_tasks' path has a Jinja2 template error.. The 'include_tasks' module dynamically resolves the path to a task file using a variable. If that variable contains a Jinja2 template error (e.g., undefined variable, syntax mistake, or filter misuse), Ansible will fail with a 'template error' message during the variable expansion phase, before the task file is even loaded. This explains why the error occurs only on hosts where the variable's value or context triggers the template failure.

Answer

The included task file does not exist on the control node.

Answer

The included task file has incorrect permissions.

Answer

The included tasks contain a syntax error.

Question 4

An Ansible playbook is designed to run on a group of database servers. The administrator wants to ensure that a task runs only on the primary database server, which is defined in the inventory with a variable 'primary: true'. Which conditional should be used?

Accepted Answer

when: primary. Option B is correct because the `when` conditional in Ansible evaluates a Jinja2 expression to determine whether a task should execute. By using `when: primary`, the task will run only on hosts where the inventory variable `primary` is defined and evaluates to `true` (a truthy value). This directly meets the requirement to target the primary database server.

Answer

ignore_errors: yes

Answer

run_once: true

Answer

delegate_to: "{{ primary }}"

Question 5

A playbook uses the 'block' and 'rescue' keywords to handle errors. The block contains three tasks. The first task fails. What happens next?

Accepted Answer

The rescue section runs immediately after the failure.. In Ansible, when a task inside a `block` fails, the `rescue` section is executed immediately after the failure, without running any remaining tasks in the block. This is analogous to a try-catch mechanism in programming: the block is the 'try', and the rescue is the 'catch'. Option B correctly describes this behavior.

Answer

The rescue section runs and retries the failed task.

Answer

The playbook fails with an error message.

Answer

The remaining tasks in the block run, then the rescue section runs.

Question 6

An administrator needs to securely pass a database password to a playbook without exposing it in logs or the command line. Which approach is the most secure?

Accepted Answer

Store the password in an Ansible Vault-encrypted variable file and include it.. Option A is correct because Ansible Vault encrypts the variable file at rest, and including it via `vars_files` or `include_vars` decrypts it only in memory during playbook execution. This prevents the password from appearing in logs, the command line, or the process table, meeting the security requirement.

Answer

Set the password in a variable and use 'no_log: true' on tasks that use it.

Answer

Store the password in a host_vars file with restricted file permissions.

Answer

Prompt for the password and pass it as an extra variable using -e.

Question 7

A system administrator wants to run a playbook on all hosts in the 'webservers' group, but only if the host is currently online. Which approach should be used?

Accepted Answer

Use 'wait_for_connection' as a pre-task to ensure connectivity.. Option D is correct because the `wait_for_connection` module is specifically designed to pause the playbook execution until a remote host becomes reachable over SSH or WinRM. By placing it as a pre-task, the playbook will only proceed to subsequent tasks for hosts that are currently online, effectively filtering out offline hosts. This directly meets the requirement to run the playbook only on hosts in the 'webservers' group that are online.

Answer

Set 'gather_facts: no' to skip fact collection.

Answer

Use 'throttle: 1' to limit concurrent connections.

Answer

Set 'serial: 1' to run on one host at a time.

Question 8

An Ansible playbook includes a role that defines default variables in 'defaults/main.yml' and role variables in 'vars/main.yml'. A playbook sets the same variable in the play's 'vars' section. Which variable value takes precedence?

Accepted Answer

Play vars. In Ansible, variable precedence is hierarchical, and play vars (set directly in the play's `vars` section) have a higher priority than role defaults and role vars. Specifically, play vars override role vars, which in turn override role defaults. Therefore, when the same variable is defined in all three locations, the play vars value takes precedence.

Answer

Role defaults

Answer

Inventory group vars

Answer

Role vars

Question 9

Which TWO statements about Ansible collections are correct?

Accepted Answer

Collections provide a way to package and distribute Ansible content.. Ansible collections are a distribution format for Ansible content that allows packaging and distributing playbooks, roles, modules, and plugins. They enable users to bundle related automation content into a single, versioned package that can be shared via Ansible Galaxy or Automation Hub. This makes option B correct because collections are explicitly designed for packaging and distribution.

Answer

Collections cannot be versioned.

Answer

Collections replace the need for inventory files.

Answer

Collections can only contain modules and roles.

Question 10

Which THREE of the following are valid uses of the 'ansible.builtin.include_role' module?

Accepted Answer

Pass variables to the included role using the 'vars' keyword.. Option A is correct because the 'ansible.builtin.include_role' module supports the 'vars' keyword to pass variables directly to the included role. This allows you to override or supply role variables at the point of inclusion, which is a common pattern for reusing roles with different configurations.

Answer

Dynamically set the role name using a variable without the 'name' parameter.

Answer

Apply tags to all tasks within the included role.

Question 11

Which TWO of the following are advantages of using 'ansible-pull' over 'ansible-playbook'?

Accepted Answer

It can be used in environments where a central control node is not desired.. Option A is correct because ansible-pull operates in a pull-based model where each managed node independently retrieves and executes playbooks from a central repository (e.g., a Git server). This eliminates the need for a persistent central control node, making it ideal for environments where a dedicated Ansible control node is not desired or feasible, such as in large-scale or decentralized deployments.

Answer

It eliminates the need for an inventory file.

Answer

It supports a different syntax for playbooks that is more efficient.

Answer

It reduces load on the control node because it runs locally on each node.

Question 12

You are managing a large infrastructure of 500 Linux servers. The servers are divided into groups: 'web', 'app', and 'db'. Each group has specific configuration requirements. You have developed a set of Ansible roles to manage these configurations. Recently, you noticed that when you run the playbook against all servers, the 'web' role is applied to 'app' servers due to a variable misconfiguration. The playbook uses include_role with a variable that determines which role to apply. The variable is defined in group_vars/all.yml as 'server_role: web'. However, each group should have its own role: 'web' for web servers, 'app' for app servers, 'db' for db servers. The playbook includes the role based on '{{ server_role }}'. What is the best course of action to fix this issue without modifying the playbook structure?

Accepted Answer

Define the server_role variable in group_vars/web.yml, group_vars/app.yml, and group_vars/db.yml with the appropriate values.. Option C is correct because Ansible's variable precedence dictates that group_vars/<group_name>.yml files override group_vars/all.yml for hosts in that group. By defining `server_role` per group file (web, app, db), each server gets the correct role without modifying the playbook structure. This leverages Ansible's built-in group variable inheritance to resolve the misconfiguration cleanly.

Answer

Change the variable in group_vars/all.yml to a list and use 'include_role' with loop.

Answer

Add a 'when' condition to the include_role task to check the group name.

Answer

Define the server_role in host_vars for each server.

Question 13

You have an Ansible playbook that uses the 'lineinfile' module to manage the /etc/ssh/sshd_config file. The playbook runs without errors, but after execution, the SSH service becomes unreachable on some hosts. Investigation reveals that the file contains duplicate lines for 'Port 22' and 'PermitRootLogin no'. The playbook uses the following task:

- name: Ensure SSH settings
  ansible.builtin.lineinfile:
    path: /etc/ssh/sshd_config
    regexp: "^{{ item.key }}"
    line: "{{ item.key }} {{ item.value }}"
  loop:
    - { key: 'Port', value: '22' }
    - { key: 'PermitRootLogin', value: 'no' }

The playbook is run multiple times. What is the most likely cause of the duplicate lines?

Accepted Answer

The regexp pattern does not match the existing lines exactly, causing new lines to be added instead of replacing.. Option A is correct because the regexp pattern `^{{ item.key }}` matches only the start of a line (e.g., `^Port` or `^PermitRootLogin`), but the existing lines in `/etc/ssh/sshd_config` may have leading spaces or tabs (common in SSH config files). Since the regex does not match the actual line due to whitespace, the `lineinfile` module inserts a new line instead of replacing the existing one. Each playbook run adds another duplicate, eventually causing SSH to fail due to conflicting directives.

Answer

The 'lineinfile' module is not idempotent when used with loops.

Answer

The loop should use 'with_items' instead of 'loop' for proper idempotence.

Answer

The 'line' parameter should use backreferences to avoid duplication.

Question 14

An Ansible automation team is designing a playbook to manage network devices. They need to ensure that the playbook can handle transient network failures by retrying failed tasks a specific number of times with a delay between retries. Which approach should they use?

Accepted Answer

Use the `until` loop with `retries` and `delay` parameters on the task.. The `until` loop with `retries` and `delay` parameters is the correct approach because it allows a task to be retried a specified number of times with a configurable pause between attempts, directly addressing transient network failures. This is a built-in Ansible feature for handling intermittent issues without additional error-handling constructs.

Answer

Set `max_fail_percentage` in the play to 0 and use `ignore_errors: yes` with a rescue block.

Answer

Use the `throttle` keyword to limit concurrent tasks and rely on idempotency.

Answer

Set `serial: 1` on the play to ensure only one host is processed at a time and rely on idempotency.

Question 15

An Ansible playbook that deploys a web application includes a task that uses the `uri` module to call an external API. The task occasionally fails due to API rate limiting. Which combination of keywords should be added to the task to automatically retry up to 5 times with a 30-second delay between attempts, and only fail if all retries are exhausted?

Accepted Answer

`register: result`, `until: result.status == 200`, `retries: 5`, `delay: 30`. Option B is correct because it combines `register` to capture the API response, `until` to check that `result.status` equals 200 (the HTTP success code), `retries: 5` to attempt the task up to five times, and `delay: 30` to wait 30 seconds between retries. This ensures the task only fails after all five retries are exhausted, which is the exact behavior needed to handle transient API rate limiting.

Answer

`register: result`, `until: status == 200`, `retries: 5`, `delay: 30`

Answer

`until: result.status == 200`, `retries: 5`, `delay: 30`

Answer

`register: result`, `retries: 5`, `delay: 30`