Courseiva

CCNA Inventories Credentials Questions

75 questions · Inventories Credentials topic · All types, answers revealed

Practice these questionsExam hubAll questions
1
MCQhard

A DevOps engineer is designing a dynamic inventory script for a cloud provider. The script must return host variables in a specific JSON format. According to Ansible best practices, which top-level keys should be present in the script output?

A.Group names as keys, each containing 'hosts' and 'vars'
B.all, groups, hosts
C.List of host objects
D.inventory, hosts, vars
AnswerA

Required format for dynamic inventory output.

Why this answer

Ansible dynamic inventory scripts must return JSON with group names as top-level keys, each containing 'hosts' (a list of hostnames) and optionally 'vars' (dictionary of group variables). This structure allows Ansible to map hosts to groups and apply group-level variables, which is essential for inventory organization and playbook targeting. Option A correctly describes this required format per Ansible best practices.

Exam trap

The trap here is that candidates confuse the dynamic inventory JSON schema with the structure of an Ansible inventory file (INI or YAML) or with the output of the 'ansible-inventory' command, leading them to select options like 'all, groups, hosts' or 'inventory, hosts, vars' instead of recognizing that group names must be the top-level keys.

How to eliminate wrong answers

Option B is wrong because 'all', 'groups', and 'hosts' are not the required top-level keys; 'all' is a default group in Ansible but not a mandatory key in the script output, and 'groups' and 'hosts' are not valid top-level keys for the inventory JSON structure. Option C is wrong because a list of host objects does not provide the group-based hierarchy Ansible expects; the script must return a dictionary with group names as keys, not a flat list. Option D is wrong because 'inventory', 'hosts', and 'vars' are not the correct top-level keys; the inventory script output must use group names as keys, and 'inventory' is not a recognized key in the dynamic inventory JSON schema.

Practice this question →
2
MCQeasy

An Ansible Tower administrator wants to allow a team to run playbooks against a set of production web servers without giving them direct SSH access to the hosts. Which inventory configuration approach should be used?

A.Use the ad hoc inventory feature to specify hosts at launch time
B.Define a group variable for production web servers in the inventory
C.Create a static inventory and add each web server manually
D.Create a smart inventory and use the 'prod_web' tag to filter hosts
AnswerD

Smart inventories dynamically filter hosts based on criteria like tags, enabling automatic grouping.

Why this answer

Smart inventories in Ansible Tower allow you to define a dynamic set of hosts based on a filter, such as a tag (e.g., 'prod_web'). This enables the team to run playbooks against production web servers without granting them direct SSH access to the hosts, as Tower manages the SSH connections centrally using its own credentials.

Exam trap

The trap here is that candidates often confuse smart inventories with static inventories or group variables, failing to recognize that smart inventories are the only option that provides dynamic, tag-based host filtering without requiring direct SSH access.

How to eliminate wrong answers

Option A is wrong because the ad hoc inventory feature is used for one-off, temporary host lists at launch time, not for persistent, tag-based filtering of production web servers. Option B is wrong because defining a group variable for production web servers does not restrict access or filter hosts dynamically; it only sets variables for that group. Option C is wrong because creating a static inventory and adding each web server manually is not scalable and does not leverage Tower's dynamic filtering capabilities to control access without direct SSH.

Practice this question →
3
MCQhard

A company manages its infrastructure using Ansible Tower. There are two teams: Team Alpha manages web servers in the 'webservers' group, and Team Beta manages database servers in the 'dbservers' group. Both teams need to use the same SSH credential to connect to their respective servers. The credential is stored in Tower as 'shared_ssh_key'. Team Alpha reports that they can launch jobs against the 'webservers' group, but Team Beta gets an error when trying to launch jobs against the 'dbservers' group: 'You do not have permission to use this credential.' Both teams are members of the same organization. The inventory is a single inventory source with separate groups. The credential has been assigned to the organization. What is the most likely cause of Team Beta's issue, and what is the correct solution?

A.Grant Team Beta the 'Use' role on the credential 'shared_ssh_key'.
B.Create a new credential with the same SSH key and assign it to Team Beta.
C.Assign the credential to the dbservers group in the inventory.
D.Move the credential from the organization to the project level.
AnswerA

Explicit 'Use' permission allows Team Beta to use the credential in jobs.

Why this answer

In Ansible Tower, credentials are assigned to an organization, but users or teams must be explicitly granted the 'Use' role on a credential to be able to use it in a job template. Team Alpha can use the credential because they likely have the 'Use' role, while Team Beta does not. Granting Team Beta the 'Use' role on 'shared_ssh_key' resolves the permission error.

Exam trap

The trap here is that candidates assume assigning a credential to an organization automatically grants all members the right to use it, but Tower requires explicit 'Use' role assignment for each team or user.

How to eliminate wrong answers

Option B is wrong because creating a duplicate credential violates the principle of least privilege and adds unnecessary management overhead; the existing credential can be shared by granting the 'Use' role. Option C is wrong because credentials are not assigned to inventory groups in Tower; they are assigned to organizations, projects, or job templates, and the error is about credential permissions, not inventory group assignments. Option D is wrong because moving the credential to the project level does not change the fact that Team Beta lacks the 'Use' role; the credential would still require explicit role assignment for the team to use it.

Practice this question →
4
Multi-Selecthard

Which THREE of the following are best practices for managing credentials in Ansible Automation Controller?

Select 3 answers
A.Avoid using external secret management systems; keep all secrets in Automation Controller
B.Share the same credential across multiple organizations for simplicity
C.Restrict credential 'Use' permissions to specific users or teams
D.Use custom credential types to store secrets for third-party APIs
E.Use Vault credentials to store and encrypt sensitive variables in playbooks
AnswersC, D, E

This ensures only authorized users can use the credential.

Why this answer

Option C is correct because Ansible Automation Controller's Role-Based Access Control (RBAC) allows administrators to assign granular 'Use' permissions to specific users or teams, ensuring that only authorized entities can leverage a credential for job runs. This prevents unauthorized access to sensitive secrets and aligns with the principle of least privilege, which is a core security best practice in automation environments.

Exam trap

The trap here is that candidates may think storing all secrets inside Automation Controller is safer than using an external vault, but Red Hat specifically recommends integrating with external secret managers for centralized control and rotation, making Option A a common misconception.

Practice this question →
5
MCQhard

The job template running against host db1 uses a machine credential with an SSH key. The key is correctly configured in Automation Controller. However, the job fails with the error shown. What is the most likely cause?

A.The SSH public key corresponding to the private key is not installed on the target host
B.The vault password is incorrect
C.The SSH port is blocked by a firewall
D.The host's SSH host key has changed and the known_hosts file is outdated
AnswerA

Permission denied (publickey) indicates the key is not accepted.

Why this answer

The error indicates that Automation Controller cannot authenticate to host db1 using the SSH key. Since the key is correctly configured in the controller, the most likely cause is that the corresponding public key is not present in the target host's ~/.ssh/authorized_keys file. SSH key-based authentication requires the private key on the client (controller) and the public key installed on the target host; without the public key, the server rejects the connection attempt.

Exam trap

The trap here is that candidates often assume the SSH key error is due to network or firewall issues, but the specific 'Permission denied (publickey)' message points directly to a missing or mismatched public key on the target host, not connectivity or host key verification.

How to eliminate wrong answers

Option B is wrong because a vault password is used to decrypt encrypted variables or files, not for SSH authentication; an incorrect vault password would cause a decryption failure, not an SSH key authentication error. Option C is wrong because a blocked SSH port (default 22) would result in a connection timeout or 'Connection refused' error, not an authentication failure related to keys. Option D is wrong because an outdated known_hosts file causes a host key verification failure (e.g., 'REMOTE HOST IDENTIFICATION HAS CHANGED'), not an authentication error with the SSH key itself.

Practice this question →
6
MCQhard

An organization uses multiple Satellite servers for inventory. They want to combine data from all satellites into one unified inventory in Ansible Tower. Which approach is best?

A.Use a custom script to fetch and merge data from all Satellites into a single inventory source.
B.Create a smart inventory that includes all satellites.
C.Use a single Satellite server that aggregates data from all other Satellites.
D.Create one inventory with multiple inventory sources, each pointing to a different Satellite.
AnswerD

Multiple inventory sources can populate the same inventory, merging hosts.

Why this answer

Option D is correct because Ansible Tower allows you to create a single inventory with multiple inventory sources, each configured to sync from a different Satellite server. This approach consolidates all host data into one unified inventory without custom scripting or requiring a central aggregator, leveraging Tower's native multi-source inventory capabilities.

Exam trap

The trap here is that candidates may confuse 'smart inventory' with the ability to aggregate external sources, but smart inventories only filter existing inventory data and cannot import from multiple external sources directly.

How to eliminate wrong answers

Option A is wrong because using a custom script to fetch and merge data introduces unnecessary complexity, maintenance overhead, and bypasses Tower's built-in inventory source management, which is designed for this exact use case. Option B is wrong because a smart inventory filters hosts based on existing inventory data and cannot directly import data from multiple external sources like Satellite servers; it requires a pre-populated inventory. Option C is wrong because requiring a single Satellite server to aggregate data from others adds an extra layer of infrastructure and defeats the purpose of using multiple independent Satellite servers, which Tower can directly query.

Practice this question →
7
Multi-Selectmedium

Which THREE of the following are valid ways to define host variables in an Ansible inventory? (Choose exactly three.)

Select 3 answers
A.In the 'extra_vars' field of the job template.
B.Inline in the inventory file, e.g., 'myhost ansible_host=192.168.1.1 http_port=8080'.
C.In a credential's 'Input Configuration' as a secret variable.
D.In a 'group_vars/<groupname>' file, if the host belongs to that group.
E.In a 'host_vars/<hostname>' file within the project.
AnswersB, D, E

Variables can be assigned directly in the inventory file.

Why this answer

Option B is correct because Ansible allows inline host variable definitions directly in the inventory file using key=value pairs after the hostname. This is a standard syntax where variables like 'http_port=8080' are assigned to the host 'myhost' and become available as Ansible facts during playbook execution. The 'ansible_host' special variable is also defined this way to override the connection address.

Exam trap

The trap here is that candidates confuse runtime variable injection methods (like extra_vars or credentials) with static inventory variable definitions, leading them to select options that are valid for passing variables but not for defining host variables in an inventory.

Practice this question →
8
MCQhard

A company uses Ansible Automation Controller to manage a mix of Linux and Windows servers. Each server is in a separate inventory group. The Linux servers use SSH keys stored in machine credentials, and the Windows servers use username/password stored in machine credentials. Recently, a new security policy requires that all credentials must be rotated every 90 days. The automation team has 50 Linux servers and 20 Windows servers. They want to minimize manual effort and avoid exposing secrets in plain text during rotation. They currently have a Jenkins pipeline that can run scripts on the controller node. Which approach best meets the requirements?

A.Use a Vault credential to store the new secrets and reference them in the job template
B.Write a script that uses the Automation Controller API to update the credential's inputs (e.g., new SSH key or password) after rotating them on the target servers
C.Store the new passwords directly in a playbook and run it manually on each server, then update the credential in the UI
D.Create a single machine credential with the same SSH key for all Linux servers and a single credential for all Windows servers
AnswerB

The API allows programmatic rotation without exposing secrets in logs or playbooks.

Why this answer

Option B is correct because it uses the Automation Controller API to programmatically update credential inputs (SSH keys or passwords) after rotating them on the target servers, which minimizes manual effort, avoids exposing secrets in plain text (the API call uses HTTPS and authentication tokens), and satisfies the 90-day rotation policy. The Jenkins pipeline can invoke a script that first rotates the secret on each server (e.g., via SSH or WinRM) and then calls the API's PATCH endpoint for the credential to update the stored value, ensuring the credential remains synchronized without manual UI intervention.

Exam trap

The trap here is that candidates may assume a Vault credential (Option A) automates rotation, but it only stores secrets securely and does not programmatically update them; the exam tests understanding that the API is the correct mechanism for automated credential updates without manual steps.

How to eliminate wrong answers

Option A is wrong because a Vault credential stores secrets in a secure vault but does not automate the rotation process; it still requires manual steps to generate and inject new secrets, and referencing it in a job template does not update the credential's value on the controller. Option C is wrong because storing new passwords directly in a playbook exposes them in plain text (even if encrypted with ansible-vault, the playbook would need to be manually updated and run on each server, then the credential updated in the UI, which is not automated and violates the requirement to avoid exposing secrets in plain text during rotation). Option D is wrong because using a single machine credential for all Linux servers and a single credential for all Windows servers violates the requirement that each server is in a separate inventory group and would break the ability to rotate credentials per server or per group, as well as creating a security risk if one key is compromised.

Practice this question →
9
Matchingmedium

Match each Linux file system path to its typical content.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts
Matches

Configuration files

Variable data (logs, databases)

User system resources (binaries, libraries)

Temporary files

Process and kernel information

Why these pairings

Standard FHS directories for Red Hat Enterprise Linux.

Practice this question →
10
MCQmedium

Refer to the exhibit. A user runs a playbook that creates hosts and then attempts to use a constructed inventory plugin. However, the constructed inventory does not group hosts by OS distribution. What is the most likely cause?

A.The constructed plugin cannot be used with the add_host module.
B.The 'strict: false' setting ignores missing variables, causing the group to be empty.
C.The constructed inventory runs before add_host tasks, so the hosts are not yet created.
D.The variable ansible_distribution is not defined because gather_facts is set to no.
AnswerC

Inventory plugins execute at inventory load time, not during playbook execution.

Why this answer

The constructed inventory plugin processes inventory sources and applies Jinja2 conditions to group hosts based on variables. However, when used in a playbook alongside the `add_host` module, the constructed inventory is evaluated at the start of the play, before any tasks (including `add_host`) run. Therefore, hosts added dynamically via `add_host` do not exist when the constructed plugin attempts to group them, causing the groups to be empty.

Option C correctly identifies this ordering issue.

Exam trap

Red Hat often tests the misconception that inventory plugins and dynamic host creation (`add_host`) operate in the same phase, when in fact the constructed plugin runs during inventory loading (pre-task) while `add_host` runs during task execution, creating a timing mismatch that candidates overlook.

How to eliminate wrong answers

Option A is wrong because the constructed plugin can absolutely be used with hosts created by `add_host` — the issue is not compatibility but execution order. Option B is wrong because `strict: false` does not cause groups to be empty; it merely suppresses errors when a variable is undefined, but if the hosts themselves are not yet present, no grouping can occur regardless of strict mode. Option D is wrong because even if `gather_facts` is set to `no`, the constructed plugin can still use other variables or static facts; the core problem remains that the hosts are not yet added to the inventory at the time the plugin runs.

Practice this question →
11
MCQeasy

An administrator needs to store a database password securely for use in playbooks. Which credential type should they create?

A.Vault credential
B.Source control credential
C.Machine credential
D.Network credential
AnswerA

Vault credentials securely store encrypted secrets like passwords.

Why this answer

A Vault credential is the correct choice because Ansible Vault is specifically designed to encrypt sensitive data like passwords, API keys, and other secrets used in playbooks. It allows the administrator to store the database password in an encrypted file that can be decrypted at runtime using a vault password, ensuring the secret is not exposed in plaintext in the playbook or inventory.

Exam trap

The trap here is that candidates may confuse 'Machine credential' (used for SSH/WinRM access to hosts) with a general-purpose secret store, not realizing that Ansible Vault is the dedicated mechanism for encrypting sensitive data like database passwords within playbooks.

How to eliminate wrong answers

Option B (Source control credential) is wrong because it is used to authenticate to Git or other version control systems to sync projects, not to store secrets for use in playbooks. Option C (Machine credential) is wrong because it is used for SSH or WinRM authentication to managed hosts, not for storing arbitrary secrets like database passwords. Option D (Network credential) is wrong because it is used for network device authentication (e.g., SNMP, API tokens for network appliances), not for storing database passwords for playbook use.

Practice this question →
12
MCQhard

A job template uses a custom credential type that injects environment variables for a third-party API. The credential input defines a field 'api_key'. The playbook uses {{ api_key }} but it's empty. What is the most likely cause?

A.The injector configuration is missing or incorrect.
B.The field name is case-sensitive and the playbook uses a different case.
C.The credential was not assigned to the job template.
D.The playbook uses a different variable name.
AnswerA

Without injector, the credential's inputs are not made available to the playbook.

Why this answer

The most likely cause is that the injector configuration is missing or incorrect. In Ansible Tower/AWX, a custom credential type requires an injector definition (e.g., `env` or `file`) to map the credential input fields into environment variables or extra vars. Without a proper injector, the `api_key` field is never exposed to the job environment, so `{{ api_key }}` resolves to an empty string.

Exam trap

The trap here is that candidates assume simply defining an input field automatically makes it available as a variable, but without a correct injector configuration, the value is never injected into the job environment.

How to eliminate wrong answers

Option B is wrong because Ansible variable names are case-sensitive, but the playbook uses `{{ api_key }}` which matches the credential input field name `api_key` exactly, so case is not the issue. Option C is wrong because if the credential were not assigned to the job template, the job would fail with a credential not found error, not silently produce an empty variable. Option D is wrong because the playbook uses `{{ api_key }}` which matches the credential input field name; a different variable name would cause an undefined variable error, not an empty string.

Practice this question →
13
MCQeasy

A company uses a static inventory file for Ansible Tower. They need to add a new host to an existing group. Which action should they take?

A.Edit the inventory in the Tower UI and add the host to the group.
B.Use the ansible-inventory command to add the host.
C.Modify the static inventory file and run a job template.
D.Create a new inventory and host group.
AnswerA

Directly editing the inventory via UI is the correct method for static inventories.

Why this answer

Option A is correct because the company uses a static inventory file for Ansible Tower, and the Tower UI provides a built-in interface to manage static inventories. Editing the inventory in the Tower UI and adding the host to the group directly updates the underlying static inventory file and synchronizes it with Tower's database, ensuring the host is available for job runs without manual file manipulation.

Exam trap

The trap here is that candidates may think modifying the static inventory file directly (Option C) is sufficient, but they overlook that Tower requires a sync or UI-based edit to recognize the change, and simply running a job template does not refresh the inventory.

How to eliminate wrong answers

Option B is wrong because the ansible-inventory command is used to display or dump inventory contents, not to modify static inventory files; it cannot add hosts to a group. Option C is wrong because modifying the static inventory file manually does not automatically update Tower's inventory cache; you would need to sync or refresh the inventory in Tower, not just run a job template. Option D is wrong because creating a new inventory and host group is unnecessary and inefficient; the existing group can be edited directly to add the new host.

Practice this question →
14
MCQmedium

Ansible Tower is configured with a dynamic inventory source from VMware vCenter. The playbook needs to limit execution to hosts with a specific custom attribute. How should this be achieved?

A.Modify the VMware inventory script to filter hosts.
B.Use a smart inventory filter.
C.Add the required hosts manually.
D.Create a new inventory source with a filter.
AnswerB

Smart inventories can filter hosts based on custom attributes from the dynamic source.

Why this answer

Smart inventories in Ansible Tower allow you to apply a filter (using Jinja2-style syntax) against an existing inventory source, such as a dynamic VMware vCenter source, to limit execution to hosts matching specific criteria like a custom attribute. This approach avoids modifying the source script or creating duplicate inventory sources, preserving the dynamic nature of the inventory while enabling targeted host selection.

Exam trap

The trap here is that candidates may think they need to modify the inventory source or script to filter hosts, not realizing that Tower's smart inventories provide a built-in, non-destructive way to apply filters on top of any existing inventory source.

How to eliminate wrong answers

Option A is wrong because modifying the VMware inventory script is not a supported or scalable method in Tower; it would break the dynamic inventory source and require manual maintenance. Option C is wrong because manually adding hosts defeats the purpose of using a dynamic inventory from vCenter and introduces management overhead. Option D is wrong because creating a new inventory source with a filter is unnecessary; smart inventories provide the filtering capability without duplicating the source, and filters are applied at the smart inventory level, not at the source level.

Practice this question →
15
Multi-Selecthard

Which THREE considerations are important when using dynamic inventories in Ansible Tower?

Select 3 answers
A.Dynamic inventory groups can be nested under static groups.
B.Each inventory source can be assigned to multiple inventories.
C.The inventory source must have a defined credential for authentication to the cloud provider.
D.Custom inventory scripts must be placed in the Tower home directory.
E.Inventory sources can update automatically on a schedule.
AnswersA, C, E

Group hierarchies can mix static and dynamic groups.

Why this answer

Option A is correct because Ansible Tower allows dynamic inventory groups to be nested under static groups, enabling a hybrid inventory structure where cloud-sourced hosts can be organized within manually defined static groups for more flexible automation targeting. This is supported by the Tower inventory model, which merges static and dynamic sources into a unified group hierarchy.

Exam trap

The trap here is that candidates may confuse the one-to-many relationship of inventory sources to inventories (Option B) with the actual one-to-one constraint, or assume custom scripts must reside in a specific directory (Option D) when Tower actually supports flexible script paths via projects or absolute paths.

Practice this question →
16
MCQmedium

A playbook requires a secret token that changes every hour. The token is stored in a password vault. Which setting should be used to have Tower retrieve the token at runtime?

A.Use a custom credential type that injects the vault lookup result.
B.Hard-code the token in the playbook.
C.Store the token in extra_vars on the job template.
D.Store the token in the project as a file.
AnswerA

Custom credential types can be configured to look up secrets dynamically.

Why this answer

Option A is correct because Ansible Tower (now Red Hat Ansible Automation Platform) supports custom credential types that can define input and injector configurations. By using a custom credential type with an injector that includes a lookup plugin (e.g., `{{ lookup('hashi_vault', 'secret/data/token') }}`), Tower can retrieve the secret token from a password vault (like HashiCorp Vault) at runtime, ensuring the token is always current without hard-coding or manual updates.

Exam trap

The trap here is that candidates may think extra_vars or project files are dynamic enough for runtime secret retrieval, but they fail to recognize that only custom credential types with lookup plugins can fetch secrets from an external vault at job execution time, not at job template definition time.

How to eliminate wrong answers

Option B is wrong because hard-coding the token in the playbook violates security best practices and would require manual updates every hour, making automation impractical. Option C is wrong because storing the token in extra_vars on the job template would require manual updates each hour and does not support dynamic retrieval from a vault; extra_vars are static at job launch time. Option D is wrong because storing the token as a file in the project would require manual file updates and does not integrate with a password vault for dynamic retrieval; project files are static and version-controlled, not suitable for frequently changing secrets.

Practice this question →
17
Multi-Selecthard

An Ansible Tower administrator needs to create a custom credential type that uses an SSH private key and a username. Which THREE components should be defined in the credential type's configuration?

Select 3 answers
A."fields": [{"id": "ssh_key_data", "type": "string", "label": "SSH Private Key", "multiline": true, "secret": true}]
B."fields": [{"id": "password", "type": "string", "label": "Password"}]
C."fields": [{"id": "key_type", "type": "string", "label": "Key Type"}]
D."fields": [{"id": "username", "type": "string", "label": "Username"}]
E."injectors": {"extra_vars": {"ansible_user": "{{ username }}", "ansible_ssh_private_key_file": "{{ ssh_key_data }}"}}
AnswersA, D, E

Input field for SSH private key content.

Why this answer

Option A is correct because the SSH private key must be defined as a field with `"type": "string"`, `"multiline": true` (since SSH keys are multi-line), and `"secret": true` (to encrypt the value in the database). This matches the standard Ansible Tower custom credential type schema for storing sensitive key material.

Exam trap

The trap here is that candidates often add unnecessary fields like 'password' or 'key type' because they confuse SSH key-based authentication with password-based authentication, or they think the key format must be explicitly specified.

Practice this question →
18
MCQmedium

A system administrator maintains a dynamic inventory script that queries a cloud provider API to build host lists. The script returns valid JSON, but after importing into Ansible Tower, the inventory shows zero hosts. The script is executable and placed in the expected project directory. What is the most likely cause?

A.The script does not output JSON in the correct format expected by Ansible Tower.
B.The script does not have the executable permission set.
C.The script has not been added as an inventory script in Ansible Tower's inventory scripts settings.
D.The script is written in a language that Ansible Tower does not support.
AnswerC

Dynamic inventory scripts must be registered in Tower.

Why this answer

Option C is correct because Ansible Tower requires that a dynamic inventory script be explicitly registered as an inventory script in the Tower UI under 'Inventories' → 'Scripts'. Even if the script is executable and returns valid JSON, Tower will not execute it unless it is configured as a custom inventory script source. The script must be added via the 'Add' button in the Inventory Scripts section, where Tower will then use it to populate the inventory.

Exam trap

The trap here is that candidates assume making a script executable and placing it in the project directory is sufficient, but Ansible Tower requires explicit registration of the script as an inventory source, unlike standalone Ansible which can use the script directly via the '-i' flag.

How to eliminate wrong answers

Option A is wrong because the question states the script returns valid JSON, and Ansible Tower accepts any valid JSON that follows the expected host/group structure (e.g., a dictionary with 'group_name' keys and 'hosts' lists). Option B is wrong because the question explicitly states the script is executable, so permission is not the issue. Option D is wrong because Ansible Tower supports any scripting language that can be executed via a shebang line (e.g., Python, Bash, Ruby) as long as the script is executable and outputs JSON to stdout.

Practice this question →
19
MCQeasy

An Ansible playbook uses the `ansible_password` variable to connect to a Windows host. The value is stored in an encrypted Ansible Vault file. Which credential type in Automation Controller would allow the vault password to be supplied at runtime?

A.Cloud credential
B.Machine credential
C.Vault credential
D.Network credential
AnswerC

Vault credentials provide the vault password to decrypt vault-encrypted files.

Why this answer

Option C is correct because Automation Controller's Vault credential type is specifically designed to provide the vault password needed to decrypt Ansible Vault-encrypted variables like `ansible_password`. When a job runs, the controller uses this credential to unlock the vault file, allowing the playbook to access the encrypted value at runtime without exposing the plaintext password.

Exam trap

The trap here is that candidates confuse the credential type used to authenticate to the target host (Machine credential) with the credential type needed to decrypt the vault file containing the host's password, leading them to select Option B instead of C.

How to eliminate wrong answers

Option A is wrong because Cloud credentials are used to authenticate against cloud providers (e.g., AWS, Azure, GCP) and have no mechanism to supply a vault password for decrypting Ansible Vault files. Option B is wrong because Machine credentials provide SSH keys or username/password for connecting to target hosts, not the vault password needed to decrypt encrypted variables stored in vault files. Option D is wrong because Network credentials are used for network device authentication (e.g., via SSH or API tokens) and do not support supplying vault passwords for Ansible Vault decryption.

Practice this question →
20
MCQmedium

The inventory above is used in a job template in Automation Controller. The job template also has a machine credential assigned that specifies username 'root' and an SSH key. When the job runs against host web1, which username will Ansible use to connect?

A.admin (from inventory host variable)
B.The username set in the job template's 'extra variables'
C.The first defined username in the credential chain
D.root (from credential)
AnswerA

Inventory host variables take precedence over credential settings.

Why this answer

Option A is correct because Ansible uses a specific precedence order for determining the connection user. When a host variable (like `ansible_user: admin`) is defined in the inventory for host web1, it overrides the username set in the job template's machine credential. The credential's username ('root') acts only as a fallback if no `ansible_user` is defined at the host or group level.

Exam trap

The trap here is that candidates assume the credential's username is always used, forgetting that inventory host variables (like `ansible_user`) override credential settings, a common point of confusion in Ansible's variable precedence hierarchy.

How to eliminate wrong answers

Option B is wrong because extra variables in the job template do not directly set the connection username; they are used for playbook variables, not for the SSH user unless explicitly referenced via `ansible_user` in the extra vars. Option C is wrong because there is no 'credential chain' that selects the first username; Ansible uses a deterministic precedence: host vars > group vars > credential username > default (current user). Option D is wrong because the credential's username ('root') is overridden by the host variable `ansible_user: admin` defined in the inventory for web1.

Practice this question →
21
MCQeasy

A systems administrator needs to use a different SSH private key for a group of hosts in an Ansible inventory. Which inventory variable should be set at the group level?

A.ansible_ssh_key
B.ansible_ssh_private_key_file
C.ansible_ssh_key_file
D.ansible_private_key
AnswerB

Correct variable for SSH private key path.

Why this answer

Option B is correct because `ansible_ssh_private_key_file` is the Ansible inventory variable that specifies the path to the SSH private key file for a host or group. When set at the group level, it applies to all hosts in that group, allowing the administrator to use a different key for authentication without modifying individual host definitions.

Exam trap

The trap here is that candidates confuse the variable name with similar-sounding but invalid options like `ansible_ssh_key` or `ansible_private_key`, forgetting that Ansible requires the exact `ansible_ssh_private_key_file` syntax to specify a private key file path.

How to eliminate wrong answers

Option A is wrong because `ansible_ssh_key` is not a valid Ansible variable; the correct variable name includes `private_key_file` to indicate the file path. Option C is wrong because `ansible_ssh_key_file` is not a recognized variable; Ansible uses `ansible_ssh_private_key_file` to avoid ambiguity with public keys. Option D is wrong because `ansible_private_key` omits the `ssh` connection plugin prefix and the `file` suffix, making it an invalid variable that Ansible will ignore.

Practice this question →
22
MCQhard

A team uses a single Ansible Tower inventory called 'Production' containing hosts for multiple environments (dev, stage, prod). They want to apply different variables to hosts based on environment. Which inventory structure meets this requirement with minimal administrative overhead?

A.Create groups within the inventory for each environment (e.g., 'dev', 'stage', 'prod') and assign variables at the group level.
B.Assign variables directly to each host using the 'Host Variables' field in the inventory.
C.Add tags to each host and use the tags to filter variables in the job template.
D.Create separate inventories for each environment and link them to the same project.
AnswerA

Groups with group_vars is the standard approach.

Why this answer

Option A is correct because Ansible Tower (now Red Hat Ansible Automation Platform) supports group-based variable inheritance within a single inventory. By creating groups for each environment (dev, stage, prod) and assigning variables at the group level, you can apply environment-specific variables to all hosts in that group with minimal administrative overhead. This leverages Tower's built-in group variable mechanism without requiring per-host edits or multiple inventory objects.

Exam trap

The trap here is that candidates often confuse tags (which are for job template filtering and RBAC) with group variables (which are for host-level data), leading them to select option C despite tags having no role in variable assignment.

How to eliminate wrong answers

Option B is wrong because assigning variables directly to each host via the 'Host Variables' field creates significant administrative overhead when managing many hosts, as each host must be individually configured, and it does not scale well for environment-wide changes. Option C is wrong because tags in Ansible Tower are used for job template filtering and access control, not for variable assignment; variables cannot be conditionally applied based on tags within an inventory. Option D is wrong because creating separate inventories for each environment increases administrative overhead by requiring multiple inventory objects to be maintained and linked to the same project, and it does not leverage the single-inventory structure specified in the question.

Practice this question →
23
MCQhard

During a playbook run, the task 'debug: msg={{ ansible_facts.distribution }}' outputs 'CentOS' for a host. However, the host's inventory variable 'distribution' is set to 'RedHat'. The administrator expected the inventory variable to override the fact. What is the most likely cause of this behavior?

A.The 'gather_facts' directive is set to 'no' in the playbook
B.The host variable is defined in a group_var that is overridden by a host_var
C.The ansible_facts dictionary is used, which contains discovered facts that take precedence over inventory variables
D.The playbook uses the variable 'distribution' instead of 'ansible_facts.distribution'
AnswerC

Facts from the system have higher precedence than inventory variables unless using registered variables or setting fact precedence explicitly.

Why this answer

Option C is correct because in Ansible, facts discovered by the `setup` module (stored in `ansible_facts`) take precedence over inventory variables when accessed via the `ansible_facts` dictionary. The `debug` task explicitly references `ansible_facts.distribution`, which retrieves the discovered fact value ('CentOS'), not the inventory variable `distribution`. Inventory variables are stored separately and do not override facts within the `ansible_facts` namespace.

Exam trap

The trap here is that candidates confuse the variable precedence hierarchy with the explicit namespace access; they assume inventory variables always override facts, but the `ansible_facts` dictionary is a separate, immutable collection of discovered data that is not overridden by inventory variables.

How to eliminate wrong answers

Option A is wrong because setting `gather_facts: no` would prevent fact discovery entirely, causing the `ansible_facts.distribution` variable to be undefined or raise an error, not output 'CentOS'. Option B is wrong because host_vars always override group_vars in Ansible's variable precedence, but the issue here is not about precedence between inventory variable sources; it's about the explicit use of the `ansible_facts` dictionary, which bypasses inventory variables entirely. Option D is wrong because the playbook uses `ansible_facts.distribution`, not `distribution`; if it used `distribution`, the inventory variable 'RedHat' would have been output, not 'CentOS'.

Practice this question →
24
Multi-Selecthard

Which THREE considerations are important when designing a credential strategy in Ansible Automation Platform? (Choose exactly three.)

Select 3 answers
A.All credentials must be stored within the AAP database for security
B.Playbooks should contain hardcoded credentials for simplicity
C.Credentials should be assigned to job templates rather than embedded in playbooks
D.Custom credential types allow integration with external secrets management systems
E.Credential access can be restricted using RBAC on organizations, teams, and users
AnswersC, D, E

Best practice is to manage credentials via AAP and assign them to templates.

Why this answer

Option C is correct because Ansible Automation Platform (AAP) best practices dictate that credentials should be assigned to job templates, not embedded in playbooks. This decouples sensitive authentication data from automation logic, allowing credentials to be managed, rotated, and audited centrally through the AAP controller without exposing them in version-controlled playbook files.

Exam trap

The trap here is that candidates often assume all credentials must be stored inside the AAP database for security, but the platform is designed to delegate secret storage to external vaults, and the question tests awareness of that flexibility.

Practice this question →
25
MCQmedium

Refer to the exhibit. A playbook runs against the `web` group. What username will be used for host web2?

A.deploy
B.undetermined
C.admin
D.root
AnswerA

web2 inherits from group vars.

Why this answer

Option A is correct because the playbook runs against the `web` group, and host `web2` inherits the `ansible_user` variable from the group-level inventory definition. In Ansible, the `ansible_user` variable determines the SSH username for the connection. Since the exhibit (not shown here but implied) sets `ansible_user: deploy` for the `web` group, all hosts in that group, including `web2`, will use `deploy` as the SSH username unless overridden at the host level.

Exam trap

The trap here is that candidates assume the default SSH user `root` is always used, forgetting that group-level `ansible_user` variables in the inventory explicitly override that default.

How to eliminate wrong answers

Option B is wrong because the username is not undetermined; Ansible resolves the `ansible_user` variable from the group-level inventory, providing a deterministic value. Option C is wrong because `admin` is not the configured `ansible_user` for the `web` group; it would only be used if explicitly set at the group or host level. Option D is wrong because `root` is the default SSH user only when no `ansible_user` is defined, but here the group-level variable overrides that default.

Practice this question →
26
MCQmedium

An Ansible Tower administrator notices that a job template fails intermittently with a 'Host unreachable' error for a specific group of servers. The inventory is static and the host entries have correct IPs. The credential used for SSH is a machine credential with a username and password, and it works for other hosts. Upon checking the job output, the error occurs during the 'Gathering Facts' step. The SSH service on these servers is running and reachable from the Tower node. What is the most likely cause?

A.The credential's SSH private key has a passphrase that is not stored in the credential.
B.The credential type should be 'network' instead of 'machine' for these servers.
C.The inventory group has hosts defined with incorrect hostnames in the ansible_host variable.
D.The SSH service on these servers is bound to a different port than the default 22.
AnswerA

If private key requires passphrase, it must be stored in credential.

Why this answer

Option A is correct because the error occurs during the 'Gathering Facts' step, which uses SSH to connect to the managed hosts. If the SSH private key has a passphrase that is not stored in the credential, Ansible Tower cannot decrypt the key to authenticate, causing a 'Host unreachable' error even though the host is actually reachable. The credential works for other hosts only if those hosts are configured to accept password-based authentication, but the failing hosts may require key-based authentication, exposing the missing passphrase.

Exam trap

The trap here is that candidates confuse a network connectivity issue with an authentication failure, assuming 'Host unreachable' always means the host is down or the port is closed, rather than recognizing it can be caused by SSH key decryption failure during the authentication phase.

How to eliminate wrong answers

Option B is wrong because the credential type 'network' is used for network devices (e.g., switches, routers) that use protocols like SSH or SNMP, not for standard Linux servers; 'machine' is the correct type for SSH access to servers. Option C is wrong because the inventory is static and host entries have correct IPs, so the ansible_host variable is not the issue; the error occurs during fact gathering, not during hostname resolution. Option D is wrong because if the SSH service were bound to a different port, the error would consistently fail for all connection attempts, not intermittently, and the host would be unreachable from the start, not just during fact gathering.

Practice this question →
27
MCQeasy

A junior admin wants to remove a credential from Ansible Tower. Which role-based access control permission is required to delete a credential?

A.Read
B.Use
C.Execute
D.Admin
AnswerD

Admin role allows deletion of credentials.

Why this answer

In Ansible Tower, the Admin role is the only role that grants full management permissions, including the ability to delete credentials. Lower-level roles like Read, Use, and Execute only allow viewing or using credentials, not modifying or deleting them. This aligns with Tower's RBAC hierarchy where Admin is required for destructive actions on any resource.

Exam trap

The trap here is that candidates often confuse the 'Use' role with full management permissions, but 'Use' only allows credential consumption in job templates, not deletion or modification.

How to eliminate wrong answers

Option A is wrong because the Read role only allows viewing credentials, not deleting them. Option B is wrong because the Use role permits using a credential in a job template but does not grant deletion rights. Option C is wrong because the Execute role applies to job templates and projects, not to credential management, and does not include delete permissions.

Practice this question →
28
MCQhard

What is the most likely cause of the failure?

A.The inventory must be of type 'file' rather than 'scm'.
B.The source_path is incorrect because it should be a directory, not a file.
C.The source_project should reference the project ID, not name.
D.The update_cache_timeout should be a positive integer.
E.The credential type is incorrect; it should be a Source Control credential, not Machine.
AnswerE

A Machine credential is designed for SSH/WinRM, not for authenticating to a source control system. Using the appropriate credential type is essential.

Why this answer

Option B is correct because the credential type must match the service; a Machine credential is used for SSH/WinRM, not for source control. Using a Source Control credential ensures proper authentication for the SCM project. Option A is incorrect because source_path can be a file or directory; the error is authentication-related.

Option C is incorrect because update_cache_timeout=0 is valid (no caching). Option D is incorrect because source_project can accept either name or ID. Option E is incorrect because source 'scm' is valid for sourcing inventory from a project.

Practice this question →
29
MCQhard

An Ansible Tower administrator notices that a job template using a dynamic inventory source from AWS EC2 is not updating when new instances are launched. The inventory source is set to update on launch. What is the most likely cause?

A.The inventory source cache timeout is set too high.
B.The AWS credential associated with the inventory source is invalid or expired.
C.The 'update on launch' option is disabled.
D.The inventory source is configured as a custom script.
AnswerB

Invalid credentials prevent successful inventory sync.

Why this answer

Option B is correct because the most likely cause of a dynamic inventory source not updating is that the associated AWS credential is invalid or expired. When the 'update on launch' option is enabled, Ansible Tower attempts to refresh the inventory from the source before each job run. If the credential (e.g., AWS access key ID and secret access key) is no longer valid, the inventory update will fail silently or with an error, and the job will use stale cached data.

Exam trap

The trap here is that candidates often assume the 'update on launch' option is misconfigured or that cache settings are the problem, when in reality the credential validity is the root cause that prevents any update from succeeding.

How to eliminate wrong answers

Option A is wrong because a high cache timeout would cause the inventory to be updated less frequently, but the 'update on launch' option forces a fresh update regardless of the cache timeout setting. Option C is wrong because the question explicitly states that the inventory source is set to update on launch, so this option is factually incorrect. Option D is wrong because a custom script inventory source would not use the AWS EC2 dynamic inventory plugin; the question specifies a dynamic inventory source from AWS EC2, which uses the built-in ec2.py or ec2 plugin, not a custom script.

Practice this question →
30
MCQmedium

An administrator needs to store a secret API token in Ansible Automation Controller so that it can be used in job templates without exposing the token in plain text. Which type of credential should be used?

A.Vault credential
B.Machine credential
C.Network credential
D.Cloud credential
AnswerB

Machine credentials can store SSH keys or passwords, but not API tokens directly; however, the token can be stored as a custom credential type or secret. This is the closest built-in type.

Why this answer

Option B is correct because a Machine credential in Ansible Automation Controller is designed to store SSH keys, passwords, and other authentication secrets for remote hosts. It can securely store an API token as a password field, which can then be referenced in job templates without exposing the token in plain text. This aligns with the requirement to store a secret API token for use in automation jobs.

Exam trap

The trap here is that candidates may confuse a Vault credential (which handles encrypted files) with a generic secret storage mechanism, but Vault credentials only provide the decryption password, not a secure field for arbitrary secrets like API tokens.

How to eliminate wrong answers

Option A is wrong because a Vault credential is used to decrypt Ansible Vault-encrypted files, not to store arbitrary API tokens for use in job templates; it provides a vault password to unlock encrypted data. Option C is wrong because a Network credential is specifically for network device authentication (e.g., SSH keys for routers/switches) and is not intended for storing API tokens. Option D is wrong because a Cloud credential is designed to store cloud provider authentication (e.g., AWS access keys, Azure service principals) and is not a generic secret store for arbitrary API tokens.

Practice this question →
31
MCQeasy

An administrator wants to use a custom inventory script to dynamically generate hosts in Ansible Tower. Which of the following is a valid approach to manage credentials for accessing the script's API?

A.Define environment variables in the job template that references the inventory script, and use a credential type that injects those variables.
B.Attach the credential directly to the inventory script in the Ansible Tower UI.
C.Store the API token in a file within the project repository and source it in the script.
D.Embed the API token within the inventory script's JSON output.
AnswerA

This is the correct approach: use custom credential types to inject environment variables into job templates.

Why this answer

Option A is correct because Ansible Tower (now Red Hat Ansible Automation Platform) allows custom credential types to inject environment variables into job runs. When a custom inventory script requires API authentication, you can define a credential type with injector configuration that sets environment variables (e.g., API_TOKEN, API_USER), then attach that credential to the job template. This keeps secrets out of scripts and repositories, following security best practices.

Exam trap

The trap here is that candidates may think credentials can be directly attached to inventory scripts (Option B) or that storing tokens in project files is acceptable, when in fact Tower's credential system is designed to inject secrets via environment variables or extra vars, not via direct script attachment or file storage.

How to eliminate wrong answers

Option B is wrong because Ansible Tower does not allow attaching credentials directly to an inventory script; credentials are attached to job templates, projects, or inventories, not to individual script files. Option C is wrong because storing API tokens in a file within the project repository violates security best practices and exposes secrets to version control, making them accessible to anyone with repository access. Option D is wrong because embedding the API token directly in the inventory script's JSON output would expose the token in plaintext in job logs and outputs, compromising security and violating the principle of least privilege.

Practice this question →
32
MCQeasy

Refer to the exhibit. A playbook includes this vars file and runs `systemctl restart httpd`. The playbook fails because it cannot decrypt the vault. Which of the following is the most likely cause?

A.The vault ID is missing.
B.The variable db_password is not used in the playbook.
C.The vault password is not provided.
D.The vault file is corrupted.
AnswerC

Without a vault password, decryption fails.

Why this answer

The error 'cannot decrypt the vault' indicates that Ansible is unable to decrypt the vault-encrypted variable file. This occurs when the vault password is not provided via `--ask-vault-pass`, `--vault-password-file`, or the `ANSIBLE_VAULT_PASSWORD_FILE` environment variable. Without the correct password, Ansible cannot decrypt the vault, causing the playbook to fail.

Exam trap

Red Hat often tests the distinction between vault ID (which is optional) and vault password (which is mandatory), leading candidates to incorrectly select 'vault ID is missing' when the actual issue is the missing password.

How to eliminate wrong answers

Option A is wrong because a vault ID is optional; Ansible can decrypt vaults without an ID if the password matches, and the error message does not indicate a missing ID. Option B is wrong because whether `db_password` is used in the playbook is irrelevant to the decryption failure; the vault file is loaded regardless of variable usage. Option D is wrong because a corrupted vault file would typically produce a different error (e.g., 'Vault format error' or 'HMAC mismatch'), not a generic 'cannot decrypt' message.

Practice this question →
33
MCQmedium

A sysadmin receives an error when running a job template: 'ERROR! the role 'common' was not found in the specified roles path'. The role exists in a source control repository referenced in the project. What is the most likely cause?

A.The inventory does not include the target hosts
B.The project's source control sync failed, so the roles directory is empty
C.The job template is configured with an incorrect schedule
D.The credential used does not have access to the source control repository
AnswerB

A failed sync means the roles were not downloaded, causing the 'not found' error.

Why this answer

Option A is correct because the project sync may have failed, causing the roles directory to be missing. Option B is wrong because the credential type does not affect role availability. Option C is wrong because the inventory host list does not contain role definitions.

Option D is wrong because the job template schedule does not impact role discovery.

Practice this question →
34
MCQhard

An organization uses multiple Ansible Automation Platform clusters in different geographies. Each cluster has its own set of credentials for different environments. An administrator needs to ensure that job templates launched in the EMEA cluster can only use EMEA-specific credentials, while the APAC cluster uses APAC-specific credentials, without duplicating job template definitions. What is the best approach?

A.Configure separate organizations for each cluster and assign credentials to each organization, then use the same job template within each organization
B.Create separate job templates for each cluster and assign the appropriate credentials
C.Use the same job template and rely on host tags in the inventory to filter which credentials are used
D.Use an external secrets management system and call it via lookup plugin in the playbook
AnswerA

Organizations provide credential isolation; templates can be duplicated per organization with same playbook but different credentials.

Why this answer

Option A is correct because Ansible Automation Platform organizations provide a logical boundary for credentials, projects, and job templates. By creating separate organizations for the EMEA and APAC clusters, the administrator can assign EMEA-specific credentials to the EMEA organization and APAC-specific credentials to the APAC organization. The same job template can then be created within each organization, inheriting only the credentials assigned to that organization, thus avoiding duplication of the job template definition while enforcing credential isolation.

Exam trap

The trap here is that candidates may think host tags or inventory variables can control credential usage, but Ansible Automation Platform does not support credential filtering based on inventory metadata; credentials are strictly bound to organizations or job templates.

How to eliminate wrong answers

Option B is wrong because it requires creating separate job templates for each cluster, which duplicates job template definitions and contradicts the requirement to avoid duplication. Option C is wrong because host tags in inventory are used for targeting specific hosts or groups, not for filtering credentials; credentials are assigned at the job template or organization level, and tags cannot restrict which credentials a job template can use. Option D is wrong because using an external secrets management system with a lookup plugin retrieves secrets at runtime but does not enforce which credentials a job template can use; it bypasses the credential assignment mechanism and does not provide the required isolation between clusters.

Practice this question →
35
MCQhard

An Ansible playbook uses a vault-encrypted variable `db_password` from a vars file. The playbook fails with 'Decryption failed' error. Which of the following could be the cause?

A.The vault password is correct but the file is corrupted.
B.The vault password file path is incorrect in ansible.cfg.
C.The vault ID in the encrypted file does not match the provided vault ID.
D.The variable is not encrypted but marked as `!vault`.
AnswerC

A vault ID mismatch causes decryption failure.

Why this answer

Option C is correct because Ansible Vault supports multiple vault IDs, and the vault ID used to encrypt the variable must match the vault ID provided at runtime (via `--vault-id` or `ansible.cfg`). If the encrypted file was created with vault ID 'prod' but the playbook is run with vault ID 'dev', Ansible will fail with 'Decryption failed' because it cannot find a matching password for that ID.

Exam trap

The trap here is that candidates often assume 'Decryption failed' always means a wrong password, but Ansible's vault ID mismatch is a distinct and common cause that is explicitly tested in the exam.

How to eliminate wrong answers

Option A is wrong because a corrupted file would typically produce a different error (e.g., 'Vault format error' or 'unexpected EOF'), not a generic 'Decryption failed' message. Option B is wrong because an incorrect vault password file path in ansible.cfg would cause Ansible to fail earlier with a file-not-found error, not a decryption failure. Option D is wrong because if a variable is not encrypted but marked as `!vault`, Ansible would treat it as an invalid vault string and raise a parsing error, not a decryption failure.

Practice this question →
36
MCQmedium

An inventory is sourced from an external dynamic inventory plugin. The plugin returns hosts with groups including 'webservers' and 'dbservers'. An administrator wants to add a custom variable to all hosts in the 'webservers' group without modifying the plugin script. How can this be achieved?

A.Modify the dynamic inventory plugin script to add the variable
B.Add the variable to the host_vars file for each host
C.Create a group_vars file named 'webservers' in the project directory and define the variable
D.Use the 'add_host' module in a playbook to set the variable
AnswerC

Group_vars files automatically apply to hosts in the matching group from any inventory source.

Why this answer

Option C is correct because Ansible's group_vars mechanism allows you to define variables for all hosts in a group by creating a YAML file named after the group (e.g., 'webservers') in the group_vars directory. This approach does not require modifying the dynamic inventory plugin script, which is external and should remain untouched. The variable will be automatically applied to all hosts in the 'webservers' group during playbook execution.

Exam trap

The trap here is that candidates may think modifying the plugin script (Option A) is acceptable, but the EX294 exam emphasizes immutability of external sources and using Ansible's built-in variable precedence and group_vars instead.

How to eliminate wrong answers

Option A is wrong because modifying the dynamic inventory plugin script violates the requirement to not modify the plugin, and it is not a best practice—external plugins should be treated as immutable. Option B is wrong because adding the variable to host_vars files for each host would be repetitive and inefficient, and it does not leverage group-level inheritance; it also requires knowing all hostnames in advance. Option D is wrong because the 'add_host' module is used to dynamically add hosts to the in-memory inventory during playbook runtime, not to set persistent variables for existing group members; it would not apply the variable to all hosts in the 'webservers' group automatically.

Practice this question →
37
MCQeasy

You are an Ansible Tower administrator for a company that uses a dynamic inventory script to pull hosts from AWS. The script has been working for months, but after a recent security update, the job template that uses this inventory fails with the error: 'ERROR! Unable to parse /path/to/inventory/script.py as an inventory source'. The script is executable and the path is correct. What is the most likely cause?

A.The required Python modules (e.g., boto3) are missing in the Tower virtual environment.
B.The inventory source type has been changed to 'Manual' instead of 'Scraped from project'.
C.The script has been deleted from the project directory.
D.The script lacks execute permissions for the Tower service user.
AnswerA

Security update may have changed the environment.

Why this answer

The error 'Unable to parse /path/to/inventory/script.py as an inventory source' typically occurs when the dynamic inventory script fails to execute properly. Since the script is executable and the path is correct, the most likely cause is that the required Python modules (e.g., boto3 for AWS) are missing in the Ansible Tower virtual environment. Tower runs inventory scripts in its own Python virtual environment, and if boto3 is not installed there, the script cannot import it and fails, leading to the parse error.

Exam trap

The trap here is that candidates assume the error is due to file permissions or path issues, but the real cause is a missing Python dependency in the Tower virtual environment, which is a common post-update problem.

How to eliminate wrong answers

Option B is wrong because the inventory source type is not changed to 'Manual' or 'Scraped from project' in this context; the error is about parsing the script, not about the source type setting. Option C is wrong because the script has not been deleted; the error message explicitly states the path to the script, and the path is correct, so the file exists. Option D is wrong because the script already has execute permissions (stated in the question), so lacking permissions for the Tower service user is not the issue.

Practice this question →
38
MCQhard

As an Ansible Tower administrator, you are tasked with setting up a job template that interacts with multiple cloud providers. The job template uses a custom credential type that includes two fields: 'api_token' (type password) and 'region' (type text). During a test run, the job fails with an error that the 'region' variable is not defined in the playbook. The playbook references {{ region }} and {{ api_token }}. You verified that the credential is assigned to the job template and the values are populated. What is the most likely issue?

A.The playbook uses the variable names without the credential-specific prefix.
B.The credential is assigned to the project instead of the job template.
C.The 'api_token' field is encrypted but the 'region' field is not, causing a parsing error.
D.The 'region' field is defined as 'password' type, so it is hidden.
AnswerA

Custom credential variables are namespaced with the credential name.

Why this answer

Option A is correct because in Ansible Tower/AWX, when a custom credential type is used, the variables defined in the credential's injector configuration are automatically prefixed with the credential name (or a custom namespace) when injected into the job environment. If the injector does not explicitly map the fields to the exact variable names used in the playbook (e.g., `region` and `api_token`), the playbook will fail with an undefined variable error. The most likely issue is that the credential's injector configuration does not set the variables as `{{ region }}` and `{{ api_token }}` without a prefix, or the playbook is expecting the variables without the credential-specific namespace that Tower injects by default.

Exam trap

The trap here is that candidates assume that defining fields in a custom credential type automatically makes them available as playbook variables with the same names, overlooking the critical step of configuring the injector mapping in the credential type definition.

How to eliminate wrong answers

Option B is wrong because credentials are assigned to job templates, not to projects; projects store source code, not runtime credentials. Option C is wrong because the 'password' type only masks input in the UI and does not encrypt the value in a way that would cause a parsing error; both fields are injected as plain text variables. Option D is wrong because the 'region' field is defined as 'text' type in the question, not 'password', and even if it were 'password', the type does not affect variable availability in the playbook.

Practice this question →
39
Multi-Selecteasy

An Ansible playbook uses the `fetch` module to retrieve files from managed hosts. Which TWO inventory variables are commonly used to construct unique destination paths for each host?

Select 2 answers
A.dest
B.inventory_hostname
C.hostvars
D.ansible_host
E.group_names
AnswersB, D

The hostname as defined in the inventory file.

Why this answer

The `fetch` module retrieves files from managed hosts and stores them locally. To avoid overwriting files from different hosts, you must use unique destination paths. `inventory_hostname` provides the hostname as defined in the inventory, and `ansible_host` provides the actual IP or FQDN used to connect, both of which are commonly used to create distinct per-host directories or filenames.

Exam trap

The trap here is that candidates confuse `dest` (a module parameter) with an inventory variable, or think `hostvars` can be used directly as a unique identifier without additional filtering.

Practice this question →
40
MCQeasy

An administrator is managing an Ansible Automation Platform deployment that runs job templates against a dynamic inventory sourced from VMware vCenter. The administrator updated the vCenter credentials in Tower after a password rotation. However, subsequent inventory syncs continue to fail with authentication errors. The administrator has confirmed that the new credentials work when tested directly on the controller node using the 'govc' CLI tool. The inventory source is configured to use the updated credential and the update_on_launch flag is set to true. Which action should the administrator take to resolve the issue?

A.Recreate the credential and assign it to the inventory source again.
B.Restart the ansible-tower service.
C.Run the inventory sync with the 'Clear Cache' option enabled.
D.Change the inventory source to use a new name and reconfigure it.
AnswerC

Clearing the cache ensures that stale credential data is removed, allowing the sync to authenticate with the updated credentials.

Why this answer

Option A is correct because clearing the cache forces a fresh inventory sync that discards any cached credentials or data, ensuring the new credentials are used. Option B is incorrect because restarting services is a brute-force approach that may clear cache but is not the targeted solution. Option C is incorrect because recreating the credential is unnecessary; the existing credential is valid.

Option D is incorrect because changing the inventory source name and reconfiguring it is overkill and does not directly address the caching issue.

Practice this question →
41
MCQhard

A system administrator is managing Ansible Tower and wants to use an Azure Resource Manager credential to provision virtual machines. However, the credential fails authentication with the error '401 Unauthorized'. Which action should the administrator take to resolve the issue?

A.Regenerate the SSH key pair and update the credential.
B.Verify the client secret in the credential matches the one configured in Azure Active Directory.
C.Add the credential as a playbook-level variable instead of a Tower credential.
D.Generate a new API token from Azure and paste it into the credential.
AnswerB

A mismatch in client secret causes 401 errors.

Why this answer

The 401 Unauthorized error when using an Azure Resource Manager credential in Ansible Tower indicates that the authentication token or secret used to authenticate with Azure Active Directory is invalid or mismatched. Option B is correct because verifying that the client secret stored in the Tower credential exactly matches the one configured in Azure Active Directory resolves the authentication failure, as Azure AD uses OAuth 2.0 client credentials flow where the client secret is required for token acquisition.

Exam trap

The trap here is that candidates confuse SSH key authentication (used for Linux hosts) with Azure AD OAuth authentication, leading them to select option A, or they mistakenly think generating a new API token (option D) is the correct fix for Azure credentials.

How to eliminate wrong answers

Option A is wrong because SSH key pairs are used for authentication to Linux hosts via SSH, not for Azure Resource Manager API authentication, which uses OAuth 2.0 tokens and client secrets. Option C is wrong because adding the credential as a playbook-level variable bypasses Tower's credential management and encryption, but the underlying authentication issue (invalid client secret) would persist and still cause a 401 error. Option D is wrong because Azure Resource Manager credentials in Tower require a client ID and client secret, not an API token; generating a new API token is not the correct mechanism for Azure AD service principal authentication.

Practice this question →
42
Drag & Dropmedium

Drag and drop the steps to configure a systemd service to start automatically at boot 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

Systemd service: create unit file, reload, enable, start, verify status.

Practice this question →
43
MCQmedium

An administrator wants to create a custom credential type to store a third-party API key. The API key must be passed to the playbook as an environment variable `MY_API_KEY`. What is the correct Injector configuration in the custom credential type definition?

A.file: {MY_API_KEY: "{{ api_key }}"}
B.env: {"MY_API_KEY": api_key}
C.extra_vars: {MY_API_KEY: "{{ api_key }}"}
D.env: {MY_API_KEY: "{{ api_key }}"}
AnswerD

The env dictionary maps credential inputs to environment variables.

Why this answer

Option D is correct because the Injector configuration for a custom credential type in Ansible Automation Platform uses the `env` key to map credential inputs to environment variables. The syntax `env: {"MY_API_KEY": "{{ api_key }}"}` correctly references the input field `api_key` using Jinja2 templating and assigns it to the environment variable `MY_API_KEY`, which the playbook can then access via `ansible_env.MY_API_KEY`.

Exam trap

The trap here is that candidates often confuse `env` with `extra_vars` or forget the Jinja2 templating syntax, leading them to pick Option B (missing braces) or Option C (incorrect injector type).

How to eliminate wrong answers

Option A is wrong because `file` is not a valid Injector key; it is used for file-based credential types (e.g., SSH keys) but not for environment variables. Option B is wrong because it omits the required Jinja2 braces around the variable reference (`api_key` instead of `{{ api_key }}`), which would cause the literal string 'api_key' to be passed rather than the credential input value. Option C is wrong because `extra_vars` is used to inject variables into the playbook's variable space, not as environment variables; it would set `MY_API_KEY` as an Ansible variable, not an environment variable.

Practice this question →
44
MCQeasy

An Ansible Tower administrator needs to add a single host to an existing inventory. The host has a static IP address and requires SSH access with a specific username and private key. Which of the following is the correct approach?

A.Add the host to an inventory group using the 'Add Group' option and specify the host details there.
B.Use the 'Add Host' form and in the 'Credentials' field, select the appropriate SSH credential from the drop-down.
C.Create a new credential first, then add the host directly within the credential definition.
D.Navigate to the inventory, click 'Add Host', enter the hostname and IP, and optionally define variables. Then create a credential for SSH and associate it with the host through a job template.
AnswerD

This is the standard method to add a host in Tower.

Why this answer

Option D is correct because in Ansible Tower, a host is added to an inventory via the 'Add Host' form, where you enter the hostname and IP address and optionally define variables. SSH credentials are not directly associated with a host; instead, they are created separately and then linked to the host through a job template, which uses the credential to authenticate when running playbooks against that host.

Exam trap

The trap here is that candidates mistakenly think SSH credentials can be directly assigned to a host in the inventory UI, when in reality credentials are associated at the job template level to maintain separation of concerns and reusability.

How to eliminate wrong answers

Option A is wrong because the 'Add Group' option is for creating or modifying groups within an inventory, not for adding a host; host details are not specified within a group definition. Option B is wrong because the 'Add Host' form does not have a 'Credentials' field; credentials are managed separately and associated at the job template level, not directly on the host. Option C is wrong because a credential definition does not include host details; credentials are reusable objects that contain authentication information (username, private key) and are not tied to a specific host during creation.

Practice this question →
45
MCQeasy

A junior admin is troubleshooting why a job template fails with 'Permission denied' when connecting to a target host. The job template uses a machine credential that appears correct. What is the first thing to check?

A.Verify the inventory contains the correct host IP
B.Check the credential's username and private key / password
C.Check the vault credential used in the job template
D.Check the project sync status
AnswerB

The error suggests the credentials are not accepted by the target host.

Why this answer

The error 'Permission denied' during SSH connection to a target host indicates an authentication failure. Since the machine credential appears correct, the most immediate cause is that the username or private key/password stored in the credential is incorrect or mismatched. This is the first thing to check because the credential directly controls authentication to the target host.

Exam trap

The trap here is that candidates often confuse 'Permission denied' with a network or inventory issue, leading them to check the inventory or project sync instead of the credential's authentication details.

How to eliminate wrong answers

Option A is wrong because verifying the inventory host IP addresses connectivity issues (e.g., wrong host or unreachable), not authentication failures; 'Permission denied' is an SSH-level error, not a network reachability error. Option C is wrong because vault credentials are used to decrypt sensitive data within Ansible, not for SSH authentication to target hosts; they do not affect the 'Permission denied' error. Option D is wrong because project sync status relates to retrieving playbook content from a source control repository, not to SSH authentication; a failed sync would cause a different error (e.g., 'project not found'), not 'Permission denied'.

Practice this question →
46
Multi-Selecteasy

Which TWO methods can be used to limit the hosts that a job template runs against when launching a job? (Choose exactly two.)

Select 2 answers
A.Assigning a specific credential to the job template.
B.Using the 'Tags' field to include only certain tasks.
C.Using the 'LIMIT' field in the job template or at launch time.
D.Selecting a specific group in the 'Jobs' section during launch.
E.Setting the 'Source Control Branch' in the project.
AnswersC, D

This is the primary method to restrict hosts.

Why this answer

Option C is correct because the 'LIMIT' field in Ansible Tower/AWX allows you to restrict the execution of a job template to a specific subset of hosts in the inventory, either by host name, group name, or pattern. This can be set in the job template definition or overridden at launch time, providing flexible targeting without modifying the inventory structure.

Exam trap

The trap here is that candidates confuse the 'Tags' field (which filters tasks within a playbook) with host limiting, or mistakenly think credentials or source control branches affect which hosts are targeted, when in fact only inventory patterns and the 'LIMIT' field control host selection.

Practice this question →
47
MCQmedium

An administrator needs to restrict access to an inventory so that only members of the 'WebTeam' can update its host variables and group memberships. Other users should be able to view the inventory but not modify it. Which role-based access control (RBAC) configuration should be applied?

A.Create a job template and assign 'WebTeam' the 'execute' role
B.Make the 'WebTeam' organization administrators and assign others the 'read' role on the organization
C.Assign the 'WebTeam' the 'admin' role on the inventory and others the 'read' role
D.Assign the 'WebTeam' the 'use' role on the inventory and others the 'read' role
AnswerC

Admin role on inventory allows full management; read role allows viewing.

Why this answer

Option C is correct because in Ansible Tower/AWX, the 'admin' role on an inventory grants full update permissions (including host variables and group memberships), while the 'read' role provides view-only access. This directly satisfies the requirement that only WebTeam members can modify the inventory, and others can only view it.

Exam trap

The trap here is confusing the 'use' role with 'write' or 'admin' roles, as candidates often assume 'use' allows modifications, but 'use' only permits associating the inventory with a job template, not editing its contents.

How to eliminate wrong answers

Option A is wrong because a job template with an 'execute' role controls who can run a job, not who can update inventory host variables or group memberships; it does not provide inventory modification permissions. Option B is wrong because making WebTeam organization administrators grants them broad administrative rights across the entire organization, not just the inventory, which violates the principle of least privilege and could allow unintended modifications to other resources. Option D is wrong because the 'use' role on an inventory allows a user to use the inventory in a job template (i.e., associate it with a job), but it does not grant permission to update host variables or group memberships; only 'admin' or 'write' roles provide those modification capabilities.

Practice this question →
48
MCQhard

A team uses Ansible Automation Controller with multiple organizations. Each organization has its own set of machines that require different SSH keys. The administrator wants to ensure that users from one organization cannot use credentials from another organization. What is the best way to achieve this isolation?

A.Create credentials within each organization and assign organization-level access
B.Store credentials in separate projects and restrict project access
C.Set 'Use' permission on credentials only for specific users
D.Place users in different teams and restrict credential access by team
AnswerA

Credentials belong to an organization, and users from other organizations cannot see them.

Why this answer

In Ansible Automation Controller, credentials are scoped to organizations. By creating credentials within each organization and assigning organization-level access, the administrator ensures that credentials are only visible and usable by members of that organization. This leverages the built-in role-based access control (RBAC) that isolates resources by organization, preventing cross-organization credential access.

Exam trap

The trap here is that candidates often confuse team-based access control with organization-level isolation, assuming that restricting credentials to a team within an organization provides cross-organization security, but teams do not span organizations and cannot prevent access from users in other organizations.

How to eliminate wrong answers

Option B is wrong because projects in Ansible Automation Controller are used to store playbooks and source code, not credentials; credentials are stored separately in the Credentials resource and are not scoped by project. Option C is wrong because setting 'Use' permission on credentials for specific users does not prevent users from other organizations from accessing those credentials if they are not properly scoped to an organization; organization-level isolation is required. Option D is wrong because teams are subgroups within an organization and do not provide cross-organization isolation; users from different organizations could still be placed in the same team, and team-based restrictions do not enforce organizational boundaries.

Practice this question →
49
Matchingmedium

Match each storage concept to its description.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts
Matches

Logical Volume Manager for flexible storage

Redundant array of independent disks

Default Linux filesystem (journaling)

High-performance 64-bit filesystem

Virtual memory on disk

Why these pairings

Common storage technologies in RHEL.

Practice this question →
50
MCQmedium

A team is using Ansible Tower with multiple credentials per job template. The playbook uses the 'become' method to escalate privileges on remote hosts. The become password is different from the SSH password. Which configuration ensures the become password is used?

A.Provide both the SSH password and become password in the machine credential.
B.Use a vault credential to store the become password.
C.Use two separate credentials (one for SSH, one for become) and assign both to the job template.
D.Store the become password in inventory variables.
AnswerA

Machine credentials support both SSH and become authentication fields.

Why this answer

In Ansible Tower, when a job template uses multiple credentials, the machine credential is the primary credential for SSH authentication. To use a different become password, you must provide both the SSH password and the become password within the same machine credential. This is because the machine credential has dedicated fields for 'Password' (SSH) and 'Become Password' (privilege escalation), and Tower automatically uses the become password from that credential when the playbook invokes 'become: yes'.

Exam trap

The trap here is that candidates assume you can use separate credentials for SSH and become passwords, but Tower requires both passwords to be bundled in the same machine credential because the become password is a field within that credential type, not a separate credential object.

How to eliminate wrong answers

Option B is wrong because a vault credential is used to store encrypted secrets (like passwords) that are decrypted at runtime, but it does not directly supply the become password to the 'become' mechanism; the become password must be explicitly provided in the machine credential or via a separate credential type. Option C is wrong because Tower does not support assigning two separate machine credentials to a single job template; you can assign multiple credentials of different types, but for SSH and become passwords, both must reside in the same machine credential. Option D is wrong because storing the become password in inventory variables is insecure and not the intended method; Tower expects the become password to be defined in the credential, not in inventory, and using variables would bypass credential management and auditing.

Practice this question →
51
MCQeasy

An administrator needs to provide a set of credentials to a job template that requires a machine credential for SSH and a source control credential for the project. What is the correct way to associate these credentials?

A.Define the source control token in the playbook using the 'set_fact' module
B.Create a single credential that includes both SSH key and source control token
C.Store the source control token as an extra variable in the job template
D.Assign both a machine credential and a source control credential to the job template
AnswerD

Job templates can have multiple credentials of different types.

Why this answer

Option D is correct because Ansible Tower/AWX allows multiple credentials of different types to be assigned to a single job template. A machine credential handles SSH authentication for target hosts, while a source control credential manages authentication for the project repository (e.g., Git). This separation follows Ansible's modular credential design, where each credential type serves a distinct purpose and can be independently managed.

Exam trap

The trap here is that candidates think a single credential must contain all authentication data, but Ansible Tower explicitly separates credential types by function, and a job template can accept multiple credentials of different types simultaneously.

How to eliminate wrong answers

Option A is wrong because the 'set_fact' module sets variables at runtime within a playbook, not credentials; source control tokens must be stored securely in a credential type, not hardcoded in playbooks. Option B is wrong because Ansible Tower does not support a single credential that combines SSH and source control tokens; credentials are typed (machine, source control, vault, etc.) and cannot be merged. Option C is wrong because extra variables are not designed for sensitive credentials; they are visible in job runs and logs, whereas source control tokens should be stored in a dedicated credential type with encryption.

Practice this question →
52
MCQhard

An organization has multiple Ansible Tower projects that use different cloud providers. The security team mandates that cloud API credentials stored in Tower must have restricted access and be reusable across job templates without exposing the secret key. Which credential type and organization strategy best meets these requirements?

A.Use a network credential to store the API token and assign it to the project.
B.Create separate custom credential types for each cloud provider, marking the secret key fields as 'password' type, and add them to each job template as needed.
C.Create a single custom credential type that includes both cloud provider API keys and reuse it across all projects.
D.Use a machine credential for each cloud provider and set the SSH key as the API secret.
AnswerB

Custom credential types with password fields provide secure, reusable credentials.

Why this answer

Option B is correct because Ansible Tower's custom credential types allow you to define fields with the 'password' type, which encrypts the secret key and hides it from view after entry. By creating separate custom credential types for each cloud provider, you can assign them to specific job templates, ensuring restricted access and reusability without exposing the secret key. This approach meets the security mandate by isolating credentials per provider and leveraging Tower's built-in encryption for sensitive fields.

Exam trap

The trap here is that candidates may confuse credential types (e.g., network, machine) with their intended use cases, or assume a single shared credential is more efficient, overlooking the security requirement for restricted access and separation of concerns per cloud provider.

How to eliminate wrong answers

Option A is wrong because network credentials are designed for network device authentication (e.g., SNMP, SSH), not for storing cloud API tokens, and they do not support custom fields for API secrets. Option C is wrong because a single custom credential type for all cloud providers would violate the principle of least privilege, as it would expose all API keys to any job template using that credential, increasing the risk of unauthorized access. Option D is wrong because machine credentials are intended for SSH key-based authentication to managed hosts, not for cloud API secrets, and using an SSH key field for an API secret would be a misuse of the credential type, potentially causing authentication failures.

Practice this question →
53
Multi-Selectmedium

Which TWO statements about machine credentials in Ansible Tower are correct? (Choose two.)

Select 2 answers
A.Machine credentials can specify a 'become_method' for privilege escalation.
B.Machine credentials can use an SSH private key for authentication.
C.The SSH private key file automatically includes privilege escalation settings.
D.The username field is optional when using an SSH key.
E.SSH key credentials require a password field to be filled in.
AnswersA, B

Become method (e.g., sudo) is configurable.

Why this answer

Option A is correct because Ansible Tower machine credentials include a 'Become Method' field that allows you to specify privilege escalation methods such as 'sudo', 'su', 'pbrun', or 'pfexec'. This setting is used by Ansible to escalate privileges on the target machine after the initial SSH connection is established, enabling tasks that require higher-level permissions.

Exam trap

The trap here is that candidates often assume the SSH private key file inherently includes privilege escalation settings, or that the username is optional when using SSH keys, but Ansible Tower strictly requires a username and treats privilege escalation as a separate configuration field.

Practice this question →
54
Multi-Selectmedium

Which THREE are valid credential types in Ansible Tower?

Select 3 answers
A.Network credential
B.Machine credential
C.Source control credential
D.Cloud credential
E.Vault credential
AnswersA, B, E

Network credentials are used for network devices.

Why this answer

Network credentials are valid in Ansible Tower for authenticating to network devices (e.g., routers, switches) via protocols like SSH, Telnet, or API. They store the username, password, and optional SSH key or become method, enabling Tower to execute playbooks against network targets.

Exam trap

The trap here is that candidates confuse 'Source control credential' (which is not a standalone type) with the ability to authenticate to Git repos, which is actually handled by Machine or Cloud credentials, or by storing SSH keys in the project's settings.

Practice this question →
55
MCQmedium

An Ansible inventory file uses the `gce.py` dynamic inventory script for Google Cloud. After running the script, the inventory contains hosts but no variables. What is the most likely cause?

A.The script is not executable.
B.The GCE service account lacks permissions to read instance metadata.
C.The script's JSON output lacks the 'vars' section for the group.
D.The inventory file uses `hosts: all`.
AnswerC

Variables are only populated if the script includes a 'vars' key in each group.

Why this answer

Option C is correct because dynamic inventory scripts like `gce.py` output JSON that must include a `_meta` section with `hostvars` for host-specific variables, and a `vars` subsection within each group to define group-level variables. If the script's JSON output lacks the `vars` section for a group, Ansible will still see the hosts but will not populate any variables for that group, resulting in hosts with no associated variables.

Exam trap

The trap here is that candidates often assume missing variables are due to permission or execution issues, but the question specifically states the script runs and produces hosts, narrowing the cause to a structural problem in the script's JSON output.

How to eliminate wrong answers

Option A is wrong because if the script were not executable, Ansible would fail to run it entirely and would not produce any inventory hosts, not hosts without variables. Option B is wrong because insufficient GCE service account permissions would typically cause the script to fail to retrieve instance data, resulting in an empty inventory or an error, not hosts with missing variables. Option D is wrong because `hosts: all` is a playbook-level directive that targets all inventory hosts, not a cause for missing variables; it does not affect how the dynamic inventory script populates variables.

Practice this question →
56
MCQeasy

An Ansible Tower administrator needs to allow a team of developers to run playbooks against specific inventory groups without allowing them to modify the inventory or credentials. Which approach best satisfies the requirement?

A.Assign the developers the 'Execute' role on the inventory and 'Use' role on the credential.
B.Assign the developers the 'Update' role on the inventory and 'Admin' role on the credential.
C.Assign the developers the 'Admin' role on the inventory and 'Read' role on the credential.
D.Assign the developers the 'Read' role on both inventory and credential.
AnswerA

Execute allows running jobs; Use allows credential usage without management.

Why this answer

The 'Execute' role on an inventory allows a user to run playbooks against that inventory without granting permission to modify its contents. The 'Use' role on a credential permits the credential to be used in job templates but not viewed or edited. This combination precisely meets the requirement of allowing playbook execution while preventing inventory or credential modification.

Exam trap

The trap here is confusing 'Execute' with 'Read' or 'Update' roles — candidates often assume 'Read' is sufficient for running playbooks, but Tower requires the explicit 'Execute' permission to launch jobs against an inventory.

How to eliminate wrong answers

Option B is wrong because the 'Update' role on inventory allows modifying inventory contents (e.g., adding/removing hosts), and the 'Admin' role on credential grants full control including editing and deletion, both exceeding the requirement. Option C is wrong because the 'Admin' role on inventory provides full administrative rights including modification, and the 'Read' role on credential only allows viewing, not usage in job templates. Option D is wrong because the 'Read' role on both inventory and credential only permits viewing, not executing playbooks against the inventory or using the credential in a job template.

Practice this question →
57
MCQeasy

An Ansible administrator wants to use an encrypted vault file to store sensitive variables. Which command creates a new vault file and prompts for a password?

A.ansible-vault edit secrets.yml
B.ansible-vault create secrets.yml
C.ansible-vault view secrets.yml
D.ansible-vault encrypt secrets.yml
AnswerB

Creates a new vault file and prompts for password.

Why this answer

Option B is correct because `ansible-vault create secrets.yml` creates a new encrypted vault file and immediately prompts the user to set a password, which is then used to encrypt the file. This command is specifically designed for initial creation of vault files, unlike `edit` which requires an existing file, `view` which only displays content, or `encrypt` which encrypts an existing plaintext file.

Exam trap

The trap here is that candidates confuse `ansible-vault create` with `ansible-vault encrypt`, mistakenly thinking both create new files, but `encrypt` requires an existing plaintext file while `create` generates a new encrypted file from scratch.

How to eliminate wrong answers

Option A is wrong because `ansible-vault edit` opens an existing vault file for editing, not creating a new one; it requires the file to already exist and be encrypted. Option C is wrong because `ansible-vault view` displays the decrypted content of an existing vault file without prompting for a new password or creating a file. Option D is wrong because `ansible-vault encrypt` encrypts an existing plaintext file into a vault file, but does not create a new file from scratch; it expects the file to already exist in plaintext.

Practice this question →
58
MCQhard

You manage an Ansible Tower instance that has multiple inventories synced from different sources (static, dynamic cloud, and satellite). Recently, a job template that uses an inventory synced from Red Hat Satellite fails with 'No hosts matched' even though hosts exist in Satellite. The inventory sync job runs successfully and shows hosts populated in Tower. The job template uses a limit field set to '*' and there are no tags or other filters. The playbook is simple: 'hosts: all'. What is the most likely cause?

A.The inventory sync job is not scheduled to run before the job template.
B.The groups imported from Satellite are nested and the job template's limit does not include the parent group.
C.The inventory source is configured to use 'scraped from project' instead of 'satellite'.
D.The credential used for Satellite sync is expired.
AnswerB

Hosts may be in subgroups; the limit must account for hierarchy.

Why this answer

Option B is correct because when Satellite imports hosts into Tower, it often creates nested groups (e.g., a parent group containing child groups). If the job template's limit field is set to '*' (which expands to all hosts in the inventory), but the playbook's 'hosts: all' directive only matches hosts directly in the top-level group—not those in nested subgroups—the job will report 'No hosts matched'. This occurs because Ansible's inventory resolution for 'all' does not automatically recurse into child groups unless the inventory source properly flattens the group hierarchy or the limit explicitly includes the parent group.

Exam trap

The trap here is that candidates assume '*' in the limit field or 'hosts: all' in the playbook will match every host in the inventory, overlooking how nested group structures from dynamic sources like Satellite can cause hosts to be invisible to the 'all' group unless the inventory is properly flattened.

How to eliminate wrong answers

Option A is wrong because the inventory sync job runs successfully and shows hosts populated in Tower, so scheduling is not the issue; the problem is that the job template cannot match those hosts. Option C is wrong because the inventory source is explicitly stated as synced from Satellite, and 'scraped from project' is a different source type that would not import Satellite groups; the question confirms the sync runs successfully, so the source type is correct. Option D is wrong because if the credential were expired, the inventory sync job would fail, not succeed and show hosts populated.

Practice this question →
59
Multi-Selectmedium

Which TWO statements about inventory groups in Ansible Automation Platform are correct? (Choose exactly two.)

Select 2 answers
A.A host can belong to multiple groups
B.Inventory groups can be used in smart inventories as filter criteria
C.Host variables are the only way to define variables for a host
D.Groups cannot be members of other groups
E.Dynamic inventory sources cannot produce groups
AnswersA, B

A host can be a member of multiple groups, e.g., 'webservers' and 'production'.

Why this answer

Options B and D are correct. A is wrong because groups can contain other groups (nested groups). C is wrong because host variables can be defined at the group level.

E is wrong because smart inventories are a separate type, not a dynamic source.

Practice this question →
60
Multi-Selectmedium

A team is configuring an inventory to manage Windows hosts via Ansible. Which TWO inventory variables must be defined for each host?

Select 2 answers
A.ansible_host
B.ansible_shell_type
C.ansible_user
D.ansible_winrm_server_cert_validation
E.ansible_connection
AnswersA, E

Required to specify the host address.

Why this answer

Option A is correct because `ansible_host` defines the IP address or FQDN that Ansible uses to connect to the managed host. For Windows hosts, this is essential because Ansible cannot rely on the inventory hostname alone (which may be a short name or not resolvable). Option E is correct because `ansible_connection` must be set to `winrm` for Windows hosts; without it, Ansible defaults to SSH, which will fail against Windows targets.

Exam trap

The trap here is that candidates often assume `ansible_user` is mandatory for all connections, but Ansible can derive the user from the current session or other credential sources, whereas `ansible_host` and `ansible_connection` are strictly required to reach and identify the Windows host correctly.

Practice this question →
61
Drag & Dropmedium

Drag and drop the steps to create and apply a simple Ansible playbook that installs httpd into 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

A playbook defines hosts and tasks; tasks use modules; after execution, verification confirms success.

Practice this question →
62
MCQhard

An organization uses an external secrets management system (e.g., HashiCorp Vault) to store sensitive credentials. They want to integrate it with Ansible Automation Platform so that job templates automatically retrieve credentials from Vault without storing them in the AAP database. Which approach is supported?

A.Use the built-in 'Machine' credential type and store the Vault token in the credential
B.Store the secret in an extra variable and reference it in the playbook
C.Use the 'Ansible Vault' credential type to decrypt vault-encrypted variables in the project
D.Create a custom credential type with an injector that uses a lookup plugin to fetch the secret from Vault
AnswerD

Custom credential types can use runtime lookups to retrieve secrets externally.

Why this answer

Option D is correct because Ansible Automation Platform supports custom credential types that can use lookup plugins (such as `hashi_vault`) to retrieve secrets from external systems like HashiCorp Vault at runtime. The injector template can define environment variables or extra variables that are populated by the lookup plugin, ensuring credentials are never stored in the AAP database.

Exam trap

The trap here is confusing 'Ansible Vault' (a file encryption tool) with 'HashiCorp Vault' (an external secrets manager), leading candidates to incorrectly select Option C, which only handles decrypting Ansible Vault-encrypted files, not integrating with external secret stores.

How to eliminate wrong answers

Option A is wrong because the built-in 'Machine' credential type is designed for SSH authentication, not for storing Vault tokens; it would still store the token in the AAP database, defeating the purpose of external secret retrieval. Option B is wrong because storing the secret in an extra variable means the secret is passed as plain text in the job template or inventory, which persists in the AAP database and logs, violating the requirement to avoid storing credentials. Option C is wrong because the 'Ansible Vault' credential type is used to decrypt Ansible Vault-encrypted files (using a password), not to integrate with external secrets management systems like HashiCorp Vault.

Practice this question →
63
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.

Practice this question →
64
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.

Practice this question →
65
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.

Practice this question →
66
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.

Practice this question →
67
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.

Practice this question →
68
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.

Practice this question →
69
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.

Practice this question →
70
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.

Practice this question →
71
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.

Practice this question →
72
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.

Practice this question →
73
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.

Practice this question →
74
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.

Practice this question →
75
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.

Practice this question →

Ready to test yourself?

Try a timed practice session using only Inventories Credentials questions.

Start 20-question session