Ansible Automation Ansible Tower and AWX 1 — Questions and Answers
Question 1: What is the relationship between Ansible Tower and AWX?
- AWX is the open-source upstream project that Ansible Tower (now Red Hat Ansible Automation Platform) is based on (Correct answer)
- AWX is the enterprise version of Ansible Tower with additional features
- Tower and AWX are completely separate projects with no shared code
- AWX is Tower's API layer while Tower provides the web UI
Correct answer: AWX is the open-source upstream project that Ansible Tower (now Red Hat Ansible Automation Platform) is based on
AWX is the community-supported open-source project; Red Hat Ansible Tower (now Ansible Automation Platform) is the enterprise product built from AWX's codebase.
AWX (Ansible Web eXperience) is the open-source, community-driven project that serves as the upstream for Ansible Tower. Red Hat takes the AWX codebase, adds testing, enterprise support, and long-term stability guarantees, and releases it as Ansible Tower (now part of Red Hat Ansible Automation Platform). AWX releases frequently with cutting-edge features but no enterprise support; Tower releases less frequently with stability guarantees and Red Hat SLA. AWX can be deployed on Kubernetes using the AWX Operator.
Question 2: In Ansible Tower/AWX, what is a 'Job Template'?
- A reusable definition that combines a playbook, inventory, credentials, and settings to create runnable automation jobs (Correct answer)
- A predefined playbook included with Tower for common tasks
- A template file that generates playbooks dynamically
- A scheduled task that runs playbooks automatically
Correct answer: A reusable definition that combines a playbook, inventory, credentials, and settings to create runnable automation jobs
Job Templates are the primary unit of automation in Tower—they bundle everything needed to run a playbook: the playbook source, target inventory, credentials, and execution parameters.
A Job Template in Ansible Tower/AWX defines all parameters for a playbook run: - Source control project (Git repo) - Playbook file path within the project - Inventory (which hosts to target) - Credentials (SSH keys, vault passwords, cloud credentials) - Extra variables - Tags and limits - Notification settings Once defined, a Job Template can be launched manually, via schedule, webhooks (GitHub/GitLab push events), or the Tower API. Job Templates enable self-service automation by allowing non-Ansible users to trigger complex automation safely.
Question 3: What is the purpose of 'Credentials' in Ansible Tower/AWX?
- They securely store secrets (SSH keys, passwords, API tokens) that are injected into jobs at runtime without exposing them to users (Correct answer)
- They define which users are authorized to run specific Job Templates
- They store database connection information for Tower's backend
- They manage SSL certificates for the Tower web interface
Correct answer: They securely store secrets (SSH keys, passwords, API tokens) that are injected into jobs at runtime without exposing them to users
Tower Credentials provide a secure credential store where secrets are write-only—users can use credentials without ever seeing the actual values.
Tower/AWX Credentials securely store and inject secrets into jobs without exposing them: - Machine credentials: SSH private keys or passwords for managed hosts - Source control credentials: Git repository access tokens/keys - Vault credentials: Ansible Vault decryption passwords - Cloud credentials: AWS IAM keys, Azure service principals, GCP service accounts - Custom credential types: User-defined credential schemas Credentials are encrypted at rest in Tower's database. Team members can be granted 'use' permission without 'read' permission, meaning they can run jobs with a credential without ever seeing the actual key or password. This is a key security benefit over flat-file Ansible.
Question 4: What is a 'Workflow Job Template' in Ansible Tower/AWX?
- A visual workflow that chains multiple Job Templates together, with branching based on success or failure of each step (Correct answer)
- A Job Template with multiple playbooks defined in sequence
- A template that generates Job Templates automatically from a workflow definition
- A batch job runner that executes Job Templates in parallel only
Correct answer: A visual workflow that chains multiple Job Templates together, with branching based on success or failure of each step
Workflow Job Templates enable multi-step automation pipelines with conditional branching—on-success and on-failure paths between Job Templates.
Workflow Job Templates orchestrate multiple Job Templates into pipelines with conditional logic: - Visual workflow editor with drag-and-drop nodes - Each node is a Job Template, inventory sync, or project update - On-success, on-failure, and always branches between nodes - Cross-inventory workflows (patch webservers, then test, then patch databases) - Approval nodes for human-in-the-loop gates - Can pass artifacts between jobs using 'set_stats' and workflow artifacts Example pipeline: Deploy App → (success) → Run Integration Tests → (failure) → Rollback → Notify Slack
Question 5: In Ansible Tower/AWX, what is the 'Inventory' object and what types does Tower support?
- Inventories define the hosts Tower manages; types include static (manually entered), dynamic (cloud provider sync), and smart (filter-based) (Correct answer)
- Inventories are only CSV files uploaded to Tower
- Tower only supports static inventories for security reasons
- Inventories in Tower are automatically generated from network scans
Correct answer: Inventories define the hosts Tower manages; types include static (manually entered), dynamic (cloud provider sync), and smart (filter-based)
Tower supports static inventories, dynamic inventories that sync from cloud providers or other sources, and smart inventories that filter hosts from existing inventories.
Tower/AWX inventory types: 1. Static: Hosts manually defined in Tower's UI or imported from INI/YAML files 2. Dynamic/Synced: Pull hosts from cloud sources (AWS EC2, Azure, GCP, VMware vCenter, OpenStack), CMDB systems (ServiceNow), or custom scripts. Tower keeps these in sync automatically. 3. Smart Inventories: Define a filter expression to create a virtual inventory from hosts across other inventories (e.g., all hosts with 'env=production' tag) 4. Constructed Inventories: Build inventory based on complex Jinja2 expressions (Tower 2.3+) Inventory syncing can be scheduled or triggered before job runs.
Question 6: What REST API method would you use to launch a Job Template in Ansible Tower/AWX programmatically?
- POST to /api/v2/job_templates/{id}/launch/ (Correct answer)
- GET to /api/v2/job_templates/{id}/run/
- PUT to /api/v2/jobs/{id}/start/
- PATCH to /api/v2/job_templates/{id}/execute/
Correct answer: POST to /api/v2/job_templates/{id}/launch/
Tower/AWX uses a RESTful API where launching a Job Template requires a POST request to the template's launch endpoint.
The Tower/AWX REST API is fully documented at /api/v2/. To launch a Job Template: POST https://tower.example.com/api/v2/job_templates/42/launch/ Authorization: Bearer <token> Content-Type: application/json { "extra_vars": {"env": "production"}, "limit": "webservers" } The response includes a job ID for tracking status. Poll /api/v2/jobs/{id}/ to check status. Tower also supports OAuth2 tokens and basic auth. The AWX CLI tool ('awx') wraps this API for command-line automation.
Ansible Automation Ansible Tower and AWX 1
What is the relationship between Ansible Tower and AWX?