# Ansible AWX & Automation Controller (Tower): — From CLI to a Control Room Source: https://ai.techclick.in/blog_ansible_awx_tower Markdown: https://ai.techclick.in/blog_ansible_awx_tower.md Publisher: Techclick Infosec Pvt Ltd Ansible AWX & Automation Controller (Tower) for L1/L2 engineers and EX374: why a platform beats laptop runs, the core objects (Projects, Inventories, Credentials, Job Templates), RBAC, schedules, workflows, surveys, notifications and execution environments. Ansible AWX & Automation Controller (Tower): — From CLI to a Control Room student learning map A visual study map for Ansible AWX & Automation Controller (Tower): — From CLI to a Control Room showing learning path, evidence, traps, and practice sequence. TECHCLICK STUDY MAP Ansible AWX & Automation Controller (Tower): — From... Ansible · learn the flow, prove with evidence, avoid unsafe shortcuts 1. Start 🎯 By the end you will be able to 2. Understand Pick where you want to start 3. Prove ① Why a platform — one laptop... 4. Practice ② Core objects — Projects,... How to use this page First build the mental model, then connect the concept to a realistic production decision. Finish by testing yourself. Techclick Infosec Pvt Ltd | ai.techclick.in | Training Contact: WhatsApp +91 92772 29456 Content-specific feature visual for this lesson: use it as the 60-second map before reading the full detail. Most engineers think… Most engineers hear "AWX / Tower" and think it's just "a pretty web GUI that runs my playbooks for me" — a nicer button for the same ansible-playbook command, and nothing more. Wrong — and that view will cost you in interviews and on the job. The GUI is the easy part. The real product is a control plane : RBAC (who may run what), an audit trail (who ran it, when, and the full output), encrypted credential storage with run-time injection (the vault/SSH key never sits in someone's shell history), schedules and workflows (chained jobs that fire at 2 a.m. on their own), and execution environments (a pinned container so every run uses the same Ansible and collections). The dashboard is the door; governance is the building. ## ① Why a platform — one laptop doesn't scale to a team Meet Sneha, an L1 automation engineer at Infosys . She wrote a tidy backup.yml that pulls every branch router's config and saves it to Git. It runs perfectly — from her laptop, with her SSH key, when she remembers to run it. Then the team grows to six engineers, the auditors ask "who changed the Mumbai core switch last Tuesday?", and Sneha goes on leave the week the nightly backup was supposed to fire. Every one of those problems is the same problem: a single laptop is not a team . Walk the five gaps. No RBAC: anyone with the repo and a key can run anything against production — there is no "this junior may run the backup but not the firewall push." No audit: when something breaks at 9 a.m., there is no record of who ran what overnight or what the output was. No schedule: the nightly backup depends on a human (or a fragile cron on one box that nobody owns). No secret management: the Vault password and SSH keys live in shell history, sticky notes and scattered laptops. No self-service: a NOC analyst who just needs to run one safe, approved task has to be handed root and the whole repo. 👉 So far: five gaps a laptop leaves — no RBAC, no audit, no schedule, no secret management, no self-service. Next: what AWX and Automation Controller actually put on top of Ansible to close them. Here is the shift. AWX is the open-source upstream; Red Hat Automation Controller (the product formerly named Ansible Tower ) is the supported build of the same idea. Both wrap a web UI + REST API + control plane around the very same Ansible engine. Your playbooks do not change. What changes is everything around the run: who can launch it, where the secrets live, when it fires, and what gets recorded. Figure 1 — One laptop vs a shared control room A two-column comparison. Left, red: one engineer runs ansible-playbook from a personal laptop with the vault password in shell history, no record of who ran what, no schedule, and SSH keys spread across machines. Right, green: AWX or Automation Controller adds a web UI and REST API in front of the same Ansible, with role-based access control, encrypted credentials injected at run time, schedules, a workflow engine and a full audit trail. Red marks the ungoverned laptop world; green marks the platform. One laptop vs a shared control room — same Ansible underneath ansible-playbook from one laptop ✗ no RBAC — anyone with the repo can run anything ✗ no audit — who ran it, when, with what? ✗ no schedule — backups depend on you remembering ✗ vault password in shell history / a sticky note ✗ SSH keys copied onto many laptops your laptop site.yml + key 40 routers no record left behind - AWX / Automation Controller ✓ Web UI + REST API in front of the same Ansible ✓ RBAC — who can run which job template ✓ encrypted Credentials injected at run time ✓ Schedules + Workflows + Notifications ✓ full audit trail — every job + who launched it Controller UI · API · RBAC · log 40 routers every run logged Same playbooks. The platform adds the control a team needs. untrusted / no control platform / trusted policy / decision key insight allowed / success Read both columns for the same job. Left (red) = one laptop, secrets in shell history, no record. Right (green) = the platform adds RBAC, encrypted credentials, schedules, workflows and a full audit trail — same Ansible underneath. ### The five gaps, one tap each Tap each card — these five are exactly why teams stop running from laptops and stand up a platform. 🔑 No RBAC tap to flip Anyone with the key can run anything on prod. So: no way to say 'junior may back up but not push firewall rules'. 📓 No audit tap to flip Something breaks at 9 a.m. and nobody can prove who ran what overnight. So: no rollback story and no accountability. ⏰ No schedule tap to flip The nightly backup needs a human or a cron box nobody owns. So: the one night it's skipped is the night you need it. 🤫 No secret mgmt tap to flip Vault password and SSH keys in shell history and on laptops. So: one stolen laptop = one stolen production key. Daily-life analogy — society gate-pass register vs leaving the gate open A laptop run is like leaving your housing-society gate open: anyone walks in, nobody logs who came or when. The Controller is the gatekeeper with a gate-pass register — the guard (RBAC) checks who you are and whether you're allowed in, the register (audit trail) records every entry with a timestamp, and visitors only reach the flats they're cleared for (least privilege). Same building, same people — but now there's a record and a rule for every entry. Pause & Predict Predict: AWX and Automation Controller are 'the same Ansible underneath.' So if your playbook works on the CLI but fails inside a Job Template, where do you look FIRST — the playbook logic, or the platform plumbing? Type your guess. Reveal answer Answer: The platform plumbing, almost always. The playbook already ran on the CLI, so the YAML logic is fine. The usual culprits are platform-side: the Project wasn't synced (the Template ran an old commit), the wrong Credential was attached (so login failed), or the Execution Environment is missing a collection the playbook imports. Reach for those before you re-read the playbook. Quick check · Q1 of 10 Rahul at TCS says: "We have six engineers all running the same playbooks from their own laptops. Auditors keep asking who ran what and we have no answer." Which platform feature directly fixes THAT complaint? a) The audit trail — every job records who launched it, when, and the full output b) A faster execution environment image c) Replacing the playbooks with shell scripts d) Giving everyone the same SSH key Correct: a. The audit trail (activity stream + per-job output) records who launched each job, when, and against which hosts — exactly the auditor's question. A faster EE image is unrelated; shell scripts make it worse; a shared key destroys accountability rather than creating it. ## ② Core objects — Projects, Inventories, Credentials & Job Templates The whole platform is built from a few objects that snap together. Learn these four and the rest is detail. Project = your playbooks, almost always backed by Git. Inventory = your hosts. Credential = your secrets, encrypted. Job Template = the runnable unit that binds the other three together. Let's take them one at a time, because the EX374 exam and your first day both live in this list. A Project points at a Git repository and a branch . When you (or a schedule) hit Sync , the platform pulls the latest commit so the playbooks it runs are always the approved ones in version control. This is the part new users trip over: edit a playbook in Git, forget to Sync the Project, and your Job Template happily runs the old commit. An Inventory is the list of hosts the job targets. It can be static (hosts you type in or group by hand) or come from a dynamic source that queries a cloud account or a script and refreshes itself, so a newly built VM appears without anyone editing a file. Credentials are where the platform earns its keep on security. They are stored encrypted and injected at run time — the engine drops the SSH key or vault password into the job's environment for the duration of the run and never shows it back in the UI. There are types that matter: a Machine credential (SSH login + become/sudo password for Linux), a Network credential (for network_cli -style device logins), a Vault credential (the password that decrypts your Ansible Vault files), and various cloud credentials (AWS, Azure, GCP keys). Pick the wrong type and the job can't authenticate even though the secret itself is correct. Finally the Job Template ties it together: it says "run this playbook (from this Project) against this Inventory using these Credentials inside this Execution Environment ," plus knobs like limit , verbosity , and optional survey prompts. Click Launch and it becomes a Job with a live, streamed log. That single bound, repeatable, logged unit is the heart of the whole product. Figure 2 — The four core objects bind into a Job Template Four core objects feed into a Job Template. The Project is your Git-backed playbooks. The Inventory is your hosts, static or from a dynamic source. The Credentials are encrypted secrets injected at run time, of type machine, network, cloud or vault. The Job Template binds project plus inventory plus credential plus an execution environment and optional survey prompts into one launchable unit. Launch produces a Job with a full log. Blue marks the platform objects, amber marks the credential decision point, green marks the launched job. The four core objects bind into one Job Template Project Git-backed playbooks synced from a branch Inventory hosts + groups static or dynamic source Credentials encrypted · injected at run time machine / network / cloud / vault Job Template project + inventory + credential + EE + survey prompts Launch → Job runs + streams output full log, who + when click Launch Key idea: one Template = one repeatable, governed run untrusted / no control platform / trusted policy / decision key insight allowed / success Follow the arrows: Project (playbooks) + Inventory (hosts) + Credentials (secrets, amber = decision) all feed the Job Template, which on Launch becomes a logged Job. The Credential is the run-time-injected piece. Automation Execution → Templates → Create template → Create job template . (Recreated for clarity — your console matches this.)"> 🖥️ This is the screen you'll use — Automation Execution → Templates → Create template → Create job template . (Recreated for clarity — your console matches this.) controller.lab.local · Automation Execution → Templates → Create job template 1 Name Nightly-Branch-Backup 2 Job type Run 3 Inventory Branch-Routers (dynamic) Project NetAutomation (main) Execution environment ee-network-2.6 Playbook backup.yml 4 Credentials br-net-login (Network) Options ☑ Prompt on launch (Limit) Create job template REST API — list job templates (every UI screen is also an API call; great for the EX374 'navigate the Controller' objective) curl -sk -u admin:'redhat' \ https://controller.lab.local/api/v2/job_templates/ | jq '.results[] | {id, name, project, inventory}' Expected output { "id": 14, "name": "Nightly-Branch-Backup", "project": 7, "inventory": 3 } Common mistake — "the Template runs an OLD version of my playbook" Symptom: you fixed a bug in Git, the Job Template still does the buggy thing. Cause: the Project wasn't synced , so the Template ran the previous commit. Fix: open the Project and click Sync (or set Update revision on launch so it syncs before every run). Related trap: editing the playbook directly on the controller's filesystem — that change is overwritten on the next Sync, because the Project's source of truth is Git, not the box. Quick check · Q2 of 10 Priya at HCL needs her backup Job Template to log in to Cisco routers. She attaches a plain Machine (SSH) credential and the job fails to authenticate to the devices. What's the cleanest fix? a) Attach a Network credential (for network_cli device logins) instead of, or alongside, the Machine type b) Paste the password into the playbook as a variable c) Give everyone the router enable password over chat d) Disable credentials for that template Correct: a. Network devices using a network_cli-style connection expect a Network credential, not a generic Machine credential — the type drives how the secret is injected. Pasting the password into the playbook defeats encrypted storage; sharing the enable password kills accountability; disabling credentials means no login at all. Pause & Predict Predict: a Credential is stored encrypted and 'injected at run time.' So after a job finishes, can another engineer open that Credential in the UI and read the SSH private key back out? Type your guess. Reveal answer Answer: No. The platform injects the secret into the running job's environment for the duration of the run, but it never displays the stored secret back in the UI — the field shows as encrypted/hidden. That's the whole point: people can USE a credential (by attaching it to a template they're allowed to run) without ever SEEING it. So a leaving employee's stored key isn't readable by the next person; it's rotated, not handed over. ## ③ Team features — RBAC, schedules, workflows, surveys & audit Now the features that turn "a GUI for Ansible" into "a platform a team can trust." Start with RBAC . You grant roles — like Admin , Execute or Read — on specific objects to users or teams . So a NOC analyst gets Execute on just the "Restart-Service" Job Template and Read on its inventory — nothing else. They can run the one safe thing and can't touch the firewall push. This is least privilege, enforced by the platform instead of by trust. Schedules let a Job Template fire on its own — "run the config backup every night at 02:00." No human, no fragile cron box. Workflows go further: the Workflow Visualizer lets you chain templates with branching — run the backup, and on success run the compliance check, but on failure page the on-call. You can even drop an approval node that pauses the workflow until a human clicks Approve — a built-in change gate. Surveys add safe, parameterised self-service: instead of editing the playbook, a user is shown prompts ("which site?", "dry-run or apply?") at launch, and their answers become variables. Notifications wire job start / success / failure (and workflow approval) to Slack, Microsoft Teams, email or a webhook . 👉 So far: RBAC scopes who runs what, schedules and workflows fire jobs on their own with branching and approvals, surveys give safe self-service, notifications shout to chat. Next: the audit trail and execution environments — the last two pieces. Two more. The audit trail (the activity stream plus every job's saved output) answers the auditor's question permanently: every job records who launched it, when, against which hosts, and the full log . And the Execution Environment (EE) is the container the job actually runs inside — it bundles a pinned Ansible version, the Python libraries and the collections your playbook imports. Because every run uses the same image, "works on my laptop" stops being a thing: a job either has its EE or it doesn't, the same way for everyone. Figure 3 — Laptop run vs Job Template run — the five rows that decide it A decision-style comparison table. Left column, the laptop run: secrets in plain files, no record of runs, manual scheduling, no self-service for junior engineers, and inconsistent Ansible versions per laptop. Right column, the Job Template run: secrets stored encrypted and injected at run time, every run audited, schedules built in, surveys give safe self-service, and one execution environment pins the Ansible version. Red marks the weak laptop choice, green marks the platform choice, amber marks the row that is a governance decision. Laptop run vs Job Template run — five rows that decide it ✗ laptop / CLI only ✓ AWX / Controller Secrets plain files / shell history encrypted, injected at run time Audit none — who ran it? every job + user logged Schedule cron on a box you maintain built-in Schedules tab Self-service junior needs root + the repo Survey + RBAC = safe button Ansible version differs per laptop one Execution Environment pins it The platform does not change your playbooks — it changes who can run them and what gets recorded untrusted / no control platform / trusted policy / decision key insight allowed / success The svg-compare card: secrets, audit, schedule, self-service and Ansible-version, scored laptop vs platform. The amber row (self-service) is the governance decision; everything else is a clear platform win. ### ▶ Watch RBAC + a survey turn a risky task into a safe button A NOC analyst at Wipro, Karthik, needs to restart a stuck service on one branch — but must NOT be able to touch anything else. Follow how the platform makes that safe. Press Play for the healthy path, then Break it to see the failure. ① Grant role admin gives Karthik only Execute on the Restart-Service template ▼ ② Launch + survey Karthik clicks Launch; a survey asks 'which site?' → answer becomes limit ▼ ③ Inject creds platform injects the Machine credential at run time; Karthik never sees the password ▼ ④ Log + notify job runs on one host; audit logs who+when; Slack gets a success ping Press Play to step through the healthy path. Then press Break it . ▶ Play Next ▶ ⚠ Break it ↺ Reset playbook YAML — the nightly backup the Job Template runs (cisco.ios; the secrets come from the attached Network credential, NOT from here) --- - name: Nightly branch config backup hosts: branch_routers gather_facts: false connection: network_cli tasks: - name: Pull and save running-config cisco.ios.ios_config: backup: true backup_options: dir_path: /backups/{{ inventory_hostname }} register: result - name: Fail the host if 'no telnet' baseline is missing ansible.builtin.assert: that: "'transport input ssh' in result.backup_path | default('')" fail_msg: "Drift: telnet not disabled on {{ inventory_hostname }}" Expected output PLAY [Nightly branch config backup] ******************************** TASK [Pull and save running-config] ******************************* changed: [br-mumbai-01] changed: [br-pune-01] TASK [Fail the host if 'no telnet' baseline is missing] *********** ok: [br-mumbai-01] failed: [br-pune-01] => Drift: telnet not disabled on br-pune-01 Prove RBAC actually scoped the user — don't assume After granting a role, log in as that user (or use the API with their token) and check what they can see. Run curl -sk -u karthik:... https://controller.lab.local/api/v2/job_templates/ — the list should contain only the templates they have a role on. If they can see (or worse, launch) templates you didn't grant, the role was attached too high up — at the Organization or Team level — instead of on the single object. Tightest scope wins. Meera at ICICI faces this Meera, an L2 engineer, schedules a nightly backup Job Template. The schedule shows it 'ran' at 02:00, but the Job failed instantly with 'ERROR! couldn't resolve module/action cisco.ios.ios_config' — yet the same playbook runs fine from her laptop. Likely cause The Job Template is pinned to an Execution Environment image that doesn't contain the cisco.ios collection. On her laptop the collection is installed locally; inside the EE container it isn't. Control-plane onboarding is fine — this is purely the run environment missing content. Diagnosis She reads the failed Job's output (not the playbook) and sees the 'couldn't resolve module' line — a classic missing-collection-in-EE signature, separate from any login or RBAC issue. Automation Execution → Jobs → (the failed run) → Output → then Templates → Nightly-Branch-Backup → Edit → Execution Environment Fix Point the Template at a network EE that bundles cisco.ios (e.g. a 'ee-network' image), or rebuild the EE with the collection added to its requirements; re-launch. Verify Re-run the Job → the cisco.ios.ios_config task now executes and the config files land in /backups; the next scheduled 02:00 run also succeeds and posts to Slack. Quick check · Q3 of 10 Aditya at Flipkart wants: run the backup, and ONLY if it succeeds run the compliance check; if the backup fails, page the on-call instead. Which platform feature expresses that? a) A single Job Template with extra verbosity b) A Workflow (Visualizer) with on-success and on-failure branches c) A static inventory with more groups d) A second Machine credential Correct: b. Branching 'on success do X, on failure do Y' is exactly what a Workflow's Visualizer expresses, chaining templates with success/failure/always links. Verbosity only changes log detail; more inventory groups or a second credential don't add conditional flow control. Pause & Predict Predict: a Survey lets a user supply variables at launch. So why is a Survey with a fixed dropdown ('site: Mumbai / Pune / Lucknow') safer than letting the user type the limit free-hand? Type your guess. Reveal answer Answer: Because it bounds the blast radius. A free-text limit lets a tired analyst type 'all' (or a typo that matches everything) and hit every device at once. A dropdown only offers the three approved sites, so the worst they can do is run the approved task on one approved target. Surveys give self-service AND guardrails — that's why they pair so well with Execute-only RBAC. ## ④ A real flow — nightly backup, scheduled, credentialed & notified Let's assemble everything into the flow you'll genuinely build in your first weeks: a nightly config-backup that runs against a dynamic inventory of branch routers, on a schedule , with a network credential injected, and the result posted to a Slack channel . Every object from sections ② and ③ shows up here in order, so this is also your revision. The build, step by step. 1. Create a Project pointing at your net-automation Git repo, branch main , with Update revision on launch ticked so it always runs the latest commit. 2. Create an Inventory with a dynamic Source so new routers appear automatically. 3. Create a Network Credential holding the device login (encrypted). 4. Create the Job Template binding all three plus a network Execution Environment that has cisco.ios . 5. Add a Schedule on that Template for 02:00 daily. 6. Attach a Notification (Slack/Teams webhook) on success and failure . 7. Grant the NOC team Execute via RBAC so they can launch it manually too, but can't edit it. ansible-navigator — run the same playbook inside the SAME EE locally before you trust it in a schedule (an EX374-flavoured habit) ansible-navigator run backup.yml \ -i inventory/branch.yml \ --execution-environment-image ee-network-2.6 \ --mode stdout --check Expected output PLAY [Nightly branch config backup] ******************************** TASK [Pull and save running-config] ******************************* ok: [br-mumbai-01] ok: [br-pune-01] PLAY RECAP ******************************************************** br-mumbai-01 : ok=1 changed=0 unreachable=0 failed=0 br-pune-01 : ok=1 changed=0 unreachable=0 failed=0 Three gotchas that bite real teams on exactly this flow. Credential scoping: the Network credential and the Job Template must live in the same Organization (and the launching user must have a role on the credential) or the Template can't attach it. Project sync: if you forget Update revision on launch and don't Sync, the 02:00 run executes last week's playbook — schedule the Project sync too, or tick the box. EE images: a Template pinned to the wrong/old EE image fails with 'couldn't resolve module' or an ansible-runner version mismatch even though the playbook is perfect. One sober note from 2025–2026: because the controller holds every credential and can run anything, it's a high-value target — patch it. CVE-2025-69534 is a denial-of-service in automation-controller (Ansible Automation Platform 2.6) triggered by malformed HTML-like input; Red Hat fixed it in a patch release. The lesson for you isn't the CVE number — it's that the platform that holds the keys to your whole estate has to be kept current and access-controlled, exactly the way you'd treat a Vault server. Automation Execution → Jobs → (pick the run) → Output / Details . (Recreated for clarity — your console matches this.)"> 🖥️ This is where you confirm a scheduled run actually fired and read its output — Automation Execution → Jobs → (pick the run) → Output / Details . (Recreated for clarity — your console matches this.) controller.lab.local · Automation Execution → Jobs → Output 1 Job Nightly-Branch-Backup #218 2 Status Successful 3 Launched by schedule: daily-0200 Execution environment ee-network-2.6 Inventory Branch-Routers (dynamic) 4 Notification slack: #net-backups ✓ View output Figure 4 — AWX / Automation Controller — the cheat-sheet A nine-tile cheat sheet. Tiles cover Organization and teams, Project, Inventory, Credential types, Job Template, Workflow Visualizer, Schedule and Notification, Survey and RBAC, and Execution Environment. Each tile gives a one-line role and the menu path or key idea. AWX / Automation Controller — your one-glance card Org → Teams → Users top container; RBAC hangs off it Access ▸ Organizations / Teams scope everything per org Project = Git repo of playbooks Sync pulls the latest commit forgot to Sync = old playbook Inventory hosts + groups + vars static, or a dynamic Source Source sync = self-updating Credential types Machine · Network · Cloud · Vault encrypted; injected at run time never shown back to the user Job Template project+inventory+cred+EE the runnable unit you Launch Templates ▸ Create job template Workflow Visualizer chain templates with branches on success / on failure / always + approval nodes for change gates Schedule + Notify Schedules tab = nightly backups Notifications → Slack / Teams on start / success / failure Survey + RBAC Survey = safe prompts on launch RBAC = who can run / edit / admin self-service without giving root Execution Environment container with Ansible + collections pins versions = same run everywhere wrong EE = missing module errors Your one-card map of this whole lesson: the object hierarchy, the menu paths, the credential types, the workflow branches, schedules/notifications, surveys+RBAC and execution environments. Keep it open in week one and before any EX374 interview. Daily-life analogy — the dabbawala dispatch board The whole platform is a Mumbai dabbawala dispatch board . The Project is the route book (the playbooks). The Inventory is today's delivery list (the hosts). the Credential is the building gate-pass, handed to the carrier only at the door and taken back after (injected at run time). The Schedule is the fixed train time. The Notification is the SMS when lunch is delivered. And the dispatcher with the register is RBAC + audit — who carries which tiffin, and proof it was delivered. Pairs with: Ansible for Config Backup & Compliance Prove you own this lesson Cold, in 30 seconds: name the four core objects and what each holds ( Project=playbooks, Inventory=hosts, Credential=encrypted secrets, Job Template=the bound runnable unit ); say why a Credential can be USED but not READ (encrypted + injected at run time); and explain how RBAC + a Survey let a junior run one safe task without root. If you can do that without notes, you're ready for the EX374 Controller objectives and your first platform shift. Quick check · Q4 of 10 An interviewer asks Neha: "Give me the single biggest reason a team moves config backups off engineers' laptops and into a scheduled Job Template." Best answer? a) The web UI looks nicer than a terminal b) It runs the same Ansible, so nothing really changes c) It adds the control the playbook never had — RBAC, audit, run-time secret injection, and a schedule that fires without a human d) Execution environments make playbooks run faster Correct: c. The move is about governance, not cosmetics: the platform adds who-can-run (RBAC), who-ran-it (audit), encrypted run-time secrets, and an unattended schedule — none of which a laptop run has. A nicer UI is a side effect; 'nothing changes' misses the whole point; EEs add consistency, not raw speed. ### 🤖 Ask the AI Tutor Tap any question — instant, scoped to this lesson. No login, no waiting. AWX vs Automation Controller vs Ansible Tower — what's the actual difference? Why store credentials in the platform at all — why not just keep using Ansible Vault? What exactly is an Execution Environment and why do I keep hitting 'couldn't resolve module' errors? How is a Workflow different from just one big Job Template? If a Survey lets users pass variables, can't they pass something dangerous? How much of EX374 does this one lesson actually cover? Pre-curated from Ansible docs + community Q&A, scoped to this lesson. For a live prod issue, paste your export into chat.techclick.in. ## 📝 Wrap-up assessment — six more You've answered 4 inline. Six left. 70% (7 of 10) marks the lesson complete on your profile. Tap Submit all answers at the end. Q5 · Remember In AWX / Automation Controller, which object binds a Project (playbook), an Inventory (hosts) and Credentials into one unit you can click 'Launch' on? a) A Schedule b) An Execution Environment c) A Notification d) A Job Template Correct: d. The Job Template is the runnable unit binding project + inventory + credential (+ EE) into something you Launch. A Schedule only fires a template automatically; an Execution Environment is the container it runs in; a Notification just reports the result. Q6 · Apply An Airtel NOC analyst must be able to run ONE approved restart playbook and nothing else — no editing, no other templates. What do you configure? a) Grant Execute on just that Job Template via RBAC b) Give them the Organization Admin role c) Hand them the root SSH key and the repo d) Add them as a system superuser Correct: a. Execute on a single Job Template is least privilege — they can run that one thing and nothing else. Org Admin or superuser grants far too much; handing over the root key and repo removes all control and accountability. Q7 · Apply You need a config backup to run unattended every night at 02:00 against your branch routers. Which platform feature do you use, and what stops it running last week's playbook? a) A Workflow approval node; nothing is needed for freshness b) A Schedule on the Job Template, plus Project sync (or 'Update revision on launch') so it runs the latest commit c) A Survey that asks the time each night d) A second Credential of the Vault type Correct: b. A Schedule fires the template unattended; syncing the Project (or ticking 'Update revision on launch') guarantees it runs the latest committed playbook, not a stale one. An approval node would pause it (not unattended); a Survey gathers variables, not freshness; a Vault credential decrypts secrets, unrelated to scheduling. Q8 · Analyze A scheduled Job Template fails instantly with 'ERROR! couldn't resolve module/action cisco.ios.ios_config', but the exact same playbook runs fine from the engineer's laptop. Most likely root cause? a) The Project's Git URL is wrong b) RBAC is blocking the schedule from launching c) The Execution Environment image pinned to the template doesn't contain the cisco.ios collection d) The Inventory has no hosts Correct: c. Working on the laptop but failing in the job points at the run environment: the EE container lacks the cisco.ios collection that's installed locally. A wrong Git URL would fail the Project sync, not resolve a module; RBAC blocking would stop the launch with a permission error; an empty inventory gives 'no hosts matched', not 'couldn't resolve module'. Q9 · Analyze A leaving employee had an SSH key stored as a Machine credential, attached to several Job Templates other engineers run daily. After they leave, what's true about that stored key in AWX/Controller? a) Any remaining engineer can open the credential and read the private key to reuse it b) The key was only ever in the leaver's shell history, so nothing is stored centrally c) Other engineers can keep USING the credential via the templates, but cannot READ the key back — so you rotate the secret centrally without it ever being exposed d) All jobs using it stop working the moment the user is deleted Correct: c. Credentials are stored encrypted and injected at run time, never displayed back — so people use them via templates without seeing them, and you rotate the secret in one place. The key isn't readable in the UI (so not option 1); it IS stored centrally (not option 2); and deleting the user doesn't delete the credential the templates reference (not option 4). Q10 · Evaluate Two ways to justify moving off laptop runs to a hiring manager: (A) 'the web UI is friendlier than a terminal'; (B) 'it adds RBAC, an audit trail, encrypted run-time credential injection, schedules and branching workflows — control the CLI never had.' Which is stronger and why? a) A — friendliness is what teams care about most b) B — it names the governance the platform adds (who-can-run, who-ran-it, secret handling, unattended scheduling) that produces the real value c) A — the UI is the only meaningful difference d) Identical — both say the same thing Correct: b. B names the actual architecture-level wins — RBAC, audit, encrypted run-time secrets, schedules and workflows — which are what the exam and the job test. A lists a cosmetic side effect; the platform runs the same Ansible, so 'friendlier UI' isn't the reason teams adopt it. Submit all answers Try again Lesson complete — saved to your profile. Almost! You need 70% (7 of 10) — re-read the path that tripped you up and tap "Try again". ### 🧠 In your own words Type one line: In one line, why can an engineer USE a stored credential to run a job but NOT read the secret back out of the UI? Then compare to the expert version. Compare with expert answer Expert version: Because the platform stores the credential encrypted and injects it into the job's environment only for the duration of the run, never displaying the stored value back — so people can run jobs that use a secret without ever holding it, which is what lets you give access without giving away the key. ### 🗣 Teach a friend Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary. Generate my one-liner 📩 Quiz me on this in 7 days. Opt in and we'll email 3 micro-questions on AWX & Automation Controller at Day 1, Day 7 and Day 30 — spaced repetition is how this sticks. Un-tick any time. ### 📖 Glossary AWX The open-source upstream project — a web UI, REST API and task engine for Ansible. Red Hat's Automation Controller is built from it. Automation Controller Red Hat's supported product (formerly Ansible Tower) that runs jobs inside Ansible Automation Platform. Project A collection of playbooks in AWX/Controller, usually synced from a Git branch. Sync pulls the latest commit. Inventory The managed hosts, grouped logically. Static (typed in) or dynamic (pulled from a live source and refreshed). Credential A stored secret (SSH key, password, token, vault password). Encrypted, injected at run time, never displayed back. Credential type What the secret is for — Machine (SSH), Network (device login), Cloud (AWS/Azure/GCP), or Vault (decrypts Ansible Vault). Job Template The runnable unit: binds a Project, Inventory, Credentials and an Execution Environment, plus options and survey prompts. RBAC Role-Based Access Control — grant roles (Admin/Execute/Read) on specific objects to users and teams. Enforces least privilege. Schedule A rule that launches a Job Template automatically (e.g. nightly at 02:00) with no human and no fragile cron box. Workflow A graph chaining templates and syncs with on-success/on-failure/always branches, plus optional human approval nodes. Survey A launch-time form whose answers become job variables — gives parameterised self-service with guardrails. Execution Environment (EE) A container image bundling a pinned Ansible version, Python libraries and collections. The job runs inside it for reproducibility. #### 📚 Sources Red Hat Ansible Automation Platform 2.5 — Using automation execution: 'Job templates' (exact UI path Automation Execution ▸ Templates ▸ Create job template; fields Name, Job type, Inventory, Project, Execution Environment, Playbook, Credentials, Labels, Forks, Limit, Verbosity, Privilege escalation, Prompt on launch). docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.5/html/using_automation_execution/controller-job-templates - Red Hat Ansible Automation Platform 2.5/2.6 — Using automation execution: 'Workflow job templates' (the Workflow Visualizer; chaining job templates, project/inventory syncs; on-success/on-failure/always; approval nodes; surveys, schedules and notifications on workflows). docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.5/html/using_automation_execution/controller-workflow-job-templates - Ansible AWX community documentation — Overview & User Guide (AWX as the open-source upstream: projects, inventories, credentials, job templates; credentials encrypted and injected at run time; RBAC; execution environments). docs.ansible.com/projects/awx/en/latest/userguide/overview.html - AWX GitHub Issues — project sync failing inside the Control Plane / default Execution Environment after operator/CRD reapply, plus ansible-runner version mismatch and OOM (rc 137) symptoms (real EE gotchas behind 'couldn't resolve module' and failed syncs). github.com/ansible/awx/issues/12117 · github.com/ansible/awx-operator/issues/1882 - Red Hat Security — CVE-2025-69534: denial of service via malformed HTML-like sequences in automation-controller for Ansible Automation Platform 2.6 (fixed in a patch release; why the credential-holding control plane must be patched and access-controlled). access.redhat.com/security/cve/CVE-2025-69534 · docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.5/html/release_notes/patch_releases - Red Hat EX374 — 'Red Hat Certified Specialist in Developing Automation with Ansible Automation Platform' exam objectives (navigate the Controller UI; create job templates and workflows; manage inventories and credentials; projects from SCM; configure RBAC; create execution environments). redhat.com/en/services/training/red-hat-certified-specialist-developing-automation-ansible-automation-platform-exam ### What's next? You can now run any playbook from a governed control room. But a backup that hard-codes every device's hostname and IP doesn't scale — the next lesson makes your configs build themselves with Jinja2 templating and proves they're safe to re-run with idempotency. Next · Ansible Jinja2 Templating & Idempotency: Configs That Build Themselves → Practice on exam.techclick.in → --- Cite this Techclick lesson with the source URL. Do not invent fees, batch dates, or job guarantees. Browse all lessons: https://ai.techclick.in/blogs AI index: https://ai.techclick.in/llms.txt