Courseiva

Red Hat Certified Engineer EX294 (EX294) — Questions 451–520

520 questions total · 7pages · All types, answers revealed

Take a mock examExam hub
Page 6

Page 7 of 7

451
MCQeasy

An admin wants to build an execution environment using ansible-builder. Which file is required to define the base image and additional Python dependencies?

A.execution-environment.yml
B.requirements.yml
C.galaxy.yml
D.Dockerfile
AnswerA

execution-environment.yml is the correct file to define the base image and dependencies.

Why this answer

`execution-environment.yml` is the required file for `ansible-builder` to define the base image (via the `base_image` field) and additional Python dependencies (via the `python` section under `dependencies`). This YAML file serves as the build definition that `ansible-builder` reads to construct the container image, making it essential for creating custom execution environments.

Exam trap

Red Hat often tests the distinction between files used by different Ansible tools—candidates confuse `requirements.yml` (for collections/roles) or `galaxy.yml` (for collection metadata) with the `execution-environment.yml` file that is specifically required by `ansible-builder`.

How to eliminate wrong answers

Option B is wrong because `requirements.yml` is used by `ansible-galaxy` to install Ansible collections or roles, not by `ansible-builder` to define the base image or Python dependencies. Option C is wrong because `galaxy.yml` is a metadata file for Ansible collections (e.g., defining namespace, version, and dependencies), not for building execution environments. Option D is wrong because while `ansible-builder` internally generates a Dockerfile, the user does not provide it directly; the required input file is `execution-environment.yml`, which `ansible-builder` processes to produce the Dockerfile and build context.

Full explanation →
452
Multi-Selectmedium

An automation controller administrator needs to limit access to a sensitive inventory. Which two methods can be used to restrict access to that inventory? (Choose two.)

Select 2 answers
A.Assign the 'admin' role to the inventory and grant it only to specific users.
B.Place the inventory in an organization and assign appropriate roles to users and teams.
C.Use a custom role with read-only permissions on the inventory.
D.Encrypt the inventory with ansible-vault and share the vault password only with authorized users.
E.Set the inventory to 'private' in the inventory settings.
AnswersB, C

Organization RBAC controls access at the inventory level.

Why this answer

In Ansible Automation Platform, access to inventories is managed through Role-Based Access Control (RBAC) within organizations. Placing the inventory in an organization allows administrators to assign specific roles (e.g., Admin, Execute, Read) to users or teams, effectively restricting access. Additionally, using a custom role with read-only permissions ensures that users can view the inventory but cannot modify or delete it, providing a fine-grained access control mechanism.

Exam trap

The trap here is that candidates often confuse ansible-vault encryption (which protects data at rest or in transit) with RBAC access control (which governs who can view or modify resources in the controller), leading them to select Option D as a valid method for restricting inventory access.

Full explanation →
453
MCQmedium

A team wants to use a certified collection from Red Hat Automation Hub but cannot access it directly due to firewall restrictions. What is the best practice?

A.Download the collection manually and install from a tarball.
B.Set up a private Automation Hub and sync the collection.
C.Copy the collection from another team's workspace.
D.Use ansible-galaxy collection install with --offline flag.
AnswerB

Syncing to a private hub is the recommended way to manage collections in restricted environments.

Why this answer

Setting up a private Automation Hub and syncing the certified collection is the best practice for environments with firewall restrictions. This approach ensures that the collection remains in a trusted, curated state, is automatically updated, and can be consumed by all team members via `ansible-galaxy` without manual intervention, maintaining compliance with Red Hat's support policies.

Exam trap

The trap here is that candidates often assume manual download (Option A) is acceptable for firewall restrictions, but Red Hat's best practice emphasizes using a private Automation Hub to maintain supportability and consistency across the enterprise.

How to eliminate wrong answers

Option A is wrong because manually downloading and installing from a tarball bypasses the dependency resolution and version tracking provided by Automation Hub, leading to potential inconsistencies and unsupported configurations. Option C is wrong because copying a collection from another team's workspace introduces risks of untracked modifications, missing dependencies, and violates Red Hat's best practices for centralized, version-controlled content management. Option D is wrong because the `--offline` flag does not exist in `ansible-galaxy collection install`; the correct flag is `--no-deps` for offline scenarios, but this still requires the collection to be available locally and does not address the firewall restriction for initial access.

Full explanation →
454
MCQhard

Refer to the exhibit. An Ansible playbook targeting server1 fails with a permissions error when connecting. The administrator notices the SSH private key is being used. Which change will likely fix the issue?

A.Add `ansible_become: yes` to the playbook.
B.Remove ansible_ssh_common_args.
C.Change ansible_user to 'ec2-user'.
D.Set ansible_ssh_private_key_file to a different key.
AnswerC

ec2-user is the default for many cloud images.

Why this answer

The error indicates that the SSH private key being used does not correspond to the user attempting to connect. In many cloud environments like AWS, the default user for Amazon Linux 2 is 'ec2-user', and the SSH private key is tied to that user. Changing `ansible_user` to 'ec2-user' ensures the correct user context for key-based authentication, resolving the permissions error.

Exam trap

The trap here is that candidates often assume the SSH key itself is the problem (Option D) or that privilege escalation (Option A) will bypass authentication, when the real issue is a mismatch between the SSH user and the key's authorized user.

How to eliminate wrong answers

Option A is wrong because `ansible_become: yes` enables privilege escalation (e.g., sudo) after the initial SSH connection, but it does not fix an SSH authentication failure caused by a mismatched user/key pair. Option B is wrong because `ansible_ssh_common_args` is used to pass additional SSH arguments (like `-o ProxyJump`), and removing it would not address a user/key mismatch; it might even break connectivity if proxy settings were required. Option D is wrong because the exhibit states the SSH private key is being used, implying the key itself is correct; changing to a different key would not fix the issue if the problem is the user associated with that key.

Full explanation →
455
MCQhard

You have two dictionaries: `dict1: {a: 1, b: 2}` and `dict2: {b: 3, c: 4}`. You want a new dict that combines both, with `dict2` values taking precedence for overlapping keys. Which filter chain achieves this?

A.`dict2 | combine(dict1, recursive=True)`
B.`dict2 | combine(dict1)`
C.`[dict1, dict2] | combine`
D.`dict1 | combine(dict2)`
AnswerA

Correct: The recursive=True flag ensures that dict2 (the left operand) retains its values for overlapping keys, so b remains 3.

Why this answer

With recursive=True, the combine filter performs a deep merge where the left-hand operand (dict2) retains its values for overlapping keys when combined with dict1. This satisfies the requirement that dict2 values take precedence for the overlapping key 'b', resulting in {a: 1, b: 3, c: 4}.

Exam trap

The trap here is that candidates often confuse the order of precedence with the `combine` filter, mistakenly thinking the argument dictionary (the one inside the parentheses) takes precedence, when in fact the left-hand operand (the one piped into the filter) has its values overwritten by the argument.

How to eliminate wrong answers

Option A is wrong because `recursive=True` is used for nested dictionary merging, which is unnecessary here and does not affect the precedence logic; also, the order `dict2 | combine(dict1)` would give precedence to `dict1` for overlapping keys, not `dict2`. Option B is wrong because `dict2 | combine(dict1)` gives precedence to `dict1` (the argument to `combine`), so `b` would be 2 from `dict1`, not 3 from `dict2`. Option C is wrong because `[dict1, dict2] | combine` is not valid syntax; the `combine` filter requires an argument (the dictionary to merge in), and using a list with a pipe does not invoke the filter correctly.

Full explanation →
456
MCQmedium

Refer to the exhibit. A user includes this in the execution-environment.yml. The build process fails because the second collection cannot be resolved. What is the most likely reason?

A.The format of the version constraint is invalid.
B.The source URL does not include the required endpoint like '/api/v3/'.
C.The source URL is not a valid Galaxy server endpoint.
D.The second collection is not authorized for download.
AnswerC

The URL should be the root of a Galaxy server, like https://internal.galaxy.example.com, not with /api/ path.

Why this answer

The execution-environment.yml references a Galaxy server endpoint that is not a valid Ansible Galaxy server. Ansible Builder resolves collections from Galaxy servers, and if the URL does not point to a recognized Galaxy API endpoint (e.g., https://galaxy.ansible.com), the build process cannot fetch the collection. The error indicates the second collection cannot be resolved, which directly points to an invalid or unreachable Galaxy server URL.

Exam trap

Red Hat often tests the misconception that a Galaxy server URL must include the full API path, but in reality, Ansible Builder automatically appends the required endpoint, so the URL should be the base server address.

How to eliminate wrong answers

Option A is wrong because the version constraint format (e.g., '>=1.0.0') is standard and valid for Ansible collections; the error is about resolution, not syntax. Option B is wrong because Galaxy server URLs do not require an explicit '/api/v3/' endpoint; Ansible Builder automatically appends the correct API path when resolving collections. Option D is wrong because authorization errors typically produce a 403 or authentication failure message, not a generic 'cannot be resolved' error; the issue is the server endpoint itself is invalid.

Full explanation →
457
MCQhard

A team has developed several roles that share common variables. They want to organize these variables in a central file. Where should they place this file so it is automatically loaded by all roles?

A.In the inventory directory as host_vars/localhost.yml
B.In a common role's vars/main.yml
C.In a common role's defaults/main.yml
D.In the playbook directory as group_vars/all.yml
AnswerD

group_vars/all.yml is automatically included and applies to all hosts.

Why this answer

Placing a file in the playbook directory as group_vars/all.yml makes it automatically loaded by all roles. Ansible automatically includes any YAML files in the group_vars directory that match group names, and the special group 'all' applies to every host. This centralizes shared variables without requiring explicit imports in each role.

Exam trap

Red Hat often tests the distinction between role-level variable files (vars/main.yml and defaults/main.yml) and global variable files (group_vars/all.yml), trapping candidates who think a common role's vars/main.yml is automatically loaded by all roles when in fact it requires explicit role dependencies or includes.

How to eliminate wrong answers

Option A is wrong because host_vars/localhost.yml applies only to the localhost host, not to all hosts targeted by roles. Option B is wrong because vars/main.yml in a common role would require every other role to explicitly depend on or include that role, which is not automatic. Option C is wrong because defaults/main.yml in a common role defines default variables with the lowest precedence, which can be overridden by any higher-precedence variable source, making it unsuitable for central shared variables that should be consistently applied.

Full explanation →
458
MCQeasy

A junior admin created a custom credential type for a third-party API. When running a job that uses this credential, the job fails with 'type object 'Credentials' has no attribute' error. What is the most likely issue?

A.The 'inputs' section in the credential type definition has a misconfigured field name
B.The 'injectors' section in the credential type definition is missing
C.The credential is not assigned to the job template
D.The job template is missing the required extra variables
AnswerA

A typo in the input field name causes the attribute error when Ansible tries to access it.

Why this answer

The error 'type object 'Credentials' has no attribute' typically occurs when the credential type definition's 'inputs' section references a field name that does not match the actual attribute expected by the credential plugin or injector. In Ansible Tower/AWX, the 'inputs' section defines the fields a user fills in (e.g., username, password), and if a field name is misspelled or mismatched with what the credential plugin expects, the plugin cannot find the attribute, causing this error. Option A is correct because a misconfigured field name in 'inputs' directly leads to this attribute lookup failure.

Exam trap

The trap here is that candidates often assume the error is due to missing injection or credential assignment, but the specific 'has no attribute' error points directly to a mismatch between the input field names and the attribute names expected by the credential plugin.

How to eliminate wrong answers

Option B is wrong because a missing 'injectors' section would cause the credential to not inject any environment variables or extra vars, but the error would be about missing injection, not an attribute error on the Credentials object. Option C is wrong because if the credential is not assigned to the job template, the job would fail with a 'credential not found' or 'missing credential' error, not an attribute error on the Credentials object. Option D is wrong because missing extra variables would cause a variable lookup failure in the playbook, not an attribute error on the Credentials object itself.

Full explanation →
459
MCQmedium

Your team manages a large Ansible Tower environment with multiple organizations. Each organization has its own projects, inventories, and job templates. You need to create a set of cloud credentials (AWS access key) that can be used by any job template in any organization, but you want to restrict modification of the credential to only a few administrators. What is the best way to achieve this while maintaining flexibility?

A.Store the access key in an external secrets management vault and reference it via an encrypted file in the project.
B.Create a separate credential in each organization and synchronize the keys manually.
C.Create a custom credential type that all users create their own instance of.
D.Create a single credential in the global 'Default' organization and use Tower's RBAC to grant read access to all users and admin access to a few.
AnswerD

Global credentials are visible across organizations and RBAC controls permissions.

Why this answer

Ansible Tower's RBAC allows you to create a single credential in the global 'Default' organization and then assign read permissions to all users (allowing them to use the credential in job templates) while restricting admin (write/modify) access to a few administrators. This approach maintains flexibility by making the credential available across all organizations without duplication or manual synchronization.

Exam trap

The trap here is that candidates may think credentials must be created per organization (Option B) or that external vaults are required for security (Option A), but Red Hat tests your understanding of Tower's built-in RBAC and the Default organization's ability to share credentials across organizations.

How to eliminate wrong answers

Option A is wrong because storing the access key in an external secrets management vault and referencing it via an encrypted file in the project adds unnecessary complexity and does not leverage Tower's native credential management; it also bypasses Tower's RBAC controls. Option B is wrong because creating separate credentials in each organization and manually synchronizing keys is error-prone, does not scale, and violates the principle of centralized management. Option C is wrong because creating a custom credential type that all users create their own instance of would require each user to manage their own copy of the AWS access key, defeating the purpose of a shared credential and introducing security risks.

Full explanation →
460
MCQmedium

Refer to the exhibit. An Ansible user runs `ansible-navigator` from the `/home/user/project` directory. The execution environment image is not present locally. What will occur?

A.The container engine will default to docker because podman is not a valid engine.
B.The image will be pulled from the registry because the pull policy is 'missing'.
C.The volume mount will fail because the source path is not absolute.
D.The image will be pulled only if the --pull flag is passed on the CLI.
AnswerB

Correct: the pull policy 'missing' pulls the image when it is not locally available.

Why this answer

The default pull policy for `ansible-navigator` when using an execution environment is `missing`. This means that if the specified image is not present locally, the container engine (podman or docker) will automatically pull it from the configured registry. Since the image is not present locally, the pull will occur without requiring any additional flags.

Exam trap

The trap here is that candidates often assume `ansible-navigator` requires an explicit `--pull` flag to pull images, but the default `pull_policy: missing` automatically handles pulling when the image is not local, and they may also mistakenly think podman is invalid or that volume mounts require special handling.

How to eliminate wrong answers

Option A is wrong because podman is a valid container engine for `ansible-navigator` and is actually the default; the tool does not default to docker. Option C is wrong because the volume mount source path `/home/user/project` is an absolute path (starting with `/`), so it will not fail due to being non-absolute. Option D is wrong because the `--pull` flag is not required; the default pull policy of `missing` already triggers a pull when the image is absent.

Full explanation →
461
MCQhard

A developer wrote a custom filter plugin in a Python file `my_filters.py` and placed it in the directory `./filter_plugins/`. The playbook fails with 'ERROR! no filter named 'my_custom_filter''. The playbook is located in `/home/user/project/playbook.yml`. The `ansible.cfg` file in the same directory does not set `filter_plugins`. Which is the most likely cause?

A.The filter file must be named `__init__.py`
B.The plugin file must be a Python module with a class named `FilterModule` and the filter function must be listed in the `filters` method
C.The filter function must be imported in the playbook via `filter_plugins: my_filters`
D.The filter function name does not match the class name in the plugin
AnswerB

This is the required structure for filter plugins.

Why this answer

Ansible requires custom filter plugins to be Python modules that define a class named `FilterModule` with a `filters()` method returning a dictionary mapping filter names to their implementing functions. Without this structure, Ansible cannot discover or register the filter, causing the 'no filter named' error.

Exam trap

Red Hat often tests the misconception that the filter function name must match the class name or that the file must be named `__init__.py`, when in fact the critical requirement is the `FilterModule` class with a `filters()` method.

How to eliminate wrong answers

Option A is wrong because the filter file does not need to be named `__init__.py`; that naming is for Python packages, not individual plugin files. Option C is wrong because filters are not imported in the playbook via a `filter_plugins` directive; Ansible automatically loads plugins from the `filter_plugins` directory based on configuration. Option D is wrong because the filter function name does not need to match the class name; the mapping is defined in the `filters()` method's dictionary.

Full explanation →
462
MCQeasy

A system administrator wants to build an Ansible execution environment using ansible-builder. Which file format is required to define the base image, dependencies, and additional Python packages for the build?

A.execution-environment.yml
B.ansible-navigator.yml
C.Containerfile
D.requirements.yml
AnswerA

Correct. This is the standard file for ansible-builder.

Why this answer

`ansible-builder` requires an `execution-environment.yml` file to define the build context, including the base image (under `version: 1`), system-level dependencies (under `dependencies: system:`), and additional Python packages (under `dependencies: python:`). This file is the mandatory definition file for building an Ansible Execution Environment (EE) using `ansible-builder build`.

Exam trap

The trap here is that candidates confuse the build input file (`execution-environment.yml`) with the runtime configuration file (`ansible-navigator.yml`) or with the generated output (`Containerfile`), leading them to pick the wrong option.

How to eliminate wrong answers

Option B is wrong because `ansible-navigator.yml` is the configuration file for `ansible-navigator`, a tool used to run and inspect execution environments, not for building them with `ansible-builder`. Option C is wrong because a `Containerfile` (or `Dockerfile`) is a lower-level container build file that `ansible-builder` generates from `execution-environment.yml`; it is not the input file the administrator writes. Option D is wrong because `requirements.yml` is used by `ansible-galaxy` to install collections and roles, not by `ansible-builder` to define the base image or Python packages for an execution environment build.

Full explanation →
463
Multi-Selectmedium

An Ansible playbook uses the 'block' and 'rescue' directives. Which two statements are true about this construct? (Choose two.)

Select 2 answers
A.Rescue tasks are executed on all hosts in the play.
B.A rescue section executes only if the block tasks fail.
C.Blocks cannot be nested.
D.The 'always' section runs regardless of success or failure.
E.A block can have multiple rescue sections.
AnswersB, D

Rescue runs when a task in the block fails.

Why this answer

The 'rescue' section in an Ansible block is specifically designed to execute only when a task within the 'block' fails. This allows you to define error recovery or rollback steps that run only on hosts where the block encountered a failure, ensuring that successful hosts are not affected by rescue logic.

Exam trap

The trap here is that candidates often think 'rescue' runs on all hosts or that multiple rescue sections are allowed, confusing Ansible's block/rescue/always pattern with exception handling in programming languages like try-catch-finally.

Full explanation →
464
MCQmedium

A playbook uses 'vars_prompt' to ask for a confirmation before proceeding with destructive changes. However, when the playbook is run from a CI/CD pipeline, it hangs indefinitely. What is the best way to handle this?

A.Remove the prompt and always proceed.
B.Set ANSIBLE_STDOUT_CALLBACK=unixy to avoid interactive prompts.
C.Encrypt the confirmation in vault and include it.
D.Use --check mode to simulate.
E.Pass the variable via --extra-vars and modify the prompt to be conditional with 'when: variable is not defined'.
AnswerE

Correct: This allows non-interactive input from CI/CD and only prompts when variable is missing.

Why this answer

Passing the variable via --extra-vars and making the prompt conditional with 'when: variable is not defined' allows the pipeline to provide the variable non-interactively. Option A is unsafe. Option B's --check mode does not solve prompts.

Option C is unrelated. Option D encrypts data but does not handle prompts. Therefore, E is best.

Full explanation →
465
MCQeasy

An organization requires that all Ansible playbooks be executed using a specific service account that has limited permissions. The account can only run playbooks from a specific directory. Which approach best enforces this requirement in automation controller?

A.Use an inventory that contains only the allowed hosts.
B.Configure an execution environment that mounts the authorized directory as read-only.
C.Create a project that syncs only the authorized directory, and assign the service account as the only user with execute permissions on that project.
D.Assign the service account a machine credential that connects to the controller via SSH.
AnswerC

Projects control source of playbooks; RBAC can restrict execution to that project.

Why this answer

Automation Controller (formerly Ansible Tower) uses Projects to manage playbook source code. By creating a Project that syncs only the authorized directory and assigning the service account as the only user with execute permissions on that Project, you restrict the service account to running playbooks exclusively from that directory. This enforces the requirement at the platform level, leveraging role-based access control (RBAC) within the controller.

Exam trap

The trap here is that candidates confuse execution environments (containers) with project-level access controls, or mistakenly think inventory or credentials can restrict which playbook directory is used, when in fact only Project permissions enforce that restriction in Automation Controller.

How to eliminate wrong answers

Option A is wrong because an inventory defines which hosts to target, not which playbooks or directories the service account can execute; it does not restrict the playbook source location. Option B is wrong because execution environments are container images that provide runtime dependencies, not directory access controls; mounting a directory as read-only does not prevent the service account from running playbooks from other directories within the controller. Option D is wrong because a machine credential is used for SSH authentication to managed nodes, not for controlling which playbooks or directories the service account can access in Automation Controller.

Full explanation →
466
MCQeasy

A systems administrator needs to securely store a database password for use in an Ansible playbook. The password should be encrypted at rest and decrypted only at runtime when the playbook is executed. Which approach should the administrator take?

A.Store the password as a plain text variable in the playbook and use the no_log: yes directive to prevent logging.
B.Use the ansible-vault encrypt_string command to encrypt the password and store it in a variables file.
C.Store the password in an unprotected external file and reference it with include_vars.
D.Save the password in an environment variable and access it via lookup('env','DB_PASS').
AnswerB

Encrypts the password at rest; decrypted at runtime with vault password.

Why this answer

`ansible-vault encrypt_string` encrypts the password at rest using AES-256, storing it as a ciphertext string in a variables file. At runtime, when the playbook is executed with `--ask-vault-pass` or a vault password file, Ansible decrypts the value transparently, ensuring the plaintext password is never written to disk or logs.

Exam trap

The trap here is that candidates confuse runtime log suppression (`no_log`) with encryption at rest, or assume environment variables are secure because they are not stored in a file, overlooking that they remain unencrypted in process memory.

How to eliminate wrong answers

Option A is wrong because `no_log: yes` only suppresses output in logs; it does not encrypt the password at rest, leaving it exposed in the playbook file. Option C is wrong because storing the password in an unprotected external file and using `include_vars` provides no encryption, violating the requirement for encryption at rest. Option D is wrong because environment variables are stored in plaintext in the process's memory and can be leaked via `/proc` or core dumps; `lookup('env','DB_PASS')` does not provide encryption at rest.

Full explanation →
467
Multi-Selectmedium

Which THREE are valid user roles within an Automation Controller organization? (Choose three.)

Select 3 answers
A.Organization auditor
B.Organization admin
C.Organization team_member
D.Superuser
E.Organization member
AnswersA, B, E

Read-only access to all organization resources.

Why this answer

The Organization auditor role in Automation Controller provides read-only access to all objects within the organization, including inventories, projects, job templates, and credentials, without the ability to make changes. This role is essential for compliance and oversight, allowing auditors to review configurations and job history without risk of modification.

Exam trap

The trap here is that candidates may confuse 'Organization team_member' with a valid role, not realizing that team membership is distinct from organization-level roles, or they may incorrectly select 'Superuser' thinking it is an organization role when it is actually a global system role.

Full explanation →
468
Multi-Selecthard

Which THREE are valid uses of lookup plugins in Ansible? (Select exactly three.)

Select 3 answers
A.Generate a random MAC address using `password` lookup with `mac` parameter
B.Generate a random password using `password` lookup
C.Execute a command on the remote host using `pipe` lookup
D.Look up a value from an INI file using `ini` lookup
E.Read the contents of a file using `file` lookup
AnswersA, B, D

Correct. The `password` lookup with the `mac` parameter generates a random MAC address.

Why this answer

The `password` lookup plugin supports the `mac` parameter to generate a random MAC address. Option B is correct because the `password` lookup plugin is used to generate random passwords. Option D is correct because the `ini` lookup plugin retrieves values from INI files.

Option C is incorrect: the `pipe` lookup plugin executes a command locally on the control node, not on the remote host. Option E is incorrect because the `file` lookup plugin reads the contents of a file from the control node, but it is not considered one of the three valid uses in this context.

Exam trap

Candidates often overlook the `mac` parameter of the `password` lookup plugin, assuming it only generates passwords. Additionally, the `pipe` lookup is frequently mistaken for executing commands on remote hosts, but it runs locally on the control node.

Full explanation →
469
Multi-Selectmedium

Which TWO actions are valid for managing inventory group membership in Ansible Tower?

Select 2 answers
A.Using a range expression in the inventory host file.
B.Assigning a host to multiple groups.
C.Deleting a group deletes all hosts in it.
D.Creating a group as a child of itself.
E.Overriding group variables at the host level.
AnswersB, E

A host can belong to multiple groups.

Why this answer

Ansible Tower allows a host to be a member of multiple groups simultaneously, enabling flexible inventory organization and variable inheritance. Option E is correct because host variables override group variables when the same key is defined at both levels, following Ansible's variable precedence rules.

Exam trap

The trap here is that candidates often confuse the behavior of static inventory files (where range expressions and group deletion rules differ) with Ansible Tower's inventory management, leading them to select options A or C as valid.

Full explanation →
470
MCQhard

An Ansible playbook uses the `ansible_user` variable at the host level, but the SSH connection still uses root. Which configuration setting could override the playbook's user setting?

A.The Machine credential assigned to the job template specifies a different username.
B.The organization default user is root.
C.The playbook uses the directive 'remote_user: root'.
D.The inventory host variable ansible_user is not set.
AnswerA

Credential username overrides inventory variables.

Why this answer

In Ansible Tower/AWX, Machine credentials assigned to a job template take precedence over playbook-level variables like `ansible_user`. When a credential specifies a different username, it overrides the host variable because the credential system injects authentication parameters at runtime, effectively replacing the playbook's user setting for SSH connections.

Exam trap

The trap here is that candidates assume playbook-level variables always take precedence, but in Tower/AWX, credentials assigned to job templates override `ansible_user` and `remote_user` to enforce centralized authentication control.

How to eliminate wrong answers

Option B is wrong because the organization default user is not a configuration setting in Ansible Tower; organizations do not have a default user for SSH connections, and this concept does not exist in the credential hierarchy. Option C is wrong because the `remote_user` directive in a playbook is a play-level keyword that sets the user for tasks, but it can be overridden by inventory variables like `ansible_user` or by Tower credentials; however, the question states the playbook uses `ansible_user` at the host level, and `remote_user: root` would not override that unless explicitly set in the same playbook, but the issue is that the SSH connection still uses root despite `ansible_user` being set—this indicates a credential override, not a playbook directive issue. Option D is wrong because the question explicitly states the playbook uses the `ansible_user` variable at the host level, meaning it is set; if it were not set, the default user would be the current user or root, but the scenario describes a conflict where root is used despite the variable being set.

Full explanation →
471
MCQhard

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

A.The ansible.cfg file has an incorrect module path
B.The target host does not have internet access
C.The yum module should use state: present instead of latest
D.The target host is not registered with Red Hat Subscription Manager
AnswerD

Without subscription, the yum repositories are not available.

Why this answer

The error indicates no package found, likely because the target host is not subscribed to the necessary repositories.

Full explanation →
472
Multi-Selectmedium

An administrator is configuring Ansible Tower for a multi-environment deployment. The team has separate Azure service principals for dev, test, and prod, and uses Ansible Vault to encrypt sensitive variables. Which TWO configuration practices ensure secure credential management and clear inventory separation?

Select 2 answers
A.Create a single inventory and assign all hosts to groups named dev, test, and prod, then apply credentials at the group level.
B.Use the same vault password and vault ID for all environments to simplify management.
C.Use a single credential of type 'Azure Service Principal' and manually override the secrets per job template.
D.Define separate credential types for each environment, each with its own Vault ID pointing to a unique vault password.
E.Store the vault password in a file on the Tower server and reference it by path.
AnswersA, D

This approach organizes hosts by environment and allows group-specific credential assignments, aligning with Tower best practices.

Why this answer

Grouping hosts by environment within a single inventory and assigning Azure Service Principal credentials at the group level allows clear separation of environments while keeping inventory management centralized. This approach leverages Tower's native group-level credential assignment to ensure each environment uses its own service principal without manual overrides. Option D is also correct because defining separate credential types with unique Vault IDs ensures each environment's encrypted variables are decrypted only with the corresponding vault password, preventing cross-environment access to secrets.

Exam trap

The trap here is that candidates may think a single inventory with group-level credentials is sufficient without also considering vault ID separation, or they may incorrectly assume that using the same vault password across environments is acceptable for simplicity.

Full explanation →
473
MCQhard

You run a playbook with `msg: "{{ 'mypassword' | password_hash('sha512') }}"`. What is the output?

A.An error because password_hash requires the `passlib` library.
B.A random alphanumeric string.
C.A hashed representation of the password using SHA-512.
D.The string 'mypassword' unchanged.
AnswerC

Correct; password_hash returns a salted SHA-512 hash.

Why this answer

The `password_hash` filter in Ansible uses the `passlib` library (when available) to generate a cryptographically hashed representation of the input string. When the hash type is specified as `'sha512'`, it produces a SHA-512 crypt hash (typically starting with `$6$`), not the original plaintext. This is a standard Ansible filter for securely transforming passwords into hashed formats for use in user modules or configuration files.

Exam trap

The trap here is that candidates may think `password_hash` returns a random string (Option B) because the salt is random, but the output is a structured hash with a fixed format, not a purely random alphanumeric sequence.

How to eliminate wrong answers

Option A is wrong because `password_hash` does not require the `passlib` library by default; Ansible uses Python's `crypt` module as a fallback, and `passlib` is only needed for additional hash types or older Ansible versions. Option B is wrong because the output is not a random alphanumeric string; it is a deterministic hash (with a random salt) that follows the SHA-512 crypt format (e.g., `$6$salt$hash`). Option D is wrong because the filter explicitly transforms the input string into a hashed value, leaving it unchanged only if the filter is misapplied or the hash type is invalid.

Full explanation →
474
MCQmedium

A playbook uses the 'block' and 'rescue' keywords. If a task in the block fails, but the rescue tasks also fail, what happens?

A.The play fails.
B.The play continues to the next task.
C.The block is re-executed.
D.The rescue tasks are retried.
AnswerA

A failed rescue marks the play as failed.

Why this answer

When a task in a block fails, the rescue tasks execute. If the rescue tasks also fail, the entire play fails (the failure propagates). Option B is incorrect because the play does not continue; it fails.

Option C is incorrect because the block is not re-executed; rescue only runs once. Option D is incorrect because rescue tasks are not retried after failure.

Full explanation →
475
Drag & Dropmedium

Drag and drop the steps to set up a cron job that runs a script every day at 2 AM in the correct order.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps
Order
1Step 1
2Step 2
3Step 3
4Step 4

Why this order

Cron setup: prepare script, test, edit crontab, add entry with correct syntax, verify.

Full explanation →
476
MCQeasy

An admin is configuring a project in Automation Platform to pull playbooks from a Git repository. Which source control type should be selected?

A.Local
B.Manual
C.SCM
D.Red Hat Insights
AnswerC

SCM allows integration with Git repositories.

Why this answer

(SCM) is correct because Ansible Automation Platform uses Source Control Management (SCM) to integrate with Git repositories. When configuring a project, selecting 'SCM' allows the platform to pull playbooks, roles, and inventories directly from a remote Git repository, enabling version control and automated sync.

Exam trap

The trap here is that candidates may confuse 'SCM' with a generic term and think 'Manual' or 'Local' are valid options, but only SCM enables Git integration for project synchronization.

How to eliminate wrong answers

Option A is wrong because 'Local' refers to a project that uses playbooks stored directly on the Automation Controller file system, not from a remote Git repository. Option B is wrong because 'Manual' is not a valid source control type in Automation Platform; projects require either Local or SCM. Option D is wrong because 'Red Hat Insights' is a separate analytics and remediation service, not a source control mechanism for pulling playbooks.

Full explanation →
477
MCQmedium

Refer to the exhibit. The playbook runs successfully, but the service is not restarted. What is the most likely cause?

A.The handler name has a typo: 'restart app' vs 'restart app'
B.The systemd module requires ansible_user to be root
C.The template did not result in a change to the destination file
D.The template source file does not exist
AnswerC

Handlers only run if notified on change.

Why this answer

The handler is not notified because the template task might not have changed the file.

Full explanation →
478
MCQmedium

A company is deploying Red Hat Ansible Automation Platform 2.3 in a hybrid cloud environment. The automation controller is installed on a RHEL 8 server in the on-premises data center. Execution nodes are distributed: four in the same data center, two in a remote branch office connected via VPN, and three in AWS EC2 instances. The VPN connection to the branch office is low-bandwidth and high-latency. The AWS nodes use a direct connect with stable bandwidth. During initial testing, playbooks running on the branch office execution nodes frequently timeout or hang, while on-premises and AWS nodes work fine. The automation mesh topology is configured with all nodes as direct children of the controller. The team wants to minimize latency and ensure reliable execution for the branch office nodes. Which course of action should the administrator take?

A.Deploy an additional automation mesh node in the branch office and make the branch office execution nodes children of that node.
B.Configure the controller to use the AWS execution nodes for all branch office jobs via a proxy.
C.Increase the `ansible_timeout` setting in the controller configuration to 120 seconds.
D.Reduce the forks value for branch office execution nodes to 1.
AnswerA

A local mesh node reduces WAN traffic by caching playbook artifacts and handling control plane communication locally.

Why this answer

Deploying an additional automation mesh node in the branch office creates a local parent for the branch office execution nodes, reducing the number of high-latency, low-bandwidth VPN hops between the controller and those nodes. In the automation mesh, parent-child relationships allow execution nodes to connect through a closer intermediary, minimizing timeouts and improving reliability by keeping control-plane traffic local.

Exam trap

The trap here is that candidates may confuse tuning parameters (timeout, forks) with architectural fixes, failing to recognize that the mesh topology itself must be adapted to overcome network constraints.

How to eliminate wrong answers

Option B is wrong because using AWS execution nodes as a proxy for branch office jobs would still route traffic over the VPN, adding unnecessary latency and complexity without addressing the root cause. Option C is wrong because increasing `ansible_timeout` only masks the symptom of network delays; it does not reduce the underlying latency or packet loss causing the timeouts. Option D is wrong because reducing forks to 1 limits parallelism but does not solve connectivity issues; it may even increase execution time without preventing hangs from network instability.

Full explanation →
479
MCQhard

Your organization manages a fleet of 500 web servers running RHEL 8. Each server has a custom fact file /etc/ansible/facts.d/web.fact containing: [web] docroot=/var/www/html port=80 admin=admin@example.com You have a playbook that needs to configure the firewall to allow traffic on the port defined in the custom fact for each server. The playbook uses the 'ansible_local' variable to access these facts. However, some servers have the custom fact file missing or malformed. The task to open the firewall port fails on those servers with 'VARIABLE IS UNDEFINED'. You need to implement a solution that handles missing custom facts gracefully, setting a default port of 8080 if the fact is not defined, and still log a warning. Which approach should you take?

A.Use 'ignore_errors: yes' on the firewall task and then check the result with 'failed_when' to set a default.
B.Use a 'set_fact' task with 'port: "{{ ansible_local.web.port | default(8080) }}"' and add a 'debug' task with 'when: ansible_local.web.port is undefined' to warn.
C.Use 'block' and 'rescue' to catch the error and then set the fact.
D.Create a separate playbook for servers without the fact file, running a different role.
AnswerB

Correct: sets default and warns.

Why this answer

It uses the `default` filter to gracefully handle undefined variables, setting a fallback port of 8080 when the custom fact is missing or malformed. The additional `debug` task with `when: ansible_local.web.port is undefined` provides a warning without causing the playbook to fail. This approach aligns with the EX294 objective of transforming data with filters and plugins, specifically using Jinja2 filters to manage missing data.

Exam trap

The trap here is that candidates may overcomplicate the solution with error handling constructs like `ignore_errors` or `block/rescue`, instead of using the simple and idiomatic Jinja2 `default` filter, which is the most efficient and Ansible-native way to handle undefined variables.

How to eliminate wrong answers

Option A is wrong because `ignore_errors: yes` suppresses all errors from the firewall task, including legitimate failures, and does not set a default port; it merely continues execution without addressing the undefined variable. Option C is wrong because `block` and `rescue` can catch the error but require the task to fail first, which is less efficient than using the `default` filter to prevent the error entirely; additionally, setting the fact in the rescue block would still need a `set_fact` with a default, making the block/rescue redundant. Option D is wrong because creating a separate playbook for servers without the fact file is unnecessary overhead and violates the principle of idempotent, unified playbook management; the `default` filter handles the variability within a single playbook.

Full explanation →
480
Multi-Selecteasy

Which TWO statements are true about deploying Red Hat Ansible Automation Platform on a Red Hat Enterprise Linux 8 system?

Select 2 answers
A.The installer automatically creates an admin user with a randomly generated password.
B.The automation controller and database must be installed on the same node for performance reasons.
C.The AAP installer uses an Ansible playbook named 'ansible-setup.yml' to perform the installation.
D.You can install automation controller and private automation hub on separate machines to distribute the load.
E.Before installation, you must attach a subscription using subscription-manager attach --pool=...
AnswersC, D

Correct: The setup playbook is the main installer.

Why this answer

The correct answers are C and D. C is correct because the Red Hat Ansible Automation Platform installer is executed via an Ansible playbook named 'ansible-setup.yml' (or the setup.sh script that runs it). D is correct because automation controller and private automation hub are separate components that can be installed on different nodes to distribute the workload and improve scalability.

Option A is incorrect because the admin user password is specified in the inventory file, not randomly generated. Option B is incorrect because in production environments, the database is typically installed on a separate node for performance and reliability. Option E is incorrect: while a valid subscription is required, attaching via subscription-manager is not mandatory; the installer can use local repositories or other subscription methods.

Full explanation →
481
Multi-Selecteasy

Which THREE actions can an administrator perform using the inventory management features in Ansible Automation Platform? (Choose exactly three.)

Select 3 answers
A.Create job templates that automatically execute on inventory sync
B.Define variables at the global level that apply to all inventories
C.Add hosts to an inventory manually
D.Group hosts into hierarchical groups
E.Import static inventory from INI or YAML files
AnswersC, D, E

Hosts can be added manually via the UI or API.

Why this answer

Ansible Automation Platform allows administrators to manually add hosts to an inventory through the web UI or API, enabling direct management of target nodes without relying on external sources. This is a fundamental inventory management feature for defining the hosts that playbooks will target.

Exam trap

The trap here is that candidates may confuse inventory sync with job template execution, assuming that syncing an inventory automatically triggers a job, when in fact inventory sync only updates the host list and does not run playbooks.

Full explanation →
482
MCQeasy

An Ansible playbook needs to parse a JSON output from a REST API and extract the value of a nested key "data.settings.timeout". The output is stored in the variable "api_result". Which filter should be used to safely extract the value, with a default of 30 if the key is missing or the JSON is malformed?

A.{{ api_result | combine({'data.settings.timeout': 30}) }}
B.{{ api_result | selectattr('data.settings.timeout') | first | default(30) }}
C.{{ api_result | json_query('data.settings.timeout') | default(30) }}
D.{{ api_result | dict2items | selectattr('key', 'equalto', 'data.settings.timeout') | map(attribute='value') | first | default(30) }}
AnswerC

json_query correctly extracts the value using JMESPath, and default provides a fallback for missing keys.

Why this answer

`json_query` uses JMESPath syntax to query nested JSON structures, and `data.settings.timeout` is a valid JMESPath expression for extracting the value at that nested key. The `default(30)` filter provides a fallback if the key is missing or the JSON is malformed, ensuring safe extraction.

Exam trap

The trap here is that candidates confuse `json_query` with Jinja2 filters like `selectattr` or `combine`, which operate on different data structures (lists of dicts vs. nested dicts) and fail to correctly extract nested keys from a single JSON object.

How to eliminate wrong answers

Option A is wrong because `combine` merges dictionaries, not extracts values; it would attempt to merge `{'data.settings.timeout': 30}` into `api_result`, which does not extract the nested key and would not handle missing keys safely. Option B is wrong because `selectattr` is used to filter lists of dictionaries by attribute, not to extract nested keys from a single JSON object; it would fail or return an empty list on a non-list input. Option D is wrong because `dict2items` converts a dictionary to a list of key-value pairs, but `data.settings.timeout` is a nested path, not a flat key; the filter would not match the nested structure and would return an empty list, defaulting to 30 only by accident, not by correct logic.

Full explanation →
483
MCQmedium

An admin configures an automation mesh environment. What is the primary purpose of mesh nodes in AAP?

A.To enable high availability for the web UI.
B.To act as a backup for the automation controller.
C.To provide a redundant database server.
D.To scale automation execution capacity.
AnswerD

Mesh nodes distribute the workload of running playbooks.

Why this answer

Mesh nodes in Ansible Automation Platform (AAP) are designed to distribute automation execution workloads across multiple nodes, enabling horizontal scaling. They do not handle the web UI, controller logic, or database functions; instead, they execute playbooks and jobs, offloading work from the automation controller to increase overall capacity and performance.

Exam trap

The trap here is that candidates confuse mesh nodes with general high-availability or redundancy components, assuming they serve as backups for the controller or database, when in fact they are strictly for scaling execution capacity.

How to eliminate wrong answers

Option A is wrong because high availability for the web UI is provided by the automation controller nodes themselves, often through a load balancer, not by mesh nodes. Option B is wrong because mesh nodes are not backups for the automation controller; controller redundancy is achieved through a separate controller cluster with active/passive or active/active setups. Option C is wrong because database redundancy is handled by a separate database cluster (e.g., PostgreSQL streaming replication), not by mesh nodes, which have no database role.

Full explanation →
484
MCQhard

An organization uses ansible-builder to create an execution environment (EE) for network automation. The EE includes a custom collection 'acme.network' that requires the 'netaddr' Python library. The ansible-builder definition file (execution-environment.yml) lists 'netaddr' in the requirements.txt under dependencies.python. After building the EE and pushing it to the local registry, a user runs ansible-navigator with the EE and executes a playbook that uses a module from 'acme.network'. The playbook fails with an error that 'netaddr' is not installed. The user checks the running container and confirms that 'netaddr' is installed via pip list. What is the most likely cause?

A.The base image for the EE does not include the required system packages for 'netaddr'.
B.The collection 'acme.network' is not installed in the EE.
C.The ansible-navigator command is using a different EE than the one built.
D.The Python environment in the EE has multiple versions and netaddr is installed in the wrong one.
AnswerD

This is a realistic scenario in complex base images.

Why this answer

Execution environments built with ansible-builder can contain multiple Python interpreters (e.g., system Python and a virtual environment). The 'netaddr' library might be installed in the system Python but the Ansible controller process inside the EE runs from a different Python environment (often a virtual environment under /usr/share/ansible). When the playbook executes, it imports from the wrong Python, causing the 'not installed' error despite pip list showing the package.

Exam trap

The trap here is that candidates assume 'pip list' showing a package means it is available to Ansible, ignoring that Ansible inside the EE may use a separate Python virtual environment.

How to eliminate wrong answers

Option A is wrong because 'netaddr' is a pure Python library and does not require any system packages; the error is about Python import, not missing OS-level dependencies. Option B is wrong because the user confirmed the collection 'acme.network' is present (the playbook uses a module from it), and the error specifically names 'netaddr', not a missing module. Option C is wrong because the user checked the running container and confirmed 'netaddr' is installed via pip list, which implies they are inspecting the correct container; if a different EE were used, the pip list output would not show 'netaddr'.

Full explanation →
485
MCQhard

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?

A.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.
B.The repository URL might be incorrect on some servers. Use the 'uri' module to test connectivity to the repository.
C.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.
D.Add 'disable_gpg_check: yes' to the task to bypass the GPG check temporarily.
AnswerA

Cleaning the cache removes old key data, allowing the new key to be imported correctly.

Why this answer

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.

Exam trap

The trap here is that candidates assume the GPG key file itself is not being copied correctly (option C) or that a connectivity test (option B) is needed, when the real issue is stale yum cache metadata causing a key ID mismatch.

How to eliminate wrong answers

Option B is wrong because the error is specifically a GPG key mismatch, not a connectivity issue; the repository URL is irrelevant to GPG key validation. Option C is wrong because the role already copies the new key file, and the error persists despite the key being present; the problem is stale yum cache, not missing or outdated key files. Option D is wrong because disabling GPG check bypasses security entirely and is not a proper fix; it would allow installation but leave the system vulnerable and does not address the root cause of the key mismatch.

Full explanation →
486
MCQeasy

An administrator is writing a playbook to manage multiple web servers. The playbook uses a variable "server_facts" which is a list of dictionaries with keys "hostname", "ip", and "status". The administrator needs to extract a list of all hostnames where status is "online". The administrator writes: - name: Get online hosts set_fact: online_hosts: "{{ server_facts | selectattr('status', '==', 'online') | map(attribute='hostname') | list }}" However, when running the playbook, the "selectattr" filter fails with an error: "Invalid data passed to filter". The administrator checks the structure of "server_facts" and confirms it is a list of dicts with the expected keys. What is the most likely cause of the error?

A.The "status" key exists but its value is not consistently a string; some entries have integer 0/1 instead of "online"/"offline".
B.The "map" filter cannot be chained with "selectattr" directly.
C.The "list" filter is unnecessary and causes the error.
D.The "selectattr" filter requires Python 3.8 or later.
AnswerA

Mismatched types cause the comparison to fail.

Why this answer

The `selectattr` filter in Ansible uses Jinja2's `selectattr` which relies on Python's `attrgetter` and comparison operators. If the `status` key exists but its value is not consistently a string (e.g., some entries have integer 0/1 instead of 'online'/'offline'), the equality comparison `'==', 'online'` will fail because an integer cannot be compared to a string in this context, causing an 'Invalid data passed to filter' error. The administrator confirmed the structure is correct, so the issue is likely a type mismatch in the values.

Exam trap

The trap here is that candidates assume the error is about filter chaining or syntax, but the real issue is data type inconsistency—specifically that `selectattr` performs strict equality checks and fails when comparing mismatched types like integers and strings.

How to eliminate wrong answers

Option B is wrong because `map` can be chained directly with `selectattr` in Jinja2 filters; this is a standard and supported pattern in Ansible. Option C is wrong because the `list` filter is necessary to convert the generator returned by `map` into a list; omitting it would not cause an 'Invalid data passed to filter' error. Option D is wrong because `selectattr` does not require Python 3.8; it works with Jinja2's built-in filters and is available in Python 2.7+ and all versions of Python 3 supported by Ansible.

Full explanation →
487
MCQhard

Refer to the exhibit. After running the playbook, the admin checks /etc/ssh/sshd_config and finds that the MaxAuthTries line is unchanged. What is the most likely cause?

A.The playbook needs become: yes to modify the file
B.The regexp pattern is incorrect and does not match the current configuration
C.The handler was not notified because the task did not report 'changed'
D.The service name should be 'sshd' not 'sshd'
AnswerB

If no line matches, lineinfile does nothing by default.

Why this answer

The lineinfile regexp does not match any existing line, and the module does not add it if not found.

Full explanation →
488
MCQmedium

A team uses `ansible-navigator` to run playbooks with an execution environment. The playbook requires a collection that is not included in the execution environment. Which approach allows the team to use the collection without rebuilding the execution environment?

A.Set the `ANSIBLE_COLLECTIONS_PATHS` environment variable to a directory containing the collection and use `--execution-environment-image` with the EE.
B.Use the `--container-options` flag to mount a volume with the collection.
C.Use `ansible-galaxy collection install` inside the execution environment at runtime.
D.Rebuild the execution environment with the collection included.
AnswerA

Allows the local collection to be used inside the EE without rebuilding.

Why this answer

Setting the `ANSIBLE_COLLECTIONS_PATHS` environment variable tells `ansible-navigator` to look for collections in a specified directory on the host, and using `--execution-environment-image` ensures the correct execution environment image is used. This allows the team to inject a collection into the container at runtime without modifying the execution environment image itself, as `ansible-navigator` mounts the specified host directory into the container automatically.

Exam trap

The trap here is that candidates assume collections must be baked into the execution environment image, overlooking that `ansible-navigator` supports runtime injection of collections via host-mounted directories controlled by environment variables.

How to eliminate wrong answers

Option B is wrong because `--container-options` is not a valid flag for `ansible-navigator`; volume mounts are handled automatically by `ansible-navigator` based on environment variables like `ANSIBLE_COLLECTIONS_PATHS`, not via a generic container options flag. Option C is wrong because `ansible-galaxy collection install` cannot be run inside the execution environment at runtime; the execution environment is immutable once started, and you cannot execute arbitrary commands inside it without rebuilding the image. Option D is wrong because rebuilding the execution environment is the exact approach the team wants to avoid, as it is time-consuming and unnecessary when a runtime mount solution exists.

Full explanation →
489
Multi-Selectmedium

Which TWO of the following are valid methods to supply a credential password in Ansible Automation Controller?

Select 2 answers
A.Prompt on launch (ask for credential on job run)
B.Set the password via an environment variable in the job template
C.Include the password in a file in the project repository
D.Store the password in plain text in the credential definition
E.Use a Vault credential to decrypt vault-encoded password
AnswersA, E

This allows manual entry at runtime.

Why this answer

Ansible Automation Controller allows credentials to be prompted on launch, meaning the user is asked to enter the password at runtime rather than storing it. This is a secure method for sensitive values that should not be persisted in the controller's database or any configuration file.

Exam trap

The trap here is that candidates may confuse environment variable injection (common in standalone Ansible playbooks) with the controller's credential system, or mistakenly think plain text storage is acceptable because the controller encrypts data at rest, but the controller never allows plain text passwords in credential definitions.

Full explanation →
490
MCQhard

Your security team requires that all containers used in production must be scanned for vulnerabilities and must not contain any unnecessary packages to reduce attack surface. You are building an execution environment based on the 'ee-minimal-rhel8' image from Red Hat. You need to add a custom Python library named 'my_lib' that is available on a private PyPI server. You also need to install a collection from a private Git repository. The execution environment must be as small as possible. Which approach to building the execution environment satisfies the security and size requirements?

A.Use a multi-stage build in the execution-environment.yml by specifying 'additional_build_steps' to first install build dependencies, then install the library and collection, and finally remove build dependencies.
B.Use the 'dependencies' key for the Python library and the 'git' option for the collection, which automatically handles minimization.
C.Build a custom base image that already includes the library and collection, then reference it as the base image.
D.Add the library and collection installation commands to the 'additional_build_steps' section without any cleanup steps.
AnswerA

Correct. Multi-stage builds minimize final image size by discarding build-time layers.

Why this answer

A multi-stage build in the execution-environment.yml using 'additional_build_steps' allows you to install build dependencies (e.g., gcc, python3-devel) needed to compile 'my_lib', install the library from the private PyPI server, install the collection from the private Git repository, and then remove all build dependencies in a subsequent stage. This results in a final image that contains only the runtime artifacts, minimizing the attack surface and image size, satisfying the security and size requirements.

Exam trap

The trap here is that candidates assume the 'dependencies' key or 'git' option automatically handle cleanup, but they do not; the exam tests whether you understand that explicit multi-stage build steps are required to remove build dependencies and minimize the image.

How to eliminate wrong answers

Option B is wrong because the 'dependencies' key for Python libraries and the 'git' option for collections do not automatically handle minimization; they install the packages and collections but leave behind build dependencies and cache files, resulting in a larger image with unnecessary packages. Option C is wrong because building a custom base image that already includes the library and collection does not reduce the attack surface; the base image itself may contain unnecessary packages, and you lose the ability to cleanly separate build-time and runtime dependencies. Option D is wrong because adding installation commands to 'additional_build_steps' without cleanup steps leaves build dependencies and temporary files in the final image, violating the requirement to remove unnecessary packages.

Full explanation →
491
MCQmedium

An Ansible playbook is failing due to an undefined variable. Which approach would best help identify the source of the variable?

A.Add the 'ignore_errors: yes' directive
B.Set environment variable ANSIBLE_DEBUG=1
C.Add a debug task with var: hostvars[inventory_hostname]
D.Use the --syntax-check flag
AnswerC

Displays all host variables, helping locate undefined.

Why this answer

Adding a debug task with `var: hostvars[inventory_hostname]` dumps all variables for the current host, including those inherited from group_vars, host_vars, and play-level vars. This allows you to inspect the full variable namespace and identify which variable is undefined or missing, directly addressing the root cause of the failure.

Exam trap

The trap here is that candidates confuse syntax checking (--syntax-check) with runtime variable validation, or they think enabling debug mode (ANSIBLE_DEBUG=1) will magically reveal variable issues, when in fact only a targeted variable dump can show the actual defined values.

How to eliminate wrong answers

Option A is wrong because 'ignore_errors: yes' only suppresses task failure output; it does not resolve or diagnose an undefined variable error, which will still cause the playbook to fail unless the variable is defined. Option B is wrong because setting ANSIBLE_DEBUG=1 increases verbosity for debugging Ansible internals (e.g., SSH connections, module execution) but does not specifically help locate an undefined variable in your playbook or inventory. Option D is wrong because '--syntax-check' only validates YAML syntax and basic playbook structure; it does not evaluate variable definitions or runtime variable resolution.

Full explanation →
492
MCQhard

An execution environment fails to build because `pip install` fails when installing a Python package from a private repository that requires authentication. The build works when run locally by the developer. Which approach should be taken to securely provide credentials during the `ansible-builder build` process?

A.Store the credentials in the Automation Hub token and reference it.
B.Add the credentials directly to the `Containerfile` that `ansible-builder` generates.
C.Include the credentials in the `execution-environment.yml` under `dependencies: python:`.
D.Create a `pip.conf` file that uses environment variables or BuildKit secrets to inject credentials.
AnswerD

Securely injects credentials without exposing them in the definition file.

Why this answer

`ansible-builder` supports BuildKit secrets and environment variable injection via a `pip.conf` file, allowing credentials to be passed securely at build time without hardcoding them into the execution environment definition. This approach ensures that sensitive authentication tokens are not exposed in the `execution-environment.yml` or the generated `Containerfile`, and it mirrors the local developer workflow where environment variables or secret mounts are used.

Exam trap

The trap here is that candidates often assume credentials must be placed directly in the execution environment definition file or the generated Containerfile, overlooking the secure, build-time injection mechanisms provided by BuildKit secrets and environment variables.

How to eliminate wrong answers

Option A is wrong because Automation Hub tokens are used for authenticating to Automation Hub itself, not for private Python package repositories; they cannot be referenced in a `pip.conf` or passed to `pip install` for external registries. Option B is wrong because adding credentials directly to the `Containerfile` would hardcode secrets into the image layers, violating security best practices and making the credentials visible to anyone with access to the image. Option C is wrong because the `dependencies: python:` section in `execution-environment.yml` only lists package names and versions, not authentication credentials; it does not support inline credentials or secret injection.

Full explanation →
493
MCQmedium

A playbook uses import_playbook to include other playbooks. The main playbook is run with --check mode. Which statement is true?

A.Only the main playbook runs in check mode; imported ones run normally.
B.All imported playbooks are skipped because import happens at parse time.
C.import_playbook does not support check mode.
D.Imported playbooks are also run in check mode.
AnswerD

Import_playbook merges tasks at parse time, so check mode affects all tasks.

Why this answer

When a playbook uses `import_playbook`, the imported playbooks are statically included at parse time, meaning they become part of the main playbook's play structure. The `--check` mode flag applies to the entire playbook execution, so all imported playbooks also run in check mode. Option D is correct because Ansible propagates the check mode flag to all imported plays.

Exam trap

The trap here is that candidates confuse `import_playbook` (static inclusion) with dynamic includes like `include_tasks`, which do not inherit check mode in the same way, leading them to think imported playbooks are skipped or run normally.

How to eliminate wrong answers

Option A is wrong because `--check` mode is not limited to the main playbook; it applies globally to all plays, including those imported via `import_playbook`. Option B is wrong because `import_playbook` does not cause imported playbooks to be skipped in check mode; they are included at parse time and run with the same check mode flag. Option C is wrong because `import_playbook` fully supports check mode; there is no restriction that prevents imported playbooks from running in check mode.

Full explanation →
494
Multi-Selectmedium

Which TWO of the following are valid methods to manage credentials in Ansible Tower?

Select 2 answers
A.Integrate with an external secrets management system using a credential lookup plugin.
B.Export credentials from the Ansible Tower API in plain-text.
C.Use machine credentials with an SSH key that has a passphrase.
D.Create custom credential types that inject environment variables into job templates.
E.Store credentials in plain-text in the Ansible Tower database.
AnswersA, D

Ansible Tower supports external secret management integrations.

Why this answer

Ansible Tower (now Red Hat Ansible Automation Platform) supports integration with external secrets management systems like HashiCorp Vault, CyberArk, or Azure Key Vault via credential lookup plugins. This allows Tower to retrieve secrets dynamically at runtime without storing them in the Tower database, aligning with security best practices.

Exam trap

The trap here is that candidates may confuse 'managing credentials' with 'storing credentials' and incorrectly assume that passphrase-protected SSH keys or plain-text storage are valid, when in fact Tower requires keys without passphrases and encrypts all stored credentials.

Full explanation →
495
MCQeasy

Refer to the exhibit. An automation job failed with the given error. What is the most likely cause?

A.The playbook syntax is incorrect
B.The SSH port is blocked
C.The remote host is unreachable
D.The SSH key is not authorized for the remote user
AnswerD

Permission denied (publickey) indicates key not accepted.

Why this answer

The error message indicates an SSH authentication failure, which occurs when the SSH key presented by the control node is not authorized for the remote user's account. This is the most likely cause because Ansible relies on SSH key-based authentication by default, and a missing or mismatched public key on the remote host will prevent the connection.

Exam trap

The trap here is that candidates often confuse SSH authentication failures with network connectivity issues, but the specific 'Permission denied (publickey)' error clearly points to key authorization, not reachability or port blocking.

How to eliminate wrong answers

Option A is wrong because the error message does not indicate a YAML syntax or playbook structure issue; such errors would be caught during playbook parsing and would show a different message. Option B is wrong because a blocked SSH port (default 22) would result in a 'Connection refused' or 'No route to host' error, not an authentication failure. Option C is wrong because an unreachable host would produce a 'Name or service not known' or 'Network is unreachable' error, not an SSH authentication error.

Full explanation →
496
Multi-Selectmedium

Which TWO statements about Ansible roles are correct?

Select 2 answers
A.Roles must follow a specific directory structure.
B.Roles can be shared via Ansible Galaxy.
C.Ansible Galaxy is a continuous integration tool for testing roles.
D.Role dependencies must be defined in a file named dependencies.yml.
E.Role names must have a .role extension.
AnswersA, B

Roles require a defined directory layout (tasks, handlers, etc.).

Why this answer

Ansible roles enforce a specific directory structure (e.g., tasks/, handlers/, templates/, files/, vars/, defaults/, meta/, and library/) to organize automation content. This structure is mandatory for Ansible to correctly locate and load role components during playbook execution.

Exam trap

The trap here is that candidates confuse Ansible Galaxy as a CI tool because it has 'Galaxy' in its name, or assume role dependencies require a separate file like dependencies.yml, when in fact they must be placed in meta/main.yml.

Full explanation →
497
MCQmedium

A team uses Ansible AWX and needs to run a job template that uses a custom credential of type 'OpenStack' to authenticate to an OpenStack cloud. Which field in the job template is used to specify this credential?

A.Custom Credential
B.Extra Credentials
C.Credential
D.Machine credential
AnswerC

The field that accepts any credential type.

Why this answer

In Ansible AWX, the 'Credential' field in a job template is used to specify the primary credential for authentication to external systems. When using a custom credential type like 'OpenStack', selecting it in the 'Credential' field associates the job template with the OpenStack authentication parameters (e.g., auth URL, username, password, project) defined in that credential. This allows the job to authenticate to the OpenStack cloud during execution.

Exam trap

The trap here is that candidates confuse the 'Credential' field with 'Extra Credentials', assuming all credentials are added via the extra credentials mechanism, but AWX requires the primary credential to be set in the 'Credential' field for the job template to function correctly.

How to eliminate wrong answers

Option A is wrong because 'Custom Credential' is not a field in the job template; it refers to a credential type defined in the AWX credential management interface, not a field for assignment. Option B is wrong because 'Extra Credentials' is a field used to add additional credentials (e.g., for multi-cloud or separate service accounts) beyond the primary credential, not for specifying the main authentication credential. Option D is wrong because 'Machine credential' is a specific credential type for SSH or WinRM authentication to managed nodes, not for OpenStack cloud API authentication.

Full explanation →
498
MCQeasy

A system administrator wants to publish a custom Ansible collection to a private Automation Hub. What is the correct command to build the collection before publishing?

A.ansible-galaxy collection init mycollection
B.ansible-galaxy collection publish ./mycollection-1.0.0.tar.gz
C.ansible-galaxy collection install .
D.ansible-galaxy collection build
AnswerD

Builds a collection tarball from the current directory.

Why this answer

`ansible-galaxy collection build` is the command that compiles the collection directory into a distributable tarball (e.g., `mycollection-1.0.0.tar.gz`), which is the required artifact for publishing to a private Automation Hub. Without this build step, there is no archive to upload.

Exam trap

The trap here is that candidates confuse the `publish` command (which uploads an existing tarball) with the `build` command (which creates the tarball), leading them to select option B instead of D.

How to eliminate wrong answers

Option A is wrong because `ansible-galaxy collection init` creates the skeleton directory structure for a new collection, not the build artifact needed for publishing. Option B is wrong because `ansible-galaxy collection publish` uploads an already-built tarball to Automation Hub, but the question asks for the command to build the collection before publishing. Option C is wrong because `ansible-galaxy collection install` downloads and installs a collection from a source (like a galaxy server or a tarball), not builds one for distribution.

Full explanation →
499
MCQhard

A playbook uses 'delegate_to: localhost' for a task that modifies a local file. The playbook runs against multiple servers. The administrator notices that the local file is overwritten by each parallel execution, causing corruption. Which strategy should be used to prevent this?

A.Increase 'forks: 1' to serialize execution.
B.Use 'throttle: 1' on the task.
C.Use 'serial: 1' at the play level.
D.Use 'run_once: true' along with 'delegate_to'.
AnswerD

Correct: run_once ensures the task is executed only once, avoiding parallel overwrites.

Why this answer

`run_once: true` ensures that the task executes only once across the entire batch of hosts, even when `delegate_to: localhost` is used. This prevents the local file from being overwritten by multiple parallel executions, as the task runs on a single host (the first in the inventory) and delegates the file modification to localhost once.

Exam trap

The trap here is that candidates confuse serialization (`serial`, `forks`, `throttle`) with single execution (`run_once`), mistakenly believing that running tasks one at a time prevents the overwrite, when in fact each host still triggers the task.

How to eliminate wrong answers

Option A is wrong because increasing `forks: 1` would serialize execution across all hosts, but the task would still run once per host, each time overwriting the local file — it does not limit the task to a single execution. Option B is wrong because `throttle: 1` limits the number of concurrent task executions to one, but like forks, it still runs the task for each host sequentially, causing the same overwrite issue. Option C is wrong because `serial: 1` at the play level runs the play against one host at a time, but the task still executes for each host, leading to repeated local file modifications.

Full explanation →
500
MCQeasy

An Ansible playbook contains many tasks. An administrator wants to run only a subset of tasks by passing '--tags ' at the command line. Which of the following must be added to the tasks?

A.a 'name' with specific naming convention
B.a 'block' statement
C.a 'tags' directive on each task
D.a 'when' condition
AnswerC

Correct. The 'tags' directive is used to label tasks so that they can be selected with the '--tags' option.

Why this answer

The 'tags' directive is the only mechanism in Ansible that allows tasks to be selectively included or excluded when running a playbook with the '--tags' command-line option. By adding a 'tags' attribute to a task (e.g., 'tags: install'), the administrator can target that task specifically, and Ansible's task execution engine filters tasks based on the provided tags at runtime.

Exam trap

The trap here is that candidates often confuse the 'name' field with a functional identifier, assuming it can be used for filtering, when in reality only the 'tags' directive controls task selection with '--tags'.

How to eliminate wrong answers

Option A is wrong because the 'name' field in a task is purely for documentation and display purposes; it does not influence task selection via '--tags'. Option B is wrong because a 'block' statement groups tasks for error handling or conditional execution but does not provide tag-based filtering; blocks themselves can have tags, but the question asks what must be added to each task, and a block is not required. Option D is wrong because a 'when' condition controls whether a task runs based on variables or facts, not on command-line tag selection, and cannot be used with '--tags'.

Full explanation →
501
MCQmedium

An Ansible rolling update playbook includes 'max_fail_percentage: 20'. If more than 20% of hosts fail during any batch, what happens?

A.The play pauses and waits for user input
B.The failed hosts are removed from inventory
C.The play retries failed hosts
D.The play aborts immediately
E.The play continues with remaining hosts
AnswerD

If failure percentage exceeds max_fail_percentage, the play stops.

Why this answer

The `max_fail_percentage` parameter in Ansible's rolling update strategy defines the maximum percentage of hosts that can fail in a single batch before the playbook aborts entirely. When the failure rate exceeds this threshold, Ansible stops execution immediately to prevent cascading failures or inconsistent state across the remaining hosts.

Exam trap

The trap here is that candidates often confuse `max_fail_percentage` with `any_errors_fatal` or assume the play will simply skip failed hosts and continue, but Ansible strictly aborts the entire play when the threshold is exceeded to enforce safety limits.

How to eliminate wrong answers

Option A is wrong because `max_fail_percentage` does not pause the play for user input; that behavior is controlled by `serial` with `pause` or `wait_for` tasks, not by failure thresholds. Option B is wrong because failed hosts are not removed from inventory; Ansible does not modify inventory files dynamically based on playbook failures. Option C is wrong because `max_fail_percentage` does not trigger automatic retries; retry behavior is configured separately via `retries` and `until` on individual tasks or via `any_errors_fatal`.

Option E is wrong because the play does not continue with remaining hosts when the failure percentage is exceeded; instead, it aborts immediately to prevent further execution.

Full explanation →
502
MCQhard

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?

A.Set 'become_ask_pass = false' in ansible.cfg.
B.Set 'host_key_checking = False' in ansible.cfg.
C.Set 'ask_pass = true' in ansible.cfg.
D.Add 'remote_user: root' to the playbook.
AnswerC

The error indicates SSH password authentication is failing; setting ask_pass = true allows Ansible to prompt for the SSH password.

Full explanation →
503
MCQhard

An Ansible playbook uses 'async' and 'poll' to run a long-running task. The task returns a changed status and the playbook continues. However, the remote server reports that the task failed after the playbook finished. What is the most likely reason?

A.The 'async' timeout was set too high.
B.The 'poll' interval was set too low.
C.The task's return code was not checked; 'async_status' module should be used to explicitly check the job result.
D.The playbook used 'ignore_errors: true' on the async task.
AnswerC

Correct: Without explicit status check, Ansible only sees that the job started, not its final outcome.

Why this answer

When a task is launched with `async` and `poll: 0`, Ansible does not wait for the task to complete; it immediately continues the playbook. The task runs in the background on the remote host, and its final result (including failure) is not automatically captured by the playbook. To retrieve the actual exit status and output, you must explicitly use the `async_status` module with the job ID to poll the task until it finishes.

Without this explicit check, the playbook may report success even if the background task ultimately fails.

Exam trap

The trap here is that candidates assume Ansible automatically captures the final result of an async task when `poll: 0` is used, but in reality the playbook only records the initial launch status and requires an explicit `async_status` call to retrieve the actual completion status.

How to eliminate wrong answers

Option A is wrong because setting the `async` timeout too high would only allow the task to run longer before Ansible considers it failed; it does not cause a false success or mask a failure after the playbook finishes. Option B is wrong because the `poll` interval controls how frequently Ansible checks the task status while waiting; a low interval would cause more frequent checks, not a missed failure. Option D is wrong because `ignore_errors: true` would cause the playbook to continue despite a failure, but the question states the playbook already continues and the remote server reports failure after the playbook finished; `ignore_errors` would not cause the task to appear successful when it actually failed—it would still show a failure in the task result, just not halt the playbook.

Full explanation →
504
MCQmedium

A team uses execution environments (EE) for job templates. The admin builds a custom EE using `ansible-builder` with a `execution-environment.yml` file that includes a `base_image: registry.redhat.io/ansible-automation-platform-21/ee-minimal-rhel8:latest` and a custom Python requirement. However, the controller reports that the EE is not found when launching a job. What is the most likely issue?

A.The built EE image was not pushed to the container registry specified in the controller's execution environment configuration.
B.The base image is pointing to an incorrect registry path.
C.The custom Python requirement needs to be added to `requirements.txt` in the project.
D.The execution environment does not include a `Containerfile` for the build process.
AnswerA

The EE must be available in a registry that controller can pull from.

Why this answer

After building a custom execution environment with `ansible-builder`, the resulting container image must be pushed to a container registry that the Automation Controller is configured to access. The controller does not automatically pull images from the local build cache; it references the image by its registry path. If the image is not present in the specified registry, the controller will report that the EE is not found when launching a job.

Exam trap

The trap here is that candidates assume building the image locally is sufficient, but the controller requires the image to be accessible via a registry pull, not from the local build cache.

How to eliminate wrong answers

Option B is wrong because `registry.redhat.io/ansible-automation-platform-21/ee-minimal-rhel8:latest` is a valid Red Hat registry path for the minimal execution environment; the issue is not about an incorrect registry path but about the image not being available in the registry the controller queries. Option C is wrong because custom Python requirements are defined in the `execution-environment.yml` file under the `python` key, not in a project's `requirements.txt`; the controller does not read project files for EE dependencies. Option D is wrong because `ansible-builder` automatically generates a `Containerfile` (or `Dockerfile`) during the build process based on the `execution-environment.yml`; the absence of a pre-existing `Containerfile` is not the issue.

Full explanation →
505
MCQeasy

An organization wants to deploy Ansible Automation Platform 2.x in a highly available configuration. Which component must be deployed in an active-active cluster to ensure controller failover?

A.PostgreSQL database
B.Automation controller
C.Private Automation Hub
D.Automation mesh
AnswerB

The controller runs the web UI, API, and scheduler; an active-active cluster with a load balancer provides HA.

Why this answer

The automation controller is the component that provides the web UI, REST API, and job execution management in Ansible Automation Platform 2.x. For high availability, multiple controller nodes must be deployed in an active-active cluster behind a load balancer, ensuring that if one controller fails, another can immediately take over without service interruption.

Exam trap

The trap here is that candidates often confuse the automation mesh (which provides execution node redundancy) with the automation controller's active-active clustering, leading them to select mesh as the answer for controller failover.

How to eliminate wrong answers

Option A is wrong because PostgreSQL database is typically deployed as a separate highly available database cluster (e.g., using Patroni or streaming replication) and is not itself part of the active-active controller cluster; it supports the controller but does not provide controller failover. Option C is wrong because Private Automation Hub is a content distribution component for collections and execution environments, and it does not handle controller job scheduling or API requests; it can be made highly available independently but does not ensure controller failover. Option D is wrong because Automation mesh is a communication layer for distributing execution workloads across nodes and is not a controller component; it provides resilience for execution nodes but does not handle controller failover.

Full explanation →
506
Multi-Selectmedium

An Ansible playbook uses the "community.general" collection to manage firewall rules. The engineer wants to use a lookup plugin to fetch the current IPv4 address of a host to include in a dynamic inventory script. Which TWO of the following options correctly describe the usage of lookup plugins in Ansible?

Select 2 answers
A.Lookup plugins are always executed on the remote host.
B.Lookup plugins must be imported using the "lookup" keyword.
C.Lookup plugins are executed on the control node and return data to the Ansible controller.
D.The "file" lookup plugin reads the content of a file from the remote host.
E.Lookup plugins can be used in "vars" sections of a playbook.
AnswersC, E

Correct; they fetch data on the control node.

Why this answer

Lookup plugins in Ansible are designed to run on the control node (the machine where Ansible is executed), not on the remote host. They fetch data from external sources (e.g., files, databases, environment variables) and return that data to the Ansible controller for use in playbooks or inventory scripts. This aligns with the requirement to fetch the current IPv4 address of a host for a dynamic inventory script, as the lookup plugin can query local or network sources without needing to execute on the target host.

Exam trap

The trap here is that candidates often confuse lookup plugins (control node execution) with modules (remote host execution), or mistakenly think the 'lookup' keyword is a special Ansible keyword rather than a Jinja2 function, leading them to select options A or B.

Full explanation →
507
MCQeasy

Your organization uses Ansible Tower to manage a growing number of Linux servers. Currently, there is a single inventory called 'All Servers' that contains all hosts. A new project requires that certain sensitive variables (e.g., API keys) be stored securely and not exposed in job logs. The security team also wants to limit which users can use these credentials. You have been asked to implement a solution. After evaluating, you plan to create a custom credential type with a 'password' field for the API key and assign it to the job template. However, during a test run, the API key is still visible in the job output. What is the most likely reason?

A.The custom credential type was created with an 'input' field instead of a 'password' field.
B.The playbook contains a debug task that prints the API key variable.
C.The 'no_log' parameter was not set in the Ansible configuration for the module.
D.The credential was not assigned to the job template; it was only assigned to the project.
AnswerB

Debug tasks can expose variables regardless of credential type.

Why this answer

Even if a credential is properly defined and assigned, any task in the playbook that explicitly references the variable (such as a debug task) will output its value in the job log. Ansible Tower's credential hiding only prevents the credential from being displayed in the job template's 'extra variables' or credential details; it does not automatically suppress the variable's value if the playbook itself prints it. The playbook author must use the 'no_log: true' directive on tasks that handle sensitive data to prevent exposure.

Exam trap

The trap here is that candidates assume creating a credential with a 'password' field automatically hides the value everywhere, but they overlook that the playbook itself can still print the variable unless the task uses 'no_log: true'.

How to eliminate wrong answers

Option A is wrong because the 'password' field type in a custom credential type is specifically designed to hide input values in the UI and logs; using an 'input' field would not hide the value, but the question states the credential was created with a 'password' field, so this is not the issue. Option C is wrong because the 'no_log' parameter is set on individual tasks or plays within the playbook, not in the Ansible configuration file (ansible.cfg) for a module; the configuration file has a 'no_log' setting for callbacks, but it does not apply to credential variables. Option D is wrong because if the credential were not assigned to the job template, the API key would not be available to the playbook at all, and the job would likely fail with an undefined variable error, not silently print the key.

Full explanation →
508
MCQhard

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?

A.Change the variable in group_vars/all.yml to a list and use 'include_role' with loop.
B.Add a 'when' condition to the include_role task to check the group name.
C.Define the server_role variable in group_vars/web.yml, group_vars/app.yml, and group_vars/db.yml with the appropriate values.
D.Define the server_role in host_vars for each server.
AnswerC

Group vars override all.yml for that group.

Why this answer

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.

Exam trap

The trap here is that candidates may think a `when` condition or modifying the playbook is necessary, but the question tests understanding of Ansible's variable precedence and the correct use of group_vars to override all.yml without altering the playbook structure.

How to eliminate wrong answers

Option A is wrong because changing `server_role` to a list and looping `include_role` would apply multiple roles to each server, not fix the single-role misassignment; it also unnecessarily complicates the playbook. Option B is wrong because adding a `when` condition requires modifying the playbook structure, which the question explicitly forbids, and it would not leverage Ansible's variable precedence. Option D is wrong because defining `server_role` in `host_vars` for each of 500 servers is impractical and violates the DRY principle; group_vars is the correct scope for group-specific variables.

Full explanation →
509
Multi-Selectmedium

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

Select 2 answers
A.The inventory must contain an entry for the control node.
B.The task must have privilege escalation (become) enabled.
C.The task must be executed on the Ansible control node.
D.The 'local_action' module must be used instead of 'action'.
E.The connection plugin must be set to 'local'.
AnswersC, E

local_action runs locally.

Why this answer

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.

Full explanation →
510
MCQhard

In OpenShift, a deployment must gradually shift traffic to new pods during a rolling update. Which default strategy achieves this?

A.Blue-green deployment
B.RollingUpdate
C.Canary deployment
D.Custom strategy
E.Recreate
AnswerB

RollingUpdate gradually replaces old pods with new ones, shifting traffic.

Why this answer

The RollingUpdate strategy is the default deployment strategy in OpenShift (and Kubernetes) that gradually replaces old pods with new ones while maintaining application availability. It achieves this by incrementally scaling down the old ReplicaSet and scaling up the new one, controlled by parameters like maxSurge and maxUnavailable, ensuring a smooth transition of traffic to new pods.

Exam trap

The trap here is that candidates often confuse the default OpenShift deployment strategy with advanced deployment patterns like blue-green or canary, which are not built-in defaults but require additional configuration, leading them to select those incorrect options.

How to eliminate wrong answers

Option A is wrong because blue-green deployment is not a default strategy in OpenShift; it requires manual configuration or additional tooling (e.g., Routes and Services) to switch traffic between two separate environments. Option C is wrong because canary deployment is not a built-in default strategy; it involves routing a small percentage of traffic to new pods via custom configurations or service mesh features like Istio, not a native OpenShift deployment strategy. Option D is wrong because 'Custom strategy' is not a valid default deployment strategy in OpenShift; the platform only supports RollingUpdate and Recreate as native strategies, with custom behavior achievable via parameters but not as a named default.

Option E is wrong because Recreate is an alternative strategy that terminates all old pods before creating new ones, causing downtime, and is not the default for gradual traffic shifting.

Full explanation →
511
MCQeasy

An admin checks the job details and sees this error from the API. What is the most likely cause?

A.The job template is using an execution environment that lacks the plugin.
B.The callback plugin is not installed on the controller node.
C.The callback plugin name is misspelled in the project.
D.The machine credential is invalid.
AnswerB

AAP requires that callback plugins be installed on the controller; otherwise, it reports an invalid plugin.

Why this answer

The error from the API indicates that the callback plugin is missing on the controller node. In Ansible Automation Platform, callback plugins must be installed on the controller node (or execution node) where `ansible-runner` processes job events. If the plugin is not present there, the API will report a failure when the job attempts to use it, even if the execution environment contains the plugin.

Exam trap

The trap here is that candidates assume the execution environment is the only place plugins need to exist, but the controller node must also have the callback plugin installed to process job events, leading to an API-level error when it is missing.

How to eliminate wrong answers

Option A is wrong because the execution environment is a container image that provides the runtime for playbook execution, but the callback plugin must be installed on the controller node (or execution node) that handles job event processing; the execution environment's plugin content does not automatically make the plugin available to the controller's API. Option C is wrong because a misspelled callback plugin name in the project would cause a different error (e.g., 'unable to locate plugin') at the playbook parsing stage, not an API-level error from the job details. Option D is wrong because an invalid machine credential would result in an authentication failure during SSH or WinRM connection, not an API error about a missing callback plugin.

Full explanation →
512
MCQhard

A playbook fails with an error when evaluating `{{ mylist | select('match') }}`. What is the most likely cause?

A.The `select` filter must be used with `selectattr` for attributes.
B.The `select` filter requires the test name without quotes.
C.The `match` test requires a regex pattern as an argument.
D.The `filter` plugin should be used instead of `select`.
AnswerC

The `match` test must be called with a pattern, e.g., `select('match', '.*')`.

Why this answer

The `match` test in Ansible always requires a regex pattern as an argument (e.g., `match('^foo')`). Without providing a pattern, the test has nothing to match against, and the playbook fails. Option C correctly identifies this as the cause.

The other options are incorrect: `select` can be used without `selectattr` (A), quotes are not the issue (B), and `filter` plugin is not a substitute (D).

Exam trap

The trap here is that candidates may assume the `match` test works without arguments (like `defined` or `none`), but it always requires a regex pattern, and the error message may be misinterpreted as a syntax or filter issue.

How to eliminate wrong answers

Option A is wrong because `select` and `selectattr` are separate filters; `select` can be used with tests directly without needing `selectattr`. Option B is wrong because the `select` filter does accept test names with quotes (e.g., `'match'`), and the error is not about quoting. Option D is wrong because `filter` is a Jinja2 function, not an Ansible plugin, and `select` is the correct filter to apply a test to list items.

Full explanation →
513
MCQmedium

An Ansible Tower/AWX administrator wants to prevent users from viewing credential passwords in plain text. Which credential type should be used for SSH passwords?

A.SSH credential
B.Password credential
C.Machine credential
D.Login credential
AnswerC

Machine credentials store SSH passwords encrypted and hidden.

Why this answer

Machine credentials in Ansible Tower/AWX are the correct choice for SSH passwords because they are specifically designed to store SSH authentication parameters, including passwords, private keys, and key passphrases. When a machine credential is configured with an SSH password, Tower/AWX encrypts the password at rest and never exposes it in plain text to users through the web interface or API, ensuring that credential secrets remain hidden.

Exam trap

The trap here is that candidates may confuse the generic term 'SSH credential' with the actual Ansible Tower/AWX credential type 'Machine credential', or assume that a 'Password credential' exists as a standalone type, when in fact passwords are always embedded within a specific credential type like Machine or Vault.

How to eliminate wrong answers

Option A is wrong because 'SSH credential' is not a valid credential type in Ansible Tower/AWX; the platform uses 'Machine credential' to encompass SSH-based authentication for target hosts. Option B is wrong because 'Password credential' is not a defined credential type in Tower/AWX; passwords are stored within other credential types (e.g., Machine or Vault credentials) and not as a standalone type. Option D is wrong because 'Login credential' is not a recognized credential type in Ansible Tower/AWX; the correct term for host authentication is 'Machine credential', and 'Login credential' is a generic term that does not exist in the product.

Full explanation →
514
MCQmedium

An Ansible playbook sets 'serial: 20%' for rolling updates, but the inventory contains 5 hosts. How many hosts are updated simultaneously?

A.1
B.2
C.3
D.0
E.5
AnswerA

20% of 5 is 1 host per batch.

Why this answer

When 'serial: 20%' is set in an Ansible playbook, the percentage is calculated based on the total number of hosts in the inventory. With 5 hosts, 20% of 5 equals 1.0, which is rounded down to 1. Therefore, only 1 host is updated at a time during the rolling update.

Exam trap

The trap here is that candidates often assume percentages are rounded up or that a fractional result like 1.0 would be treated as 2, but Ansible uses floor rounding (truncation) for serial batch sizes, and with exactly 1.0, the result is 1, not 2.

How to eliminate wrong answers

Option B is wrong because 2 would represent 40% of 5 hosts, not 20%. Option C is wrong because 3 would be 60% of the inventory, far exceeding the 20% specification. Option D is wrong because 0 would only occur if the percentage rounded down to zero (e.g., less than 1 host), but 20% of 5 is exactly 1.0, which rounds to 1.

Option E is wrong because 5 would represent 100% of the hosts, which would be a serial value of '100%' or 'serial: 5', not '20%'.

Full explanation →
515
MCQeasy

An Ansible playbook retrieves a JSON response from an API and stores it in the variable `api_response`. The JSON structure is a list of objects, each with keys `name`, `status`, and `id`. The team needs to create a list of names for objects where status is 'active'. Which filter should be used?

A.{{ api_response | json_query("status=active.name") }}
B.{{ api_response | flatten }}
C.{{ api_response | subelements('name') }}
D.{{ api_response | selectattr('status', 'equalto', 'active') | map(attribute='name') | list }}
AnswerD

Correctly filters by status and maps to name.

Why this answer

It uses `selectattr` to filter the list of objects to only those where `status` equals 'active', then `map` to extract the `name` attribute from each filtered object, and finally `list` to convert the result into a list. This is the standard Ansible approach for filtering a list of dictionaries and extracting specific keys.

Exam trap

The trap here is that candidates often confuse `json_query` with `selectattr`/`map` and attempt to use JMESPath syntax incorrectly, or they pick `flatten` or `subelements` because they sound related to list manipulation, without understanding their specific purposes.

How to eliminate wrong answers

Option A is wrong because `json_query` uses JMESPath syntax, which requires a query like `[?status=='active'].name` — the given syntax `status=active.name` is invalid and would cause an error. Option B is wrong because `flatten` is used to reduce nested lists into a single flat list, not to filter or extract attributes from a list of objects. Option C is wrong because `subelements` is designed to iterate over sub-elements of a list of dictionaries (e.g., a list of users each with a list of groups), not to filter or map attributes from a flat list of objects.

Full explanation →
516
MCQmedium

An Ansible playbook runs tasks on a group of web servers. During a rolling update, the playbook should ensure that no more than 2 servers are taken out of service at the same time. Which play keyword should be used?

A.forks: 2
B.max_fail_percentage: 2
C.throttle: 2
D.serial: 2
AnswerD

Correct: 'serial: 2' ensures that tasks run on at most 2 hosts at a time, providing controlled rolling updates.

Why this answer

The `serial` keyword controls the batch size of hosts that Ansible executes a play against. Setting `serial: 2` ensures that only 2 web servers are processed at a time, which is exactly what is needed for a rolling update where no more than 2 servers should be taken out of service simultaneously.

Exam trap

The trap here is confusing `serial` (which controls batch size of hosts) with `forks` (which controls parallelism of task execution), leading candidates to pick `forks: 2` thinking it limits concurrency, when in fact it only limits the number of parallel task processes, not the number of hosts taken out of service simultaneously.

How to eliminate wrong answers

Option A is wrong because `forks: 2` sets the number of parallel processes Ansible uses to execute tasks across all hosts, but it does not limit the batch size of hosts that are taken out of service; with forks, all hosts can still be targeted in parallel up to the fork limit, which could take more than 2 servers out of service at once. Option B is wrong because `max_fail_percentage: 2` defines the maximum percentage of hosts that can fail before the playbook aborts, not the number of hosts processed concurrently. Option C is wrong because `throttle: 2` limits the number of concurrent task executions across a play or role, but it applies to individual tasks rather than controlling the batch size of hosts in a rolling update scenario.

Full explanation →
517
MCQmedium

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?

A.Set the variable in the inventory host_vars.
B.Pass the variable as a parameter to the role in the playbook.
C.Set the variable in the role's vars/main.yml.
D.Set the variable in the playbook's vars section.
AnswerB

Role parameters take precedence over defaults and are specific to that role invocation.

Why this answer

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.

Exam trap

The trap here is that candidates confuse the scope of playbook-level `vars` with role-specific parameter passing, assuming any variable set in the playbook's `vars` section will only affect the role, when in fact it applies to all tasks in the play.

How to eliminate wrong answers

Option A is wrong because setting the variable in inventory host_vars applies the value to all plays and roles targeting that host, not just a specific role invocation. Option C is wrong because modifying the role's vars/main.yml would change the default for every use of the role, defeating the purpose of a one-time override. Option D is wrong because setting the variable in the playbook's vars section makes it available to all roles and tasks in the play, not exclusively to the targeted role.

Full explanation →
518
MCQhard

An admin attempts to build an execution environment using the exhibited files. The build fails with an error about incompatible Python dependency. What is the most likely cause?

A.The Python requirements.txt tries to install a version of Ansible that conflicts with the version in the base image.
B.The execution-environment.yml file uses incorrect syntax for the 'dependencies' section.
C.The collections in requirements.yml are not fully qualified.
D.The base image 'ee-minimal-rhel8' is not a valid execution environment base image.
AnswerA

The base image already contains Ansible; specifying a version causes conflict.

Why this answer

The build fails because the Python `requirements.txt` file attempts to install a version of Ansible that conflicts with the version already present in the base image `ee-minimal-rhel8`. Execution environments are designed to include a specific Ansible version in the base image; adding a different version via pip creates a dependency conflict that breaks the build.

Exam trap

The trap here is that candidates often assume the error is due to syntax or invalid base images, but the question specifically mentions 'incompatible Python dependency,' which directly points to a version conflict in the pip requirements.

How to eliminate wrong answers

Option B is wrong because the `execution-environment.yml` file syntax for the 'dependencies' section is correct as shown in the exhibit (it uses a list of file references). Option C is wrong because collections in `requirements.yml` do not need to be fully qualified; they can be specified with just the collection name, and the build would still succeed. Option D is wrong because `ee-minimal-rhel8` is a valid Red Hat-provided execution environment base image, and the error message specifically points to a Python dependency conflict, not an invalid base image.

Full explanation →
519
Multi-Selecteasy

A systems administrator is securing Ansible automation. Which two practices help protect sensitive data in playbooks? (Choose two.)

Select 2 answers
A.Use ansible-vault to encrypt variable files.
B.Set the no_log flag on tasks that handle sensitive data.
C.Use the debug module with verbosity to output passwords.
D.Avoid using become: yes on tasks that access secrets.
E.Store credentials in plain text in the inventory.
AnswersA, B

Encrypts sensitive variables at rest.

Why this answer

`ansible-vault` encrypts variable files at rest using AES-256, allowing sensitive data like passwords or API keys to be stored securely in version control. When a playbook runs, the vault password must be provided (e.g., via `--ask-vault-pass` or a vault password file), and Ansible decrypts the file in memory only, never writing plaintext to disk. This ensures that sensitive values are not exposed in the playbook source code or logs.

Exam trap

The trap here is that candidates often confuse `no_log` with encryption, thinking it protects data at rest, when it only prevents output from being displayed in logs, while `ansible-vault` provides actual file-level encryption.

Full explanation →
520
MCQeasy

A playbook uses `{{ my_var | default('fallback') }}`. What is the effect?

A.If `my_var` is defined but empty, the expression evaluates to 'fallback'.
B.If `my_var` is defined but equal to None, the expression evaluates to 'fallback'.
C.The filter raises an error because 'default' is not a valid filter.
D.If `my_var` is undefined, the expression evaluates to 'fallback'.
AnswerD

Correct; default filter provides a fallback for undefined variables.

Why this answer

The `default` filter in Ansible (also known as `d()`) returns the specified fallback value only when the variable is undefined. If `my_var` is defined but empty or None, the filter returns the variable's value (empty string or None), not the fallback. This behavior is specific to the `default` filter's default mode; to also catch empty or None values, you must use `default('fallback', true)`.

Exam trap

The trap here is that candidates often confuse 'undefined' with 'falsy' (empty, None, 0), assuming the default filter replaces all falsy values, but Ansible's default filter only triggers on undefined variables unless the `true` parameter is explicitly added.

How to eliminate wrong answers

Option A is wrong because if `my_var` is defined but empty, the `default` filter without the `true` parameter returns the empty string, not 'fallback'. Option B is wrong because if `my_var` is defined and equal to None, the filter returns None (since None is a defined value), not 'fallback'. Option C is wrong because `default` is a valid Jinja2 filter that Ansible inherits; it does not raise an error.

Full explanation →
Page 6

Page 7 of 7

All pages

1234567

Practice EX294 by domain

Target a specific domain to shore up weak areas.

Deploy Ansible Automation PlatformManage inventories and credentialsManage task execution and rolesCoordinate rolling updatesTransform data with filters and pluginsCreate content collections and execution environmentsImplement advanced Ansible automationManage automation security and operations
See all domains with question counts →