EX294 Implement advanced Ansible automation Practice Test 3 — 15 Questions

Question 1

Which TWO statements about Ansible roles are correct?

Accepted Answer

Ansible roles follow a predefined directory structure.. Ansible roles enforce a predefined directory structure (e.g., tasks/, handlers/, vars/, defaults/, meta/, templates/, files/) that organizes automation content into reusable components. This structure is required for Ansible to automatically locate and load role resources, making option A correct.

Answer

Roles enforce an execution order for tasks based on file naming.

Answer

A role can only be included once in a playbook.

Answer

Roles cannot have dependencies on other roles.

Question 2

Which TWO conditions are necessary for the 'local_action' directive to work as intended?

Accepted Answer

The task must be executed on the Ansible control node.. Options C and E are correct. For the 'local_action' directive to work as intended, the task must be executed on the Ansible control node (C) because local_action delegates the task to localhost. Additionally, the connection plugin must be set to 'local' (E) because local_action uses the local connection plugin to run commands on the control node without SSH. Option A is incorrect because local_action does not require an inventory entry for the control node; it implicitly uses localhost. Option B is incorrect because privilege escalation (become) is not a requirement for local_action; it can be used independently. Option D is incorrect because local_action is a shorthand directive, not a module; it is used instead of the 'action' keyword with delegate_to: localhost, but the key is that it runs locally with the local connection.

Answer

The inventory must contain an entry for the control node.

Answer

The task must have privilege escalation (become) enabled.

Answer

The 'local_action' module must be used instead of 'action'.

Question 3

Which THREE factors are essential for achieving idempotent behavior in Ansible plays?

Accepted Answer

Task execution order should not affect the final state.. Options A, B, and E are correct for achieving idempotent behavior in Ansible plays. A is correct because idempotent tasks should produce the same final state regardless of the order they are executed; this ensures consistency across multiple runs. B is correct because idempotent modules check the current state before making any changes, only acting when the desired state differs, which is fundamental to idempotency. E is correct because 'ignore_errors' should be used sparingly; overusing it can mask failures that would otherwise leave the system in a non-idempotent state, as subsequent runs may not correct hidden issues. C is incorrect because registered variables can be used in an idempotent manner; they do not inherently break idempotency. D is incorrect because loops can be idempotent if the module inside the loop is idempotent and the loop is designed to handle conditional changes.

Answer

Variables registered from previous tasks should be avoided.

Answer

Loops must be avoided because they always cause changes.

Question 4

Given the inventory above, which user will Ansible use when connecting to 'web2'?

Accepted Answer

deploy. In Ansible, the ansible_user variable set at the host level in the inventory takes precedence over group-level or global settings. If 'web2' has ansible_user=deploy defined in the inventory, Ansible will connect as 'deploy'. This is the most specific setting for that host and overrides defaults from ansible.cfg or group variables.

Answer

dbadmin

Answer

The system default user from ansible.cfg.

Answer

root

Question 5

The playbook above fails with 'template source file not found' for the copy task. Which change should be made to fix it?

Accepted Answer

Use the 'template' module instead of 'copy' for .j2 files.. The error 'template source file not found' occurs because the copy module does not process Jinja2 templates; it simply copies files as-is. When the source file has a .j2 extension and contains Jinja2 syntax, the template module must be used to render it. Therefore, changing to the template module resolves the issue.

Answer

Add 'delegate_to: localhost' to copy the file from the control node.

Answer

Set 'backup: no' because backup creates additional files.

Answer

Set 'gather_facts: yes' to allow Ansible to locate the template.

Question 6

Given the command and error above, what is the most likely cause of the failure?

Accepted Answer

The --vault-id syntax is incorrect; 'vault@prompt' should be a label and password source, not a vault file.. The `--vault-id` option expects a label and a password source (e.g., `vault@prompt` means the label is 'vault' and the password is prompted interactively). The error indicates that Ansible is interpreting the entire string as a vault file path, which fails because no file named 'vault@prompt' exists. Option C correctly identifies that the syntax is being misapplied.

Answer

The vault file 'vault@prompt' does not exist.

Answer

The vault password file must be encrypted with ansible-vault.

Answer

The --check flag is incompatible with vault encryption.

Question 7

An administrator needs to apply a set of firewall rules to multiple servers. They have created a playbook that uses the firewalld module. When running the playbook, they receive 'ERROR! module not found: firewalld'. The control node has the module available locally. What is the most likely cause?

Accepted Answer

The ansible.posix collection is not installed on the control node.. The error 'module not found: firewalld' indicates that Ansible cannot locate the firewalld module on the control node. In modern Ansible (2.10+), firewalld is part of the ansible.posix collection, not ansible-core. Even if the control node has the module available locally (e.g., via a different collection or older version), the playbook must reference it correctly. The most likely cause is that the ansible.posix collection is not installed on the control node, so Ansible cannot resolve the module. Installing the collection with 'ansible-galaxy collection install ansible.posix' resolves the issue.

Answer

The playbook uses the wrong module name.

Answer

The ansible.cfg has a wrong module path.

Answer

The module is not installed on the target nodes.

Question 8

A playbook must execute cleanup tasks after a block of tasks, both on success and failure. Which two of the following should be used within the block to achieve this?

Accepted Answer

always. To execute cleanup tasks after a block regardless of success or failure, use the block keyword to group the main tasks and the always keyword to define tasks that run unconditionally. The block + always pattern ensures cleanup runs even if the block fails. The other options do not achieve this: ignore_errors only prevents failures from stopping execution, rescue handles failures but only after a failure, and failed_when customizes failure conditions but does not guarantee cleanup execution.

Answer

ignore_errors

Answer

rescue

Answer

failed_when

Question 9

An organization uses Ansible to manage an AWS EC2 environment. The Ansible control node runs on a Linux server, and the team uses a dynamic inventory script (ec2.py) to automatically populate hosts. Recently, they need to run a playbook only against EC2 instances that have a specific tag, 'Environment', set to 'production'. The team has placed the ec2.ini configuration file in the same directory as the inventory script. However, when they run the playbook with '-i ec2.py', the playbook runs against all instances instead of only production ones. The team verifies that the tag exists on the correct instances and that the environment variable AWS_PROFILE is set correctly. Which action should resolve the issue?

Accepted Answer

Modify the ec2.ini file to include 'filters = tag:Environment=production' under the [ec2] section.. The ec2.py dynamic inventory script reads its configuration from ec2.ini, and the correct way to restrict discovery to instances with a specific tag is the 'filters' directive under the [ec2] section, using the AWS filter syntax 'tag:Environment=production'. This causes the underlying boto DescribeInstances call to pass the filter to the AWS API, so only matching instances are returned to Ansible's inventory. Once the filter is in place, running with '-i ec2.py' will populate only production-tagged hosts, and the playbook will target them exclusively.

Answer

Set the environment variable 'EC2_TAGS=Environment=production' before running the playbook.

Answer

Use the '--limit' option with the playbook command to specify the tag.

Answer

Add the option 'hostname = tag_Name' to the ec2.ini file.

Question 10

A DevOps team is developing a collection of Ansible roles to standardize web server deployments. One role, 'webserver-base', configures the firewall and installs common packages. Another role, 'webserver-app', depends on 'webserver-base' and adds application-specific configurations. The team wants to ensure that when 'webserver-app' is applied to a host, 'webserver-base' is automatically applied first. They currently have a 'meta/main.yml' file in 'webserver-app' that lists 'webserver-base' as a dependency. However, when they run a playbook that includes 'webserver-app' in a role list, they notice that 'webserver-base' runs after 'webserver-app' sometimes, causing configuration conflicts. They verify that the dependency is correctly defined and that no other roles are involved. What change should they make to ensure 'webserver-base' always runs before 'webserver-app'?

Accepted Answer

Set 'static: yes' in the dependency entry in the dependent role's meta/main.yml.. By default, role dependencies are executed before the dependent role. However, when roles are included dynamically (e.g., via `include_role`), the order may not be guaranteed. Setting `static: yes` in the dependency entry in `meta/main.yml` forces Ansible to statically inline the dependency at playbook parse time, ensuring that `webserver-base` always runs before `webserver-app`. Option B is correct because it directly addresses the ordering issue by making the dependency static. Option A is incorrect because `include_role` is a dynamic inclusion module, not a dependency type. Option C is incorrect because `order` is not a valid attribute for dependencies. Option D is a playbook-level workaround but does not enforce the dependency when the role is used elsewhere.

Answer

Change the dependency type to 'include_role' in the playbook to control ordering.

Answer

Add 'order: before' to the dependency entry in meta/main.yml.

Answer

Add a 'pre_tasks' section in the playbook to include 'webserver-base' before 'webserver-app'.

Question 11

An organization uses Ansible Tower to manage automation across different teams. One team has a job template that uses a custom Python virtual environment located at '/opt/custom_venv' to run a playbook that uses the 'docker_container' module from the 'community.docker' collection. The playbook runs successfully from the command line when using the '--ask-become-pass' option and the virtual environment activated. However, when the team runs the same playbook via the Ansible Tower job template, it fails with an error indicating that the 'docker_container' module is not found. The job template is configured to use the custom virtual environment under the 'CUSTOM VIRTUAL ENVIRONMENT' setting. The team confirms that the virtual environment has the collection installed (verified by running 'ansible-galaxy collection list' inside the venv). What is the most likely cause of the failure?

Accepted Answer

The Ansible Tower node executing the job does not have the custom virtual environment installed.. Ansible Tower (AWX) executes job templates on the Tower node itself (or on isolated nodes), not on the control machine where the playbook was tested. Even though the job template is configured with a custom virtual environment path, that path must exist on the Tower execution node; if the venv was only created on the developer's workstation, Tower cannot find the 'community.docker' collection and reports the module as missing.

Answer

The playbook should use the 'ansible_connection: local' directive to force local execution.

Answer

The 'community.docker' collection was installed in the default system-wide location instead of the custom virtual environment.

Answer

The job template's 'CUSTOM VIRTUAL ENVIRONMENT' setting points to a different path than '/opt/custom_venv'.

Question 12

An Ansible inventory file includes a group [webservers] containing web1. Another group [all] contains web1 and web2. When running a playbook with --limit webservers, the playbook fails on web2. Why does this happen?

Accepted Answer

The 'webservers' group includes web2 due to a misconfiguration.. The inventory file does not list web2 under the 'webservers' group; only web1 is listed. However, when running the playbook with --limit webservers, web2 is still targeted. This indicates a misconfiguration, such as a duplicate host entry, incorrect group assignment, or a faulty inventory script that inadvertently includes web2 in the webservers group. Ansible's --limit option restricts execution to hosts that are members of the specified group, so if web2 is not supposed to be in webservers but appears due to error, the playbook fails on web2 because it is unreachable or misconfigured for that role.

Answer

The SSH key for web2 is not authorized.

Answer

The inventory file has a syntax error causing web2 to be included in webservers.

Answer

The playbook's 'hosts' directive is set to 'all' instead of 'webservers'.

Question 13

Refer to the exhibit. A playbook fails with the error 'file not found: /var/www/app-v2.1.0.tar.gz' on the control node. What is the most likely cause?

Accepted Answer

The archive file does not exist on the control node. The copy task uses a relative path to the source file on the control node, which is not found.

Answer

The become: yes is missing from the copy task

Answer

The remote_src parameter is not set in the copy task

Answer

The unarchive task should use remote_src: no

Question 14

Refer to the exhibit. The playbook fails to install httpd on server1. Which is the most likely cause?

Accepted Answer

The target host is not registered with Red Hat Subscription Manager. The yum module requires the target host to have valid repositories configured. On Red Hat Enterprise Linux, repositories are provided through a subscription managed by Red Hat Subscription Manager (RHSM). If the host is not registered, yum cannot resolve the httpd package, causing the playbook to fail. The exhibit likely shows an error like 'No package httpd available' or a repository metadata failure, which points directly to missing subscriptions.

Answer

The ansible.cfg file has an incorrect module path

Answer

The target host does not have internet access

Answer

The yum module should use state: present instead of latest

Question 15

Refer to the exhibit. An admin wants to run a playbook on all hosts in the 'webservers' group. Which ansible-playbook command is correct?

Accepted Answer

ansible-playbook site.yml --limit webservers. The command uses --limit to target the specific group.

Answer

ansible-playbook site.yml -i webservers

Answer

ansible-playbook site.yml -e 'groups=webservers'

Answer

ansible-playbook site.yml --hosts webservers