EX294 Manage inventories and credentials — Timed 20 Questions

Question 1

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?

Accepted Answer

Smart inventories. Smart inventories allow you to define a set of hosts based on a search query (e.g., using hostname patterns or Ansible facts) that can span multiple inventories. This enables reuse of host definitions across different environments without duplicating them, as the smart inventory dynamically resolves the host list at runtime from the underlying inventory sources.

Answer

Inventory sources

Answer

Shared inventories

Answer

Inventory groups

Question 2

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?

Accepted Answer

Vault credential. A Vault credential in Ansible Automation Controller stores an encrypted password that can be used to decrypt Ansible Vault files. While originally designed for vault files, it can also be used to securely store any secret, such as an API token, by referencing it via the {{ vault_password }} variable in job templates. This ensures the token is never exposed in plain text. Machine credentials are for SSH authentication, Network credentials for network devices, and Cloud credentials for cloud provider APIs—none are suitable for storing arbitrary API tokens.

Answer

Machine credential

Answer

Network credential

Answer

Cloud credential

Question 3

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?

Accepted Answer

Create credentials within each organization and assign organization-level access. 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.

Answer

Store credentials in separate projects and restrict project access

Answer

Set 'Use' permission on credentials only for specific users

Answer

Place users in different teams and restrict credential access by team

Question 4

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?

Accepted Answer

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

Answer

Cloud credential

Answer

Machine credential

Answer

Network credential

Question 5

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?

Accepted Answer

env: {MY_API_KEY: "{{ api_key }}"}. 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`.

Answer

file: {MY_API_KEY: "{{ api_key }}"}

Answer

env: {"MY_API_KEY": api_key}

Answer

extra_vars: {MY_API_KEY: "{{ api_key }}"}

Question 6

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?

Accepted Answer

Check the credential's username and private key / password. 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.

Answer

Verify the inventory contains the correct host IP

Answer

Check the vault credential used in the job template

Answer

Check the project sync status

Question 7

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

Accepted Answer

Prompt on launch (ask for credential on job run). 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.

Answer

Set the password via an environment variable in the job template

Answer

Include the password in a file in the project repository

Answer

Store the password in plain text in the credential definition

Question 8

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

Accepted Answer

Restrict credential 'Use' permissions to specific users or teams. 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.

Answer

Avoid using external secret management systems; keep all secrets in Automation Controller

Answer

Share the same credential across multiple organizations for simplicity

Question 9

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?

Accepted Answer

admin (from inventory host variable). 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.

Answer

The username set in the job template's 'extra variables'

Answer

The first defined username in the credential chain

Answer

root (from credential)

Question 10

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?

Accepted Answer

The SSH public key corresponding to the private key is not installed on the target host. 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.

Answer

The vault password is incorrect

Answer

The SSH port is blocked by a firewall

Answer

The host's SSH host key has changed and the known_hosts file is outdated

Question 11

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?

Accepted Answer

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

Answer

Use a Vault credential to store the new secrets and reference them in the job template

Answer

Store the new passwords directly in a playbook and run it manually on each server, then update the credential in the UI

Answer

Create a single machine credential with the same SSH key for all Linux servers and a single credential for all Windows servers

Question 12

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?

Accepted Answer

Verify the client secret in the credential matches the one configured in Azure Active Directory.. 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.

Answer

Regenerate the SSH key pair and update the credential.

Answer

Add the credential as a playbook-level variable instead of a Tower credential.

Answer

Generate a new API token from Azure and paste it into the credential.

Question 13

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?

Accepted Answer

Assign the developers the 'Execute' role on the inventory and 'Use' role on the credential.. 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.

Answer

Assign the developers the 'Update' role on the inventory and 'Admin' role on the credential.

Answer

Assign the developers the 'Admin' role on the inventory and 'Read' role on the credential.

Answer

Assign the developers the 'Read' role on both inventory and credential.

Question 14

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

Accepted Answer

Machine credentials can specify a 'become_method' for privilege escalation.. 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.

Answer

The SSH private key file automatically includes privilege escalation settings.

Answer

The username field is optional when using an SSH key.

Answer

SSH key credentials require a password field to be filled in.

Question 15

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?

Accepted Answer

The constructed inventory runs before add_host tasks, so the hosts are not yet created.. 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.

Answer

The constructed plugin cannot be used with the add_host module.

Answer

The 'strict: false' setting ignores missing variables, causing the group to be empty.

Answer

The variable ansible_distribution is not defined because gather_facts is set to no.

Question 16

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?

Accepted Answer

Grant Team Beta the 'Use' role on the credential 'shared_ssh_key'.. 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.

Answer

Create a new credential with the same SSH key and assign it to Team Beta.

Answer

Assign the credential to the dbservers group in the inventory.

Answer

Move the credential from the organization to the project level.

Question 17

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?

Accepted Answer

Define environment variables in the job template that references the inventory script, and use a credential type that injects those variables.. 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.

Answer

Attach the credential directly to the inventory script in the Ansible Tower UI.

Answer

Store the API token in a file within the project repository and source it in the script.

Answer

Embed the API token within the inventory script's JSON output.

Question 18

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

Accepted Answer

Integrate with an external secrets management system using a credential lookup plugin.. 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.

Answer

Export credentials from the Ansible Tower API in plain-text.

Answer

Use machine credentials with an SSH key that has a passphrase.

Answer

Store credentials in plain-text in the Ansible Tower database.

Question 19

Drag and drop the steps to create and apply a simple Ansible playbook that installs httpd into the correct order.

Accepted Answer

Create the playbook file, then define hosts and tasks, then execute the playbook, then verify the httpd service.. A playbook defines hosts and tasks; tasks use modules; after execution, verification confirms success.

Answer

Define hosts and tasks, then create the playbook file, then execute the playbook, then verify the httpd service.

Answer

Create the playbook file, then execute the playbook, then verify the httpd service, then define hosts and tasks.

Answer

Execute the playbook, then create the playbook file, then define hosts and tasks, then verify the httpd service.

Question 20

Drag and drop the steps to configure a systemd service to start automatically at boot in the correct order.

Accepted Answer

Create unit file, Reload systemd, Enable service, Start service, Verify status. The correct sequence for configuring a systemd service to start at boot is: first create the unit file, then reload systemd to load the new unit, next enable the service to create the necessary symlinks for automatic start, then start the service immediately, and finally verify its status. Common mistakes include omitting the reload step, enabling after starting, or performing the reload too late.

Answer

Create unit file, Enable service, Start service, Verify status

Answer

Create unit file, Reload systemd, Start service, Enable service, Verify status

Answer

Create unit file, Start service, Enable service, Reload systemd, Verify status