EX294 Implement advanced Ansible automation — 20 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`

Question 16

A systems administrator needs to run a playbook that applies configuration changes to a set of servers. They want to ensure that if any task fails on a host, the playbook continues with the next host without aborting the entire play. Which play-level keyword should they use?

Accepted Answer

`ignore_errors: yes` on each task that might fail.. Option D is correct because `ignore_errors: yes` on each task ensures that if a task fails on a host, the playbook continues executing subsequent tasks on that host and moves on to the next host without aborting the entire play. This directly meets the requirement to continue with the next host upon task failure.

Answer

Set `gather_facts: no` to skip fact gathering and reduce failure points.

Answer

Set `any_errors_fatal: true` at the play level.

Answer

Set `force_handlers: true` at the play level.

Question 17

An Ansible automation engineer is developing a role that manages a microservice. The role needs to include conditional tasks based on whether a variable `microservice_version` is defined. If defined, it should use that version; otherwise, it should default to `latest`. Which of the following is the most efficient and idiomatic way to implement this default value within the role?

Accepted Answer

In the task: `image: "myimage:{{ microservice_version | default('latest') }}"`. Option D is correct because it uses the `default` filter directly in the task to set a fallback value for `microservice_version` when it is undefined. This is the most efficient and idiomatic approach in Ansible, as it avoids modifying role defaults or introducing extra variables, and it handles the conditional logic inline without unnecessary complexity.

Answer

In `defaults/main.yml`: `microservice_version: latest` and reference `{{ microservice_version }}` in the task.

Answer

In the task: `image: "myimage:{{ microservice_version }}"` and use `| mandatory` to fail if undefined.

Answer

In the task: `vars: microservice_version: "{{ microservice_version | default('latest') }}"`

Question 18

Which TWO statements about Ansible roles are correct? (Select exactly 2)

Accepted Answer

Roles can have dependencies on other roles defined in `meta/main.yml`.. Option B is correct because Ansible roles can declare dependencies on other roles in their `meta/main.yml` file using the `dependencies` keyword. This ensures that dependent roles are executed before the dependent role, enabling modular and reusable automation workflows.

Answer

A role can directly include tasks from another role using the `include_tasks` module.

Answer

Variables defined in `defaults/main.yml` override those in `vars/main.yml`.

Answer

Roles cannot include playbooks.

Question 19

Your team is responsible for managing a fleet of 200 RHEL 8 servers using Ansible Tower. You have been asked to implement a secure automation workflow that meets the following requirements:

1. All playbooks must be stored in a private Git repository hosted on an internal GitLab server.
2. Credentials to access the Git repository must be stored securely in Ansible Tower.
3. The automation must run on a schedule every night at 2:00 AM.
4. If a playbook run fails, the team must be notified via email.
5. The playbooks require SSH private keys to connect to the managed hosts; these keys must be stored securely.
6. A development team needs to be able to launch the same job template manually, but they must not be able to modify the job template or view the credentials.

You have created a Machine Credential for SSH and a Source Control Credential for Git. You have also created a Job Template that references the project, inventory, and credentials. What is the correct sequence of steps to satisfy all requirements?

Accepted Answer

1. Create a Project in Tower, pointing to the Git repository and associate the Source Control Credential. 2. Create a Job Template referencing the Project, and add the Machine Credential. 3. Assign the development team read and execute permissions on the Job Template (not admin). 4. Create a Schedule for the Job Template to run at 2:00 AM. 5. Configure a Notification Template for email on failure and associate it with the Job Template.. Option D is correct because it correctly sequences the steps: first creating a Project with the Source Control Credential to securely access the private Git repository, then creating a Job Template that references the Project and includes the Machine Credential for SSH access to managed hosts. Assigning the development team 'read and execute' permissions (not admin) satisfies the requirement that they can launch the job template manually but cannot modify it or view credentials. Creating a Schedule for 2:00 AM and configuring a Notification Template for email on failure completes the automation workflow.

Answer

1. Create a Project in Tower, pointing to the Git repository and associate the Source Control Credential. 2. Create a Job Template referencing the Project. 3. Add the Machine Credential to the Job Template. 4. Create a Schedule for the Job Template. 5. Assign the development team execute-only permissions on the Job Template. 6. Configure a Notification Template for email on failure.

Answer

1. Create a Schedule for 2:00 AM. 2. Create a Project in Tower with Source Control Credential. 3. Create a Job Template with Machine Credential. 4. Assign the development team admin permissions on the Job Template. 5. Configure a Notification Template.

Answer

1. Create a Project in Tower, pointing to the Git repository without a credential. 2. Create a Job Template referencing the Project. 3. Add the Source Control Credential to the Job Template. 4. Create a Schedule for the Job Template. 5. Assign the development team read-only permissions on the Job Template. 6. Configure a Notification Template for email on failure.

Question 20

An engineer runs the playbook as shown. What is the expected result?

Accepted Answer

The 'configure firewall' task is executed, the 'enable service' task is skipped, and the playbook continues to the next play.. Option B is correct because the playbook uses the `block` and `rescue` keywords. The 'configure firewall' task runs first and fails (e.g., due to a syntax error or connectivity issue). The `rescue` block then executes the 'enable service' task. However, the `always` block (which contains 'start service') is not present, so the playbook does not execute any 'always' tasks; instead, it proceeds to the next play after the rescue block completes. The 'start service' task is not part of the block/rescue structure and is skipped because the play moves to the next play after the rescue.

Answer

Only the 'configure firewall' task is executed; the rest are skipped.

Answer

All tasks are executed and the playbook completes successfully.

Answer

The 'configure firewall' and 'enable service' tasks are executed; the 'start service' task is skipped.