EX294 Manage task execution and roles — Timed 15 Questions

Question 1

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?

15 minute time limit — choose an answer to begin.

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 2

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 an Ansible role is a standardized directory structure whose subdirectories can hold tasks (tasks/main.yml), handlers (handlers/main.yml), variables (defaults/main.yml and vars/main.yml), templates (templates/), and files (files/), so a role can indeed include all of these content types. Option C is correct because roles are designed for reuse: once a role exists in a roles directory or is fetched via requirements.yml, any number of playbooks can invoke it, which is the primary purpose of packaging automation as a role. Option B is not correct as stated because roles are not defined inside a playbook; they are defined as separate directory structures and merely referenced in a playbook via the 'roles' keyword or the import_role/include_role modules. Option D is wrong because roles can be invoked with the classic 'roles:' keyword in a play, as well as with import_role and include_role, so include_role is not the only method. Option E is wrong because variables in a role's vars/main.yml have high precedence and can be overridden by playbook vars, extra vars, and other higher-precedence sources, so they are not immune to being overridden.

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 3

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 applies a Jinja2 expression to a task, allowing Ansible to decide at runtime whether that task should execute, which directly controls task execution flow. Option B is correct because 'block' groups multiple tasks and, combined with 'rescue' and 'always', provides structured error handling that determines whether subsequent tasks run or are skipped. Option D is correct because 'loop' (and its older equivalent 'with_items') iterates a task over a list of items, controlling how many times and with which values the task executes. Option C is not a control mechanism: 'register' only captures a task's return data into a variable for later use, it does not decide whether or how a task runs. Option E is not marked correct because, although 'with_items' is a valid legacy looping construct, it is not one of the three methods designated as correct here.

Answer

Using 'register' to store task output

Answer

Using the 'with_items' loop

Question 4

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 5

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.. 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.

Question 6

An Ansible playbook includes multiple roles. The administrator wants to ensure that a specific role's tasks are executed before any other roles, even if the roles are listed in a different order in the playbook. Which approach should be used?

Accepted Answer

Use the 'pre_tasks' section in the playbook to call the role.. The 'pre_tasks' section in an Ansible playbook runs before any roles listed in the 'roles' section, regardless of the order in which roles are defined. This allows the administrator to execute a specific role's tasks first by calling it within 'pre_tasks', ensuring it runs before all other roles.

Answer

Use the 'any_errors_fatal' setting.

Answer

Use role dependencies with 'allow_duplicates: no'.

Answer

Set the 'order' parameter in the role definition.

Question 7

A playbook uses roles with default variables. The administrator needs to override a default variable for a specific role only when that role is used. Which method should be used?

Accepted Answer

Pass the variable as a parameter to the role in the playbook.. When you need to override a default variable for a specific role only when that role is used, the correct method is to pass the variable as a parameter to the role in the playbook using the `vars` keyword within the role declaration. This ensures the override applies exclusively to that role invocation, without affecting other roles or the global playbook scope.

Answer

Set the variable in the inventory host_vars.

Answer

Set the variable in the role's vars/main.yml.

Answer

Set the variable in the playbook's vars section.

Question 8

An administrator wants to use an Ansible role from Ansible Galaxy but the role has a dependency on another role that is already installed. What should be done to avoid conflicts?

Accepted Answer

Set 'allow_duplicates: false' in the parent role's meta/main.yml.. (set allow_duplicates: false) is correct to prevent the dependency from running twice. Option B (force install) overwrites but doesn't prevent duplicate execution. Option C (collection) is a different concept. Option D (no action) would cause the role to run twice by default.

Answer

Define the dependency as a collection.

Answer

Use 'galaxy install --force' to overwrite.

Answer

No action needed; Ansible handles duplicates automatically.

Question 9

Refer to the exhibit. The administrator observes the output and is concerned because the 'Check on async job' task shows 'finished: 0'. What does this indicate?

Accepted Answer

The async job is still running.. In Ansible, when you run a task asynchronously with 'async' and 'poll', the task returns immediately with a job ID, and Ansible then polls the async job status. The output 'finished: 0' indicates that zero hosts have finished the async job at the time of the check. This means the job is still running on the managed hosts. The 'Check on async job' task is the polling task that waits for the async job to complete; if it shows 'finished: 0', it means the job has not yet completed, so it is still running.

Answer

The async job was not started.

Answer

The async job failed.

Answer

The async job has completed successfully.

Question 10

Refer to the exhibit. A playbook already includes the 'common' role in its roles list. The current role depends on 'common' with 'allow_duplicates: false'. How many times will the 'common' role run?

Accepted Answer

Once.. The 'common' role is already listed in the playbook's roles list, and the current role declares a dependency on 'common' with 'allow_duplicates: false'. In Ansible, when a role dependency is defined with 'allow_duplicates: false', Ansible checks if the role has already been executed in the current play. Since 'common' is already in the roles list, it will not run again, resulting in a single execution.

Answer

Not at all.

Answer

Depends on the order of roles.

Answer

Twice.

Question 11

A playbook uses a loop to create multiple users. The administrator notices that if one user creation fails, the entire playbook stops. Which directive should be used to continue executing remaining iterations?

Accepted Answer

ignore_errors. `ignore_errors` is a directive that, when set to `yes` on a task, allows Ansible to continue executing subsequent iterations of a loop even if that specific task fails. This ensures that a failure in creating one user does not halt the entire playbook, as Ansible will record the failure but proceed with the remaining items in the loop.

Answer

max_fail_percentage

Answer

any_errors_fatal

Answer

failed_when

Question 12

A playbook uses ansible.builtin.import_playbook to include other playbooks. The administrator needs to pass variables to the imported playbook. Which approach is valid?

Accepted Answer

Add a 'vars' block to the import_playbook statement. `ansible.builtin.import_playbook` supports a `vars` keyword directly in the import statement, allowing you to pass variables to the imported playbook at the time of import. This is the only built-in method that passes variables into the imported playbook's scope without relying on external files or facts.

Answer

Use ansible.builtin.include_vars inside the imported playbook

Answer

Set variables using set_fact before the import

Answer

Use group_vars or host_vars

Question 13

Which THREE directives can be used to modify loop behavior in Ansible?

Accepted Answer

ignore_errors. Option A, ignore_errors, is correct because setting ignore_errors: true on a task lets the play continue even when an iteration of a loop fails, effectively modifying loop behavior by preventing a failed item from aborting the run. Option B, loop_control, is correct because it is the dedicated directive for tuning loop execution, allowing keys such as loop_var (to rename the item variable), index_var, label, pause, and extended to control iteration naming, indexing, and pacing. Option C, when, is correct because a conditional applied to a looping task is evaluated per iteration, so items that do not satisfy the condition are skipped, thereby altering which loop iterations actually execute. Option D, rescue, is not correct here because it is a block-level keyword that handles failures for an entire block, not a directive that modifies loop behavior. Option E, always, is likewise a block-level keyword that runs tasks regardless of success or failure and does not change how a loop iterates.

Answer

rescue

Answer

always

Question 14

An administrator sees this output during a playbook run. What can they conclude?

Accepted Answer

The task had ignore_errors set to yes. When a task fails in Ansible but the playbook continues execution and shows a 'changed' or 'ok' status instead of 'failed', it indicates that the task has `ignore_errors: yes` set. This directive tells Ansible to treat any failure as a success, allowing the play to proceed without interruption.

Answer

The playbook was run with the --ignore-errors command-line flag

Answer

The task was part of a block with rescue

Answer

The playbook was run with the --check flag

Question 15

A DevOps engineer wants to run an Ansible playbook inside a specific execution environment (EE) that includes custom collections. The EE image is stored in a private registry requiring authentication. The engineer has configured a container credential file. Which command will execute the playbook using the EE and the credential file?

Accepted Answer

ansible-navigator run -m stdout --ce docker --container-image registry.example.com/custom-ee --container-auth-file auth.json. `ansible-navigator` uses the `--container-auth-file` flag to specify a container credential file (typically in JSON format) for authenticating to a private registry. The `-m stdout` flag sets the execution mode to stdout, and `--ce docker` selects Docker as the container engine. This command correctly references the EE image and the auth file, enabling the playbook to run inside the authenticated custom execution environment.

Answer

ansible-navigator run -m stdout --ce docker --container-image registry.example.com/custom-ee --container-auth-file credentials.yml

Answer

ansible-navigator run --pp never --ce docker --container-image registry.example.com/custom-ee

Answer

ansible-navigator run -m stdout --pp never --ce docker --container-image registry.example.com/custom-ee --container-credential-file credentials.yml