Courseiva

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

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

Take a mock examExam hub
Page 6

Page 7 of 7

451
Multi-Selecthard

Which THREE plugins are used for data transformation in Ansible?

Select 3 answers
A.connection
B.lookup
C.filter
D.callback
E.cache
AnswersB, C, E

Lookup plugins fetch and transform data from sources like files, env, etc.

Why this answer

Lookup plugins (B) are used to access external data sources (e.g., files, databases, environment variables) and bring that data into Ansible for transformation or use in tasks. Filter plugins (C) are specifically designed to manipulate and transform data within a playbook, such as converting strings, formatting JSON, or performing mathematical operations. Cache plugins (E) store and retrieve cached data (e.g., facts) to improve performance, which involves data transformation for serialization/deserialization.

Exam trap

The trap here is that candidates often confuse lookup plugins (which fetch data) with filter plugins (which transform data), or assume callback plugins (which handle output) are involved in data manipulation, but only filters, lookups, and caches directly transform or prepare data for use.

Full explanation →
452
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

Option A is correct because `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 →
453
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 →
454
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

Option B is correct because 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 →
455
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

Option C is correct because 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 →
456
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)`
AnswerD

Correct; combine merges dict2 into dict1, with dict2 overriding.

Why this answer

Option D is correct because the `combine` filter in Ansible merges two dictionaries, and when used with the pipe operator, the left-hand dictionary's values take precedence for overlapping keys. Here, `dict1 | combine(dict2)` ensures that for the overlapping key `b`, the value from `dict2` (3) overwrites the value from `dict1` (2), producing `{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 →
457
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 correct answer is C because 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 →
458
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

Variables defined in group_vars/all.yml are applied globally to all hosts and are accessible by all roles. This is the standard way to share common variables across roles in a playbook.

Full explanation →
459
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 →
460
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

Option D is correct because 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 →
461
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

Option A is correct because the pull policy "missing" means the image will be pulled if not present locally. Option B is incorrect because the pull policy is set in the config, not requiring CLI flags. Option C is incorrect because podman is a valid container engine in ansible-navigator.

Option D is incorrect because the source path `/home/user/project` is absolute.

Full explanation →
462
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

Option B is correct because 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 →
463
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

Option A is correct because `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 →
464
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

Options A and C are correct. Option B is false because only one rescue section per block is allowed. Option D is false because rescue runs only on hosts where the block failed.

Option E is false because blocks can be nested.

Full explanation →
465
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

Option E is correct because 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 →
466
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

Option C is correct because 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 →
467
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

Using ansible-vault encrypt_string is the standard method to encrypt sensitive data. Option A (no_log) hides output but the password is still in plain text. Option C (unprotected file) is insecure.

Option D (environment variable) can be seen in process listings.

Full explanation →
468
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

Option A is correct because 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 →
469
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
AnswersB, D, E

The `password` lookup generates random strings for passwords.

Why this answer

Option B is correct because the `password` lookup plugin in Ansible is specifically designed to generate random passwords with configurable length and character sets. It can also generate random MAC addresses when used with the `mac` parameter, but the core purpose is password generation, making this a valid use of a lookup plugin.

Exam trap

The trap here is that candidates often confuse the `pipe` lookup plugin with the `shell` or `command` modules, mistakenly thinking it executes commands on remote hosts, when in fact it runs locally on the control node.

Full explanation →
470
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

Option B is correct because 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 →
471
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 →
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

Option A is correct because using a single inventory with groups for each environment and assigning credentials at the group level is a best practice for organizing inventories. Option D is correct because defining separate credential types for each environment with unique Vault IDs ensures secure isolation of secrets. Option B is incorrect because using a single credential with overrides defeats the purpose of credential separation and is hard to manage.

Option C is incorrect because storing vault passwords in files on the controller is less secure than using Vault IDs. Option E is incorrect because using the same vault password for all environments reduces security.

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

Option C is correct because 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

Option B is correct because if rescue also fails, the overall play fails. Option A is wrong because rescue failure propagates. Option C is wrong because no automatic retry.

Option D is wrong because block is not re-executed.

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

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

Option C (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

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

Option A is correct because 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 →
478
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

Option B is correct because 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 →
479
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

Options A and D are correct. A: The setup playbook is used to deploy AAP components. D: Automation controller and private automation hub can be installed on separate nodes for scalability.

B is incorrect because subscription-manager attach is not required if using local repos. C is incorrect because postgreSQL must be separate from the controller node in a standard installation. E is incorrect because the installer creates the admin user based on the inventory file.

Full explanation →
480
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

Option C is correct because 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 →
481
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

Option C is correct because `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 →
482
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 →
483
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

Option D is correct because 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 →
484
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

Option A is correct because 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 →
485
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 →
486
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

Option A is correct because 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 →
487
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

Option A is correct because 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 →
488
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

Option A is correct because 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 →
489
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

Option C is correct because 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 →
490
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

Option D is correct because `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 →
491
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

Option C is correct because import_playbook includes tasks at parse time, so check mode applies to all tasks. Option A is wrong because imported playbooks are not skipped. Option B is wrong because check mode applies to all plays.

Option D is wrong because import_playbook supports check mode.

Full explanation →
492
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

Option A is correct because 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 →
493
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 →
494
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

Option A is correct because 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 →
495
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 →
496
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

Option D is correct because `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 →
497
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

Option A is correct because 'run_once: true' combined with delegate_to ensures the task runs only once, preventing overwrites. Option B serializes all tasks, which is inefficient. Option C throttles task concurrency but still runs on each host.

Option D serializes batches but still multiple executions. Therefore, A is best.

Full explanation →
498
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: tags allow tasks to be selected with --tags.

Why this answer

Option C is correct because tagging tasks with 'tags: ' allows selective execution. Options A, B, D do not enable tag filtering.

Full explanation →
499
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.

Full explanation →
500
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

Option B is correct because async tasks only start the job; the actual result must be checked with the 'async_status' module. If not checked, the playbook assumes success. Options A and C are about timing but not the core issue.

Option D would ignore errors but not cause a false success. Therefore, B is most likely.

Full explanation →
501
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

Option A is correct because 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 →
502
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 →
503
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

Option C is correct because 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 →
504
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

Option B is correct because 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 →
505
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

Option C is correct because Ansible's variable precedence dictates that group_vars/<group_name>.yml files override group_vars/all.yml for hosts in that group. By defining `server_role` per group file (web, app, db), each server gets the correct role without modifying the playbook structure. This leverages Ansible's built-in group variable inheritance to resolve the misconfiguration cleanly.

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 →
506
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 B and D are correct. B: The task must be run on the control node, so delegation is implied. D: local_action uses the local connection plugin, which typically uses the 'local' connection, not SSH.

A is wrong because local_action does not require become. C is wrong because inventory is not required for local_action. E is wrong because there is no 'local' module; it's a directive.

Full explanation →
507
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.

Full explanation →
508
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 →
509
MCQhard

The playbook above fails with an error. 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 requires a regex pattern as an argument. The correct syntax is `select('match', 'pattern')`. Without a pattern, Ansible raises an error.

Option A is incorrect because quotes around the test name are fine. Option C is incorrect because `select` works on lists and does not need `selectattr` for simple matching. Option D is incorrect because there is no 'filter' plugin used here.

Full explanation →
510
MCQeasy

An organization has multiple inventories for different environments. They want to reuse a set of hosts across inventories without duplicating host definitions. Which feature should they use?

A.Inventory sources
B.Shared inventories
C.Inventory groups
D.Smart inventories
AnswerD

Smart inventories can include hosts from multiple inventories based on filters.

Why this answer

Option D is correct because Smart inventories allow dynamic grouping of hosts from multiple sources based on filters. Option A is incorrect because groups are within a single inventory. Option B is incorrect because inventory sources populate a single inventory.

Option C is incorrect because there is no 'shared inventory' feature.

Full explanation →
511
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 →
512
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 →
513
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

Option D is correct because 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 →
514
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

Option A is correct because 'serial: 2' processes hosts in batches of 2, limiting concurrency. Option B controls total forks but not batching. Option C sets a failure threshold.

Option D throttles task concurrency but not host batching. Therefore, A is correct.

Full explanation →
515
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

Option D (role parameters) is correct because they are passed directly to the role in the playbook and override defaults. Option A (role vars) have higher priority but are static. Option B (playbook vars) apply to all roles.

Option C (inventory vars) apply to all hosts/roles.

Full explanation →
516
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 →
517
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

Option A is correct because `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 →
518
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

Option D is correct because 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 →