🎛️Module 12 — Ansible Tower, AWX & Automation Platform

NAME                        READY   STATUS    RESTARTS
awx-demo-postgres-13-0      1/1     Running   0
awx-demo-task-7c9f...       4/4     Running   0
awx-demo-web-6d8b...        3/3     Running   0

After launching, the job output pane shows exactly the same text ansible-playbook produces:

PLAY [Configure web tier] ******************************************
TASK [Gathering Facts] *********************************************
ok: [web01]
TASK [Ensure nginx is installed] ***********************************
changed: [web01]
PLAY RECAP *********************************************************
web01 : ok=4  changed=2  unreachable=0  failed=0

That identical output is the point worth internalising. AWX runs the same ansible-playbook, in an Execution Environment container, against the same inventory. It adds no capability to the run itself.

What it added is around the run: the job has a number, an operator, a timestamp, the exact project commit SHA, the inventory used, and searchable output — all retained. Open the job's Details tab and you can see precisely which revision of the repository ran, which answers "what was deployed on Tuesday?" definitively.

Note the three pods. web serves the UI and API, task runs the dispatcher and job scheduler, postgres stores everything. Jobs execute in short-lived EE containers spawned by the task pod — which is why an Execution Environment is a prerequisite rather than an optional extra.

Nothing about the run itself — it executes the same engine. It adds everything around the run: RBAC over who may launch what against which inventory, a credential store where secrets are write-only and never displayed, an audit trail of every job with its operator and the exact commit SHA, scheduling with history, job queueing and concurrency control, surveys giving non-YAML users a web form, and Execution Environments for a consistent runtime.

You adopt it when the constraint shifts from "can we automate this" to "who is allowed to, and can we prove what happened".

One lineage, three names. Ansible Tower was the commercial web UI from 2013. In 2017 Red Hat open-sourced its codebase as AWX, which became the free upstream. In 2021, with AAP 2.0, Tower was renamed automation controller — a rename, not a new product. Ansible Automation Platform is the whole suite: controller plus Private Automation Hub, Execution Environments and Event-Driven Ansible.

The analogy Red Hat uses: AWX is to automation controller what Fedora is to RHEL — same lineage, upstream moves fast and is unsupported, downstream is stabilised and subscription-supported.

Worth adding: AWX has no Red Hat production support, so "we run AWX in production" and "we run automation controller" are different risk statements.

Answer the question, and fold the current naming in naturally rather than correcting them:

"Yes — Tower is what's now called automation controller since AAP 2.0; I've used AWX, which is the same codebase upstream. In it I'd solve that with a job template plus a survey and Execute-only RBAC..."

That answers them, shows you know the current terminology, and signals hands-on exposure. Correcting their vocabulary instead of answering achieves the opposite — and "Tower" remains the name in most job adverts, so it is not really wrong.

A job template running a narrowly scoped playbook, with a survey offering only the permitted service names as a multiple-choice field and a limit restricting the hosts. Grant the support team Execute on that one template only.

They can launch it; they cannot view the credentials, edit the playbook, change the inventory, or run anything else. Every launch is attributed, timestamped and logged.

That is least privilege, RBAC, surveys and auditability in one design.

They are encrypted at rest and write-only from the UI — once saved, a secret can be used by a job but never displayed again, not even to an administrator.

That is what allows execute rights without read rights on the underlying secret, which is the security property laptops and CI variables cannot provide.

Credential plugins go further, fetching from HashiCorp Vault, CyberArk or a cloud secret store at launch time so the secret is never stored in AWX at all.

------Starting Standard Out Stream------

PLAY [Configure web tier] ******************************************
TASK [Gathering Facts] *********************************************
ok: [web01]
TASK [Ensure nginx is installed] ***********************************
changed: [web01]

PLAY RECAP *********************************************************
web01 : ok=4  changed=2  unreachable=0  failed=0

------End of Standard Out Stream--------

status: successful
id: 4821
exit code: 0

And on a failure:

status: failed
id: 4822
exit code: 1

--monitor is what makes this usable from CI. Without it, launch returns immediately with a job ID and exit code 0 — so your pipeline reports success while the deployment is still running, and never learns whether it worked. With --monitor, awxkit streams the output and exits non-zero if the job fails, so the CI job fails correctly.

This is the pattern for combining CI and AWX rather than choosing between them. CI does what it is good at — lint, Molecule, build, gate on a merge. AWX does what it is good at — hold the credentials, enforce RBAC, run the change, keep the audit trail. The pipeline triggers AWX rather than holding production SSH keys itself, which means a compromised CI runner cannot reach production directly.

Use an OAuth token scoped to that one template, not admin credentials, so the pipeline can launch exactly one thing.

A graph of job templates connected by on-success, on-failure and always branches — so a single launch can build, deploy to staging, smoke-test, pause for approval, deploy to production, and always update the CMDB.

You need one when a change is several jobs with conditional paths, or when it requires a human gate. The approval node pauses indefinitely until someone with Approve permission acts, and records who approved and when — change management inside the automation rather than beside it.

ansible.builtin.set_stats in the earlier job. Values set that way become extra vars in every subsequent node of the workflow.

Without it each job template is isolated and people resort to writing a file or using an external store, which is the workaround that signals someone has not met set_stats.

Survey answers arrive as extra vars — precedence level 22 — so they override everything in the playbook. A free-text field is effectively a way for the user to set any variable.

Mitigate with multiple-choice fields wherever the valid set is knowable, password-type fields for secrets so they are masked in output, and an assert block validating free-text input at the top of the playbook. A survey is an input boundary and deserves input validation.

As code, with the awx.awx collection — projects, inventories, credentials, job templates, surveys, schedules and RBAC all declared in a Git repository and applied by a pipeline.

That makes the platform reproducible, reviewable in a diff and restorable after a disaster. A UI hand-configured over two years is a single point of failure no backup fully captures.

awxkit and the REST API cover the operational side — launching, monitoring, exporting.

Both, for different jobs. CI does lint, Molecule, build and merge gating. AWX holds the credentials, enforces RBAC, runs the change and keeps the audit trail.

The pipeline triggers AWX with awx job_templates launch --monitor, using a token scoped to that one template — so --monitor makes the CI job fail when the deployment fails, and a compromised CI runner still cannot reach production directly because it never holds the SSH keys.

# awx/support-desk.yml   -- requirements 1, 2, 5
---
- name: Declare the support-desk capability
  hosts: localhost
  gather_facts: false
  module_defaults:
    group/awx.awx.controller:
      controller_host: "{{ controller_host }}"
      controller_oauthtoken: "{{ vault_awx_token }}"

  tasks:
    - name: Job template - restart a permitted service
      awx.awx.job_template:
        name: "Support - Restart Service"
        organization: Engineering
        project: Platform Automation
        playbook: playbooks/restart-service.yml
        inventory: Production
        credentials: ["Production SSH", "Production Vault"]
        execution_environment: "platform-ee-1.4.2"
        become_enabled: true
        ask_limit_on_launch: false                 # requirement 1 - they cannot widen scope
        survey_enabled: true
        survey_spec:
          name: Which service?
          spec:
            - question_name: Service
              variable: target_service
              type: multiplechoice                 # requirement 2 - NOT free text
              choices: ["nginx", "app-api", "worker"]
              required: true

    - name: Grant the support team Execute on that template ONLY
      awx.awx.role:
        team: Support Desk
        role: execute                              # requirement 1
        job_template: "Support - Restart Service"
        state: present

# playbooks/restart-service.yml   -- requirement 2, defence in depth
---
- name: Restart a permitted service
  hosts: web
  become: true
  tasks:
    - name: Reject anything not on the allow-list
      ansible.builtin.assert:
        that:
          - target_service in ['nginx', 'app-api', 'worker']
        fail_msg: "target_service '{{ target_service }}' is not permitted"

    - name: Restart it
      ansible.builtin.service:
        name: "{{ target_service }}"
        state: restarted

# awx/deploy-workflow.yml   -- requirements 3, 4, 5
    - name: Build job records the version
      awx.awx.job_template:
        name: "Build Artifact"
        project: Platform Automation
        playbook: playbooks/build.yml
        inventory: Build Nodes
      # playbooks/build.yml ends with:
      #   - ansible.builtin.set_stats:
      #       data: {built_version: "{{ app_version }}"}    <- requirement 4

    - name: Production deploy workflow
      awx.awx.workflow_job_template:
        name: "Deploy to Production"
        organization: Engineering
        ask_variables_on_launch: true

    - name: Workflow nodes
      awx.awx.workflow_job_template_node:
        workflow_job_template: "Deploy to Production"
        unified_job_template: "{{ item.tpl }}"
        identifier: "{{ item.id }}"
        approval_node: "{{ item.approval | default(omit) }}"
      loop:
        - {id: build,   tpl: "Build Artifact"}
        - {id: approve, approval: {name: "Approve production deploy",
                                    description: "Engineer sign-off required",
                                    timeout: 86400}}          # requirement 3
        - {id: deploy,  tpl: "Deploy Web Tier"}

# Requirement 7 - the SSH key never lives in AWX's database
    - name: Credential sourced from HashiCorp Vault at launch time
      awx.awx.credential:
        name: "Production SSH"
        organization: Engineering
        credential_type: "Machine"
        inputs:
          username: deploy
        state: present
      # then attach a credential INPUT SOURCE so ssh_key_data is
      # fetched from HashiCorp Vault when the job launches

# Requirement 6 - CI triggers AWX and gates on the outcome
awx job_templates launch "Deploy to Production" \
  --extra_vars '{"app_version": "'"$CI_COMMIT_TAG"'"}' \
  --monitor
# --monitor exits non-zero when the job fails, so the pipeline fails too

The seven decisions:

1. Execute role on one template, ask_limit_on_launch: false — requirement 1. They can launch it and nothing else, and cannot widen the host scope.
2. multiplechoice survey, not text — requirement 2. Survey answers are extra vars at precedence 22; a free-text field would let them set any variable in the playbook.
3. The assert in the playbook as well — defence in depth. The survey constrains the UI; the assert constrains the API, which someone with the token could call directly.
4. An approval node before the deploy node — requirement 3, with a timeout so it does not hang forever. The approval is recorded with identity and timestamp.
5. set_stats at the end of the build playbook — requirement 4. Those values become extra vars in every later workflow node automatically.
6. --monitor on the CI launch — requirement 6. Without it the pipeline exits 0 immediately and never learns the outcome.
7. A credential input source pointing at HashiCorp Vault — requirement 7. AWX holds a reference, not the key; CI holds only a scoped OAuth token. Neither system stores the production SSH key.

Verify:

ansible-playbook awx/support-desk.yml
awx job_templates list --name "Support - Restart Service"
awx roles list --team "Support Desk"
awx workflow_job_templates list
awx job_templates launch "Support - Restart Service" \
  --extra_vars '{"target_service":"redis"}' --monitor   # must FAIL on the assert

That last command is the proof that requirement 2 actually holds at the API layer, not just in the web form.

It adds nothing to the run itself — it executes the same ansible-playbook. It adds RBAC, a write-only credential store, an audit trail with the exact commit SHA, scheduling with history, queueing, surveys, and Execution Environments.

You adopt it when the constraint becomes "who is allowed to run this, and can we prove what happened".

AWX is the free upstream project. Ansible Tower was the supported product, renamed Automation Controller. AAP is the full suite — Controller plus Private Automation Hub, Execution Environments and Event-Driven Ansible.

They are write-only — usable by a job but never displayable again, not even to an admin. That enables execute rights without read rights on the secret, which laptops and CI variables cannot provide.

Credential plugins go further, fetching from HashiCorp Vault or a cloud store at launch so the secret is never in AWX at all.

A narrowly scoped job template, a multiple-choice survey listing only permitted services, ask_limit_on_launch: false, and the team granted Execute on that template alone. Plus an assert in the playbook so the constraint also holds at the API layer.

They launch it; they cannot see credentials, edit the playbook, change the inventory or run anything else — and every launch is attributed.

Answers arrive as extra vars at precedence 22, overriding everything in the playbook. A free-text field lets the user set any variable.

Use multiple-choice wherever possible, password type for secrets so they are masked, and validate free text with assert at the top of the playbook.

set_stats in the earlier job — those values become extra vars in every subsequent node. Without it each template is isolated and people resort to files or external stores.

A workflow node that pauses indefinitely until someone with the Approve role acts, recording their identity and timestamp.

It puts change control inside the automation rather than beside it in a ticket, and it is the direct answer to "how do you handle change management for automated production changes?"

As code, with the awx.awx collection from a Git repository applied by a pipeline — projects, inventories, credentials, templates, surveys, schedules and RBAC.

A UI hand-clicked over two years is unreproducible and unrestorable. Add scheduled awx export for a config backup independent of the database.

Both, for different jobs. CI lints, tests with Molecule, builds and gates merges. AWX holds credentials, enforces RBAC, runs the change and keeps the audit trail.

CI triggers AWX with a scoped token, so a compromised runner never holds production SSH keys.

Without it, awx job_templates launch returns immediately with exit code 0 — the pipeline goes green while the deployment is still running, and never learns whether it succeeded.

--monitor streams the output and exits non-zero when the job fails.

Behaviour verified against the current AWX documentation and the awx.awx collection reference.

Question selection cross-referenced against publicly published 2026 Ansible interview question sets:

• Spacelift — 50+ Top Ansible Interview Questions & Answers for 2026
• GeeksforGeeks — Top 50+ Ansible Interview Questions and Answers
• Vinsys — Top 30 Ansible Interview Questions and Answers 2026
• K21 Academy — Ansible Interview Questions & Answers 2026
• Hirist — Top 25+ Ansible Interview Questions and Answers 2026

Answers were rewritten and deepened rather than reproduced — published versions are usually correct but shallow, and the added operational detail is what differentiates a candidate in the room.