CCNA Deploy Ansible Automation Platform Questions

The containerized installer uses an INI-style inventory file in the setup directory to define the target hosts and platform variables such as admin password, registry credentials, and the path to the Red Hat subscription manifest. Editing this file supplies the parameters the setup playbook consumes during installation.

The automation controller persists its configuration, jobs and credentials in PostgreSQL, so a highly available deployment requires that database to be replicated across nodes; without database replication, a controller node failure would lose or block access to this shared state.

In a redundant AAP cluster, controller nodes are placed behind a load balancer that distributes traffic and monitors node health. If one node fails, the load balancer routes traffic to the remaining healthy node, maintaining availability. This is the standard high-availability configuration for the automation controller component.

The AAP installer requires the database user to have the `CREATEDB` privilege to create the necessary databases and schemas during installation. Without it, the installer cannot proceed. Granting this privilege to the specified user resolves the error and allows the installation to complete successfully. This is a documented requirement for external database configurations.

The AAP installer requires the system to be registered with RHSM and the correct AAP repository enabled so that required RPMs (e.g., ansible-core, receptor) can be installed. Without this repository, the setup script cannot resolve dependencies. Enabling the version-specific repository for RHEL 9 is the documented prerequisite before running the installer.

The bundled installer uses an INI-style inventory file where variables such as admin_password, pg_password, and receptor parameters are defined under the [automationcontroller] and [all:vars] sections. Editing this file is the documented step before running setup.sh, making it the correct place to set these deployment-wide credentials and connection details.

Differing become methods across hosts break privilege escalation: sudo, su and doas require distinct configuration and password handling, so a task succeeding where sudo is configured fails elsewhere with 'Permission denied' despite valid credentials. Aligning the become method with each host's available escalation tooling resolves the inconsistency.

Running multiple automation controllers behind a load balancer removes the single point of failure, distributing API and job traffic across nodes so one controller outage does not halt automation. This directly satisfies the high-availability design constraint.

RBAC on job templates grants or denies execute permission to named users or teams, directly satisfying the requirement to restrict who can launch specific templates. Unlike organisation-wide roles, template-level role assignments scope access per template, so only explicitly authorised principals can run it.

The 403 Forbidden comes from the registry rejecting an unauthenticated pull, not from network reachability. Automation controller needs a container registry credential holding the private automation hub pull token, associated with the execution environment, so it can authenticate.

Ansible rejects unknown task keywords, so 'now' cannot be parsed as a valid task attribute. It is not a real module or directive; the playbook likely intended 'notify' or the line should be deleted entirely.

The controller resolves collections from the Galaxy servers configured for an organization. Assigning the hub credential to the organization and enabling the private hub as a Galaxy server ensures project syncs pull collections from the private hub using the stored token, completing the authenticated connection the administrator requires.

In a containerized AAP deployment, the controller connects to the database using environment variables such as `CONTROLLER_PG_HOST`, `CONTROLLER_PG_PORT`, `CONTROLLER_PG_USER`, and `CONTROLLER_PG_PASSWORD`. If these do not match the actual database container's configuration, the controller will fail to connect and restart. Verifying and correcting these variables resolves the issue.

Containerized AAP uses Podman to run its services, and the installer expects the Podman API socket to be available. Enabling and starting `podman.socket` provides that API endpoint. Rerunning the installer after the socket is active allows the container services to start, resolving the reported failure.

The `setup.sh` script is the documented entry point for installing Ansible Automation Platform. It reads the `inventory` file in the same directory and executes the installer playbooks with the appropriate environment. Running this script performs the standard installation using the default inventory file, which the administrator can edit beforehand.

Automation controller supports external logging, which forwards activity stream records and job events to an external aggregator such as Splunk, Elastic, or a syslog server. Enabling this with the appropriate host, port, and protocol settings centralizes logs so the security team can search and correlate them without querying the controller database directly.

PostgreSQL uses `pg_hba.conf` to control which users may connect from which client addresses and with which authentication method. Even with a valid user and open port, a missing or restrictive host-based rule for the controller's address causes authentication or permission failures during migration. This is the classic cause when connectivity tests succeed but the installer's database operations fail.

For an external database, PostgreSQL must have the necessary extensions (such as hstore and pg_trgm) and pg_hba.conf must permit the controller's IP with the correct authentication method. A reachable port alone does not guarantee authentication or extension availability, so these are the likely missing pieces.

Execution nodes in an automation mesh can span distinct geographic regions, since the mesh replaces the single-hop SSH model with peer-to-peer overlay routing between nodes. This satisfies the stem's requirement for distributed, resilient deployment, allowing execution capacity to sit close to managed hosts across regions without a central hop.

The installer's pre-flight check validates database connectivity using the credentials and hostname in the inventory. If the database is running but not accepting remote connections, it is typically due to `pg_hba.conf` restrictions or the service binding only to localhost. Ensuring the database allows connections from the controller node and listens on the correct interface resolves the failure.

SSH key authentication requires the machine credential to hold the private key matching the public key on the managed host. Without that private key stored in the credential, Ansible cannot authenticate, producing the 'Authentication failed' error.

The AAP installer uses an inventory file, typically named `inventory`, located in the installer directory. This file defines the groups such as `[automationcontroller]`, `[automationhub]`, and `[database]`, and includes variables like `ansible_user`, `ansible_password`, and `ansible_become_password` for authentication. Editing this file is a required step before running `setup.sh`.

A Machine credential stores the SSH private key encrypted within Automation Platform and enforces role-based access controls, so only authorised users and job templates can retrieve it. This satisfies the requirement that keys never sit in plain text on disk.

The AAP installer relies on the target host being able to resolve its own hostname, often via `/etc/hosts`. Even if the control node can resolve the target's DNS name, the target itself may fail to resolve its own hostname during service configuration. This causes the installer to report a DNS resolution error. Adding the hostname to `/etc/hosts` on the target resolves the issue.

Organization auditor is a built-in Automation Controller role granting read-only visibility across all objects within a single organization, including inventories, credentials, job templates and projects. It satisfies the stem's requirement for a valid organization-scoped user role, distinct from system auditor, which spans the entire controller instance rather than one organization.

Selecting SCM as the source control type lets Automation Platform authenticate to the Git repository and retrieve playbooks directly, satisfying the requirement to pull playbooks from Git. Other source control types, such as manual or archive-based imports, do not establish the live repository connection the scenario demands.

Introducing an intermediate hop node in the branch office lets execution nodes connect over the low-latency LAN rather than the high-latency VPN, satisfying the requirement to minimise latency and prevent timeouts. Direct children of the controller force every job hop across the constrained VPN link.

Mesh nodes extend execution capacity by running jobs alongside control-plane hybrid nodes, distributing playbook workloads across additional compute. This directly satisfies the stem's scaling requirement: adding mesh nodes increases parallel job execution without altering the control plane, unlike hop nodes, which only relay traffic between isolated network segments.

Ansible-builder produces the EE image locally, but the controller resolves EEs from a configured container registry. Unless the image is pushed there, the controller cannot pull it, producing the 'not found' error despite a successful build.

Automation controller nodes form an active-active cluster behind a load balancer, so any node can accept and execute jobs; if one fails, the remaining nodes continue running playbooks without manual intervention. This satisfies the stem's controller failover requirement, since the control plane itself must be redundant rather than relying on a single instance.