CCNA Manage inventories and credentials Questions

The `:&` syntax in a host pattern performs set intersection, so the play runs only against hosts that are members of both the `web` and `db` groups. The `:` alone would create a union, and a leading `!` would exclude. Because the play uses `web:&db`, the correct target set is the overlap of the two groups.

Both accepted approaches produce artifacts encrypted with the same vault password that the required --vault-password-file supplies. Inline encryption with encrypt_string hides a single value inside an otherwise readable vars file, while encrypting an entire vars file protects a group of secrets referenced through vars_files. Each keeps clear-text secrets out of the repository while remaining fully usable at run time.

Ansible merges group membership across all loaded inventory sources. When the same group name appears in an INI file and a YAML file, the group ends up containing the union of hosts from both definitions. There is no duplicate error and no format-based precedence for group membership.

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.

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.

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.

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.

In Red Hat Enterprise Linux, standard directories follow the Filesystem Hierarchy Standard (FHS). /etc holds configuration files, /home stores user home directories, and /boot contains boot loader files and kernel images. Common confusions include mixing /var (variable data like logs) with /tmp (temporary files) and associating log files incorrectly with /tmp.

The ansible-inventory --list command is designed to parse an inventory source and emit the resulting groups, hosts, and variables as JSON. It is the definitive tool for confirming how Ansible interprets an inventory file, including group membership and host listing.

Setting ansible_user in [group:vars] sections of the inventory file assigns the correct SSH user to all hosts in each group. This is a standard inventory feature that automatically applies group-specific connection variables. It requires no playbook modifications and ensures the right user is used for web and db hosts without manual per-host configuration.

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.

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.

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.

Ansible uses connection variables prefixed with ansible_ to override SSH behavior. ansible_ssh_private_key_file specifies the key, and ansible_user sets the remote user. Placing them in a group vars section applies them to all hosts in that group, satisfying the scenario without modifying the playbook.

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.

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.

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

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.

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.

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.

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.

The ansible-vault encrypt command is the correct tool to encrypt an existing plaintext file. Using --vault-password-file provides the password non-interactively, enabling automation. The resulting file remains encrypted at rest and is decrypted automatically during playbook runs when the same vault password is supplied.

The error indicates that Ansible cannot find the 'common' role in the specified roles path. Since the role exists in the source control repository referenced by the project, the most likely cause is that the project's source control sync failed, leaving the roles directory empty or incomplete. Without a successful sync, the role files are not present on the Ansible control node, causing the job template execution to fail.

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.

Because manual SSH succeeds but Ansible cannot connect, the difference lies in the identity Ansible uses. Ansible defaults to the local account name for remote logins, so when that name differs from the account holding the authorized key, the connection is refused and hosts are marked UNREACHABLE. Defining the correct remote user in inventory or on the command line restores key-based access without altering the transport.

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.

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

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.

Ansible INI inventory files use square-bracketed group names followed by one host per line. The correct content defines the `app` group with app1 and app2 on separate lines, and the `db` group with db1. The other options use invalid syntax such as key-value pairs, non-standard keywords, or comma-separated hosts, which Ansible would not parse as intended.

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.

The correct matches are: LVM for flexible disk management with VGs and LVs, RAID for combining disks for redundancy/performance, Stratis for pool-based snapshots and thin provisioning, and VDO for block-level deduplication/compression. Common confusions include swapping LVM with VDO and RAID with Stratis.

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.

The ansible_user inventory variable sets the remote username for all connection types, including WinRM. For Windows hosts, ansible_user and ansible_password are used with the winrm connection plugin. Defining these in group_vars ensures credentials are applied consistently without modifying playbooks.

A vault password file is a plaintext file that contains the vault password on its first line. It is created using standard file redirection or an editor, not with ansible-vault commands. This file is then referenced with --vault-password-file during playbook runs to decrypt vault-encrypted content non-interactively.

For Windows targets, authentication over WinRM is governed by `ansible_winrm_transport`. With a username and password and no Kerberos infrastructure, setting it to `ntlm` forces NTLM authentication and resolves the connection failure. Connection type, SSH password, and become settings do not select the WinRM authentication protocol.

Variable precedence in Ansible is hierarchical rather than source-based: host variables outrank group variables, and more specific group levels outrank broader ones. Because the dynamic plugin attaches http_port to the individual host, that value sits above the group-level definition in group_vars. The managed host therefore receives 8080 even though the static group file specifies 80.

Ansible supports multiple inventory sources by repeating the -i option. Each source is parsed separately and merged, preserving distinct group names so that group_vars directories are applied based on group membership. Using a single -i with a comma-separated list or additional positional arguments does not achieve the same result and will cause errors.

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

Ansible group patterns use colon-prefixed operators: a leading ampersand means intersection, a leading exclamation mark means exclusion, and a bare colon means union. Placing an ampersand before the second group limits the selection to hosts that are members of both groups, which matches the requirement that only hosts in webservers and production be targeted by the play.

Ansible's inventory system allows a host to belong to multiple groups simultaneously. This is a fundamental feature of Ansible's inventory model, enabling flexible host organization and variable inheritance from all parent groups.

Providing the vault password interactively with --ask-vault-pass or via a vault password file with --vault-password-file are both valid methods to decrypt vault-encrypted files. The password file can be a script that outputs the password, which is useful for automation. Vault-encrypted files can be used for any variables, including inventory variables, and do not require an unencrypted reference file.

Placing the same hostname under two separate group headers is the correct way to give a host membership in multiple groups in an INI inventory. Ansible then treats the host as a single managed node that inherits variables from both groups, with group variable precedence rules resolving conflicts.

Merging multiple inventories unifies hosts and groups rather than rejecting duplicates. For a host present in several sources, variables from the source processed later override those from earlier sources. Since the dynamic plugin is processed after the static file, its ansible_host value is the one that survives, so the host resolves to the plugin-provided address.

The network_cli connection plugin relies on ansible_user and ansible_password for authentication. These variables are set in the inventory or group_vars and are used by the plugin to establish connections to network devices, ensuring proper credential management.