Ansible Automation Ansible Tower and AWX 2 — Questions and Answers
Question 1: What is Role-Based Access Control (RBAC) in Ansible Tower/AWX?
- A permission system that grants users and teams specific access levels (admin, use, execute, read) to Tower resources like Job Templates and Inventories (Correct answer)
- A way to assign Ansible roles to managed hosts through the Tower interface
- A feature that automatically assigns permissions based on Active Directory groups
- An auditing system that records all role usage in playbooks
Correct answer: A permission system that grants users and teams specific access levels (admin, use, execute, read) to Tower resources like Job Templates and Inventories
Tower RBAC controls which users and teams can access, modify, or execute specific Tower resources, enabling least-privilege automation governance.
Tower/AWX RBAC provides granular access control: - Resource types: Organizations, Teams, Users, Projects, Inventories, Job Templates, Credentials, Workflows - Permission levels: Admin (full control), Use (reference in other resources), Execute (run jobs), Read (view only) - Team-based: Assign permissions to teams, add users to teams - Org-level separation: Multiple organizations with separate admins Example: Developers get 'execute' on dev Job Templates but 'read' only on credentials. Operators get 'execute' on production templates. Only the automation team has 'admin' on production credentials. This enables self-service automation while maintaining security.
Question 2: What is a 'Project' in Ansible Tower/AWX?
- A logical collection of Ansible playbooks linked to a source control repository (Git/SVN) that Tower manages and syncs (Correct answer)
- A group of related Job Templates and workflows
- A Tower term for an Ansible role collection
- A project plan for automation initiatives tracked in Tower
Correct answer: A logical collection of Ansible playbooks linked to a source control repository (Git/SVN) that Tower manages and syncs
Projects connect Tower to source control repositories, enabling Tower to pull the latest playbooks and roles automatically.
A Tower/AWX Project represents a source of Ansible playbook content: - Connects to a Git, SVN, or Mercurial repository - Configured with the repo URL, branch, and source control credential - Tower syncs (git pull) the project before job runs or on a schedule - Supports specific Git branches, tags, or commit hashes for pinned deployments - Also supports manual projects (files placed directly on Tower's filesystem) When a Job Template runs, Tower first syncs the project, then executes the specified playbook from the synced content. Project updates can be made automatic (before each job run) or scheduled.
Question 3: What are 'Surveys' in Ansible Tower/AWX Job Templates?
- Web forms presented to users before launching a job that collect input variables, replacing the need for --extra-vars at the command line (Correct answer)
- Post-job questionnaires for operators to rate automation effectiveness
- Scheduled audits of managed host configurations
- Forms for requesting new Job Template creation
Correct answer: Web forms presented to users before launching a job that collect input variables, replacing the need for --extra-vars at the command line
Surveys enable self-service automation by providing non-technical users with a UI form to specify job parameters without needing Ansible knowledge.
Tower Surveys create input forms for Job Templates: - Question types: text, textarea, password, integer, float, single-select, multi-select - Each question maps to an extra variable passed to the playbook - Required/optional questions with default values - Validation (min/max for numbers, regex for text) - Password fields are masked in the UI and logs Example survey for a 'Deploy Application' job template: - 'Target Environment' (single-select: dev/staging/prod) - 'Application Version' (text, required) - 'Rollback on Failure' (single-select: yes/no) This enables operators to run deployments through a simple web form without CLI access.
Question 4: How does Ansible Tower/AWX handle execution environments?
- Execution Environments are container images that bundle Ansible, collections, and Python dependencies, ensuring consistent and isolated job execution (Correct answer)
- Tower executes all jobs in a shared Python virtualenv on the Tower server
- Execution environments are VMs that Tower provisions for each job run
- Tower uses Docker Compose to manage execution environments per organization
Correct answer: Execution Environments are container images that bundle Ansible, collections, and Python dependencies, ensuring consistent and isolated job execution
Execution Environments (EEs) solve the dependency management problem by containerizing all automation requirements, replacing the old virtualenv approach.
Execution Environments (introduced in AAP 2.0) are OCI-compatible container images containing: - Ansible Core - Ansible collections (specified in requirements.yml) - Python packages and system dependencies - Custom code and certificates Built using 'ansible-builder' tool, EEs ensure: 1. Consistent behavior across dev/staging/production 2. No dependency conflicts between different automation projects 3. Easy distribution via container registries 4. Isolated execution (each job runs in its own container) Default EEs are provided by Red Hat; custom EEs can be built for specific use cases.
Question 5: What is 'Instance Groups' in Ansible Tower/AWX?
- Groups of Tower execution nodes that can be targeted for specific job execution, enabling geographic distribution and workload isolation (Correct answer)
- Groups of managed hosts organized by Tower for parallel execution
- Clusters of Tower servers for high availability
- Groups of AWS EC2 instances managed by Tower
Correct answer: Groups of Tower execution nodes that can be targeted for specific job execution, enabling geographic distribution and workload isolation
Instance Groups allow routing specific jobs to specific Tower execution nodes, enabling workload isolation, geographic routing, and capacity management.
Instance Groups in Tower/AWX are collections of execution nodes: - Assign Job Templates, Inventories, or Organizations to specific instance groups - Jobs run only on nodes within the assigned instance group - Use cases: 1. Geographic routing: East/West datacenter execution nodes 2. Network isolation: Air-gapped production network with dedicated nodes 3. Capacity management: High-memory nodes for large inventories 4. Multi-tenancy: Separate execution capacity per business unit 'controlplane' is the default instance group for the Tower control nodes. Execution nodes (separate from control) were introduced in AAP 2.x for horizontal scaling.
Question 6: What notification types does Ansible Tower/AWX support for alerting on job completion?
- Email, Slack, PagerDuty, webhook (generic), HipChat, Mattermost, Rocket.Chat, Grafana, IRC, and Twilio (Correct answer)
- Only email and webhook notifications
- Slack and PagerDuty only
- Tower relies on external monitoring tools for all notifications
Correct answer: Email, Slack, PagerDuty, webhook (generic), HipChat, Mattermost, Rocket.Chat, Grafana, IRC, and Twilio
Tower has extensive built-in notification integrations covering chat platforms, alerting systems, messaging services, and generic webhooks for custom integrations.
Ansible Tower/AWX Notification Templates support multiple channels: - Chat: Slack, Mattermost, Rocket.Chat, HipChat (deprecated) - Alerting: PagerDuty, Grafana - Communication: Email (SMTP), IRC, Twilio (SMS) - Generic: Webhook (HTTP POST to any endpoint) Notifications can be attached to: Job Templates, Workflow Templates, or at the Organization level. Trigger conditions: on start, on success, on failure, or on any status change. Custom messages with template variables (job name, status, URL, launched by) enable rich notification payloads for incident management workflows.
Ansible Automation Ansible Tower and AWX 2
What is Role-Based Access Control (RBAC) in Ansible Tower/AWX?