EX294 Manage task execution and roles Practice Test 2 — 15 Questions

Question 1

A playbook needs to load encrypted variables from a file vault.yml. The vault password is stored in a file vault-pass with restricted permissions. Which method securely loads the variables when running the playbook?

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

Run ansible-playbook playbook.yml --vault-password-file vault-pass. The `--vault-password-file` flag allows Ansible to read the vault password from a file with restricted permissions, enabling non-interactive decryption of `vault.yml` without exposing the password in the process list or requiring manual input. This method is secure when the vault password file has proper permissions (e.g., 600) and is stored in a controlled location.

Answer

Use include_vars: file: vault.yml without any additional configuration.

Answer

Run ansible-playbook with --ask-vault-pass to prompt for the password.

Answer

Set the environment variable ANSIBLE_VAULT_PASSWORD_FILE in the user's profile.

Question 2

An Ansible playbook that installs packages and configures services is not idempotent. Which two practices should be implemented to make it idempotent? (Choose two.)

Accepted Answer

Use the command module with the 'creates' parameter.. Option B is correct because using the command module with the 'creates' parameter makes the task conditional: Ansible checks whether the specified file or path already exists, and if it does, the command is skipped, preventing repeated execution and ensuring idempotency. Option C is correct because using state=present with package modules (such as yum, apt, or package) tells Ansible to install the package only if it is not already present, so re-running the playbook produces no changes when the package is already installed. Option A is not among the marked correct answers, and while notify handlers are useful, they only control when services restart and do not by themselves make package installation or command execution idempotent. Option D is incorrect because check_mode: yes only performs a dry run to preview changes without applying them, which does not make the playbook idempotent. Option E is incorrect because always_run: yes forces a task to run regardless of conditions, which increases non-idempotent behavior rather than preventing it.

Answer

Use notify handlers to restart services only on change.

Answer

Use check_mode: yes to preview changes.

Answer

Set always_run: yes on tasks.

Question 3

An administrator has a playbook with tasks tagged 'install', 'configure', and 'service'. There are no untagged tasks. They want to run only the tasks tagged 'install' and 'configure', skipping 'service'. Which three commands will achieve this? (Choose three.)

Accepted Answer

ansible-playbook site.yml --tags install,configure. Option A is correct because `--tags install,configure` passes a comma-separated list to Ansible, which runs only tasks carrying either the 'install' or 'configure' tag and skips 'service'. Option C is correct because, since there are no untagged tasks and only three tags exist, `--skip-tags service` excludes the 'service' tasks while all remaining 'install' and 'configure' tasks still run. Option E is correct because Ansible allows `--tags` to be specified multiple times, and the values are merged, so `--tags install --tags configure` is equivalent to `--tags install,configure`. Option B is not correct because `--tags configure --skip-tags install,service` runs only 'configure' tasks, omitting the required 'install' tasks. Option D is not correct because `--tags install --skip-tags service` runs only 'install' tasks, omitting the required 'configure' tasks.

Answer

ansible-playbook site.yml --tags configure --skip-tags install,service

Answer

ansible-playbook site.yml --tags install --skip-tags service

Question 4

You are responsible for managing a large fleet of web servers running Red Hat Enterprise Linux 8. You have an Ansible playbook that deploys a custom web application. The playbook uses several roles from Ansible Galaxy and includes tasks that require root privileges. Recently, users reported that the deployment fails intermittently with the error 'Timeout (12s) waiting for privilege escalation prompt'. You suspect that the issue is related to the become method and the SSH connection. The current inventory uses 'ansible_user: deploy' and 'ansible_become: yes' with default settings. The 'deploy' user has sudo privileges with NOPASSWD for all commands. However, the timeout occurs only on high-latency connections. Which change would most effectively resolve the timeout issue?

Accepted Answer

Set ansible_become_timeout to a higher value in the inventory.. The error 'Timeout (12s) waiting for privilege escalation prompt' is specifically about the become timeout, not the general SSH timeout. The correct fix is to increase the become timeout by setting 'ansible_become_timeout' to a higher value in the inventory or playbook. Option D correctly increases this timeout. Option A (forks) only affects parallelism. Option B (pipelining) reduces SSH round trips but does not change the become timeout. Option C (become password) is unnecessary because the user already has NOPASSWD sudo access.

Answer

Increase 'forks' to 20 to run more tasks in parallel.

Answer

Enable pipelining by setting 'pipelining = True' in ansible.cfg.

Answer

Set 'ansible_become_password' in the inventory.

Question 5

Your organization uses Red Hat Ansible Automation Platform (AAP) to manage job execution. You have created a job template that runs a playbook to configure application servers. The playbook uses a custom credential to access a remote database. Recently, the job started failing with 'Authentication failed' when connecting to the database. You have verified that the database credentials are correct. The credential in AAP is of type 'Machine' and is assigned to the job template. The playbook uses the 'mysql_db' module. Which step should you take to troubleshoot and resolve the issue?

Accepted Answer

Change the credential type to 'Database' and provide the appropriate username and password.. The 'Machine' credential type in AAP is designed for SSH/WinRM authentication to managed hosts and does not expose database username/password fields to the mysql_db module. The correct fix is to create a credential of type 'Database' (or a custom credential type that injects the DB credentials as extra variables) and assign it to the job template so the playbook receives the proper login_user and login_password variables.

Answer

Add the database password as an extra variable in the job template.

Answer

Modify the machine credential to include the database password as an SSH key.

Answer

Encrypt the database password using Ansible Vault and include it in the playbook.

Question 6

Your team uses ansible-pull to manage configuration of a large number of remote nodes. Each node is configured to pull the latest playbook from a Git repository every 30 minutes. Recently, some nodes started reporting 'ERROR! the role 'base' was not found'. The playbook depends on roles from a requirements.yml file that is stored in the same repository. The ansible-pull command on each node uses the default roles path (~/.ansible/roles). The Git repository contains the requirements.yml file but does not contain the actual role directories. What is the most likely cause and solution?

Accepted Answer

Add a pre_task to the playbook that runs 'ansible-galaxy install -r requirements.yml' before the roles are used.. With ansible-pull, each node pulls the repository and runs the playbook locally, but roles listed in requirements.yml are not automatically installed — ansible-pull does not invoke ansible-galaxy. Adding a pre_task that runs 'ansible-galaxy install -r requirements.yml' (with an appropriate roles path, e.g., --roles-path ./roles) before roles are referenced ensures the roles exist on the node at run time. This is the standard pattern for self-contained ansible-pull repositories.

Answer

Run ansible-galaxy install on the control node and distribute the roles via a separate channel.

Answer

Add the role directories directly to the Git repository and modify the playbook to reference them with a relative path.

Answer

Set the 'roles_path' in ansible.cfg on each node to include the repository's roles directory.

Question 7

A team is automating server configuration using Ansible. They have a custom role 'security' that updates firewall and SSH settings. They notice that when they apply the role to multiple hosts, the SSH configuration changes sometimes fail because the firewall blocks the SSH port before the SSH configuration is updated. They need to ensure that SSH configuration is updated first, then firewall rules are applied. They have defined both tasks in the same role. What should they do?

Accepted Answer

Split the role into two separate roles and use role dependencies to enforce order.. Role dependencies allow you to define that one role must be executed before another. By splitting the 'security' role into separate roles for SSH and firewall, and setting the firewall role to depend on the SSH role, Ansible will always execute the SSH role first, ensuring the SSH configuration is updated before firewall rules are applied. This enforces order at the role level, which is the correct approach when tasks within a single role cannot be reordered independently.

Answer

Use tags to control the sequence of tasks.

Answer

Use pre_tasks for SSH and post_tasks for firewall in the playbook.

Answer

Use the 'order' directive in the playbook to specify task order within the role.

Question 8

Refer to the exhibit. The administrator notices that the handler 'restart httpd' runs even though the httpd service was already running. Which change would ensure the handler only runs if the service configuration changes?

Accepted Answer

Use a separate handler for configuration changes and notify it from tasks that modify configuration files.. Handlers in Ansible fire only when notified by a task that reports 'changed'. If the 'restart httpd' handler is running even when httpd was already running, it means a task that does not actually modify configuration is notifying the handler. The correct fix is to notify the handler only from tasks that genuinely change configuration files, so the handler runs solely when a config change occurs. This aligns handler execution with the intended 'restart only on config change' semantics.

Answer

Add a condition to the handler to check if httpd is already running.

Answer

Set the handler to 'state: reloaded' instead of 'restarted'.

Answer

Move the 'Ensure httpd is running' task before the handler notification.

Question 9

Refer to the exhibit. When the playbook runs on target1, which value will nginx_port have in the role?

Accepted Answer

9090 (from host vars). Ansible variable precedence dictates that host variables (in this case, from host_vars) override role defaults, role vars, and playbook vars. Since nginx_port is defined in host_vars for target1 with value 9090, that value takes highest precedence among the listed sources, so the role will use 9090.

Answer

443 (from playbook vars)

Answer

8080 (from vars/main.yml)

Answer

80 (from defaults/main.yml)

Question 10

Refer to the exhibit. A playbook uses the 'webserver' role. The administrator runs the playbook and notices that the firewall configuration is not applied as expected. What is the most likely cause?

Accepted Answer

The 'permanent: yes' option requires a reload of firewalld, but the handler restarts the service instead of reloading it.. The firewalld module with 'permanent: yes' writes the rule to the persistent configuration but does not apply it to the running firewall until firewalld is reloaded. If the handler restarts firewalld instead of reloading it, the running configuration may not reflect the new permanent rule as expected in the playbook's flow, so the firewall change appears unapplied. The correct fix is to use a reload (or ensure the handler reloads) so the permanent rule takes effect immediately.

Answer

The handler is not triggered because the task uses 'notify' but the handler is in a different role.

Answer

The handler is not included in the role because handlers/main.yml is not automatically loaded.

Answer

The handler name 'restart firewalld' does not match the notification 'restart firewalld'.

Question 11

Refer to the exhibit. An administrator runs an Ansible playbook and gets an unreachable error. The administrator has set ansible.cfg as shown. Which configuration change would most likely resolve the issue?

Accepted Answer

Set 'ask_pass = true' in ansible.cfg.

Answer

Set 'become_ask_pass = false' in ansible.cfg.

Answer

Set 'host_key_checking = False' in ansible.cfg.

Answer

Add 'remote_user: root' to the playbook.

Question 12

Refer to the exhibit. The administrator defines a default variable 'db_port' in the role's defaults/main.yml. However, the playbook sets 'db_port: 3307' as a role parameter. After running the playbook, what is the value of 'db_port' on the target host?

Accepted Answer

3307

Answer

Undefined

Answer

An error occurs because of conflicting definitions.

Answer

3306

Question 13

Refer to the exhibit. A role 'timezone' sets the timezone twice to different values. The role also depends on 'ntp'. After running a playbook that applies this role to server1, what is the timezone on server1?

Accepted Answer

America/New_York

Answer

The timezone is not set because of the dependency on ntp.

Answer

UTC

Answer

An error occurs because two tasks set the timezone.

Question 14

An administrator is developing a role that must execute a sequence of tasks only when a specific package is installed. The tasks must be skipped entirely if the package is absent, and the condition must be evaluated once per host. Which approach should the administrator take?

Accepted Answer

Use the `when` clause on each task with a condition that checks package facts, and ensure `gather_facts` is enabled.. The requirement is to conditionally execute tasks based on whether a package is installed. Using a `when` clause on each task with a condition that checks package facts is the most straightforward and reliable method. This ensures that each task is evaluated individually against the host's package state. Enabling `gather_facts` is necessary to collect package information, making the condition valid.

Answer

Use `include_tasks` with a `when` clause to dynamically include a file containing the tasks, and rely on the included tasks to inherit the condition.

Answer

Use `import_tasks` with a `when` clause on the import statement, and assume the condition is evaluated at runtime for each host.

Answer

Define a handler that checks for the package and notifies the tasks, ensuring they run only after the package is confirmed installed.

Question 15

An administrator wants to run a playbook that applies a role only to hosts in the 'database' group, and the role should run after another role named 'common'. The playbook must ensure that if any host in the 'database' group fails, the playbook stops for all hosts. Which playbook structure achieves this?

Accepted Answer

- hosts: database
  roles:
    - common
    - database
  any_errors_fatal: true. The play must target the 'database' group, run the 'common' role before the 'database' role, and stop all hosts on any failure. The 'roles:' keyword executes roles in order, and 'any_errors_fatal: true' at the play level ensures that a failure on any host aborts the play for all hosts. The other options either reverse the role order, use invalid syntax, or use an incorrect directive.

Answer

- hosts: database
  tasks:
    - import_role: common
    - import_role: database
  any_errors_fatal: true

Answer

- hosts: database
  roles:
    - common
    - database
  max_fail_percentage: 0

Answer

- hosts: database
  roles:
    - database
    - common
  any_errors_fatal: true