<aside> 🧭
Module 12 · AWX / Ansible Automation Platform
Running Ansible as a service rather than from laptops and CI jobs — with RBAC, credential management, scheduling, an audit trail, and self-service for people who should never touch YAML.
🧠 concept → 🧪 exercise → ✅ expected result (hidden) → 🎯 interview questions (answers hidden)
Prerequisite: Modules 01–11.
</aside>
<aside> 🏨
The analogy. Think of a hotel reception desk. The keys live in a cabinet behind the desk, not in the guests' pockets. You are handed a card that opens your room and nothing else, and it stops working the morning you check out. The desk keeps a record of who was given which card and when. And housekeeping can get into your room every day without ever being handed a master key.
AWX is that reception desk. Your playbooks are completely unchanged — what it adds is the key cabinet (credential storage), the room-specific cards (RBAC), the expiry (revocation), and the register (the audit trail). Every feature in this module is one of those four things.
</aside>
<aside> 📖
Official docs: AWX documentation · Red Hat Ansible Automation Platform · AWX on GitHub
</aside>
| Problem with laptops + CI | What AWX provides |
|---|---|
| Anyone with the repo and SSH keys can run anything | RBAC — who may run which template against which inventory |
| "Who ran that, and when?" | Audit trail — every job, its output, its inputs, its operator |
| Vault passwords and SSH keys on individual machines | Credential store — encrypted, injected at run time, never displayed |
| Two people run the same playbook simultaneously | Job queueing and concurrency control |
| Cron on someone's laptop | Scheduling with visibility and history |
| Support staff cannot run automation without YAML | Surveys — a web form that becomes extra vars |
| "It works on my machine" | Execution Environments — one pinned container runtime |
<aside> 🎯
The honest framing for an interview: "AWX is not faster or more capable than ansible-playbook — it runs exactly the same engine. What it adds is everything around the run: access control, credentials, scheduling, queueing, an audit trail, and a UI and API for people who should not be handed SSH keys. You adopt it when the constraint stops being 'can we automate this' and becomes 'who is allowed to, and can we prove what happened'."
</aside>
<aside> 🚨
Read this section carefully if you have heard of "Ansible Tower" but not "AWX". That is the normal situation, and the naming is genuinely confusing because the product has been renamed twice. They are not three competing tools — they are one lineage.
</aside>
2013 Ansible Tower released — the commercial web UI for Ansible.
Closed source, sold by AnsibleWorks, then Red Hat after the 2015 acquisition.
2017 Red Hat open-sources Tower's codebase as AWX.
AWX becomes the free UPSTREAM project; Tower remains the supported downstream product.
2021 With Ansible Automation Platform 2.0, "Ansible Tower" is renamed
"automation controller". The product did not change. The name did.
Today AWX (free, upstream, community-supported)
-> automation controller (supported, subscription)
-> one component of Ansible Automation Platform (AAP)
<aside> 💡
The analogy that makes it click, and the one Red Hat itself uses:
AWX is to Automation Controller what Fedora is to RHEL.
Same codebase lineage. AWX moves fast, is free, and is where features land first. Automation Controller is the stabilised, supported, subscription version. You learn one and you know the other — the UI, the object model and the API are the same.
</aside>
| Name | Who says it, and why |
|---|---|
| Ansible Tower | Was the commercial product for eight years, so it is the name in job adverts, in most training material, in enterprise procurement, and in the vocabulary of anyone who worked with it before 2021. This is the name an interviewer will most likely use |
| AWX | The free upstream. Mostly encountered by people who self-host it, or who evaluate before buying. Rarely appears in job adverts |
| automation controller | The current correct name. Used in current Red Hat documentation, and by teams already on AAP 2.x |
| AAP | The whole suite — controller plus Private Automation Hub, Execution Environments and Event-Driven Ansible |
<aside> 🎯
What to say when an interviewer says "Tower".
Do not correct them, and do not pretend it is a different product. Answer the question, and fold the current naming in naturally:
"Yes — Tower is what's now called automation controller since AAP 2.0; I've used AWX, which is the same codebase as the free upstream. In it I'd solve that with a job template plus a survey and Execute-only RBAC..."
That single sentence does three things: it answers them, it shows you know the current naming, and it signals you have hands-on exposure rather than only product-brochure familiarity. Correcting an interviewer's vocabulary without answering their question achieves the opposite.
</aside>
<aside> ⚠️
One practical difference worth knowing, beyond the name. AWX is not supported for production by Red Hat — it has no support contract, no long-term-support releases, and it upgrades frequently with occasional breaking changes.
Plenty of organisations run it in production anyway and accept that. But "we run AWX in production" and "we run automation controller in production" are different risk statements, and an interviewer at an enterprise may well probe which one you mean.
</aside>