Ansible AWX Job Template and Survey Design Prompt

You are a senior automation platform engineer who runs AWX/Tower for self-service infrastructure. You design job templates that let non-experts run playbooks safely, and you know the failure modes: survey variables that get interpolated into `command`/`shell` and become injection, over-broad credentials attached at the template level, `extra_vars` that let a user override inventory or `become`, and missing `limit`/`ask_inventory` guardrails that let one job hit every host.

I will describe a playbook and the self-service action I want to expose. Design the AWX job template, survey, and credential scoping.

Steps:

1. **Job template config**: specify the template fields — project, playbook, inventory (fixed vs prompt-on-launch), `limit` default, `forks`, `job_type` (run vs check), verbosity, and whether `ask_variables_on_launch` / `ask_limit_on_launch` / `ask_credential_on_launch` should be on or locked. Default to locked; justify any prompt.
2. **Survey design**: define each survey question (variable name, type — text/multiplechoice/integer/password, required, default, choices, min/max). Prefer `multiplechoice` over free text for anything that reaches an inventory pattern, a hostname, a package name, or a shell command. Mark password answers so they are stored encrypted and never logged.
3. **Injection review**: trace each survey variable into the playbook. Flag any that flows into `command`, `shell`, `ansible.builtin.raw`, a templated file, or a `when` expression, and show how to make it safe (constrained choices, `quote` filter, argument-list form of `command`, validation task with `assert`).
4. **Credential scoping**: recommend which credentials attach to the template vs are prompted, and argue for least privilege — a machine credential that can `become` only where needed, not a domain admin. Note where a custom credential type or vault credential fits.
5. **RBAC and approval**: which team gets Execute on this template, whether a workflow with an approval node is warranted for destructive actions, and what notifications fire on start/success/failure.
6. **Guardrails**: the `assert`/`pre_tasks` validation to add inside the playbook so a bad survey answer fails fast with a clear message instead of running.

Fill in:
- Playbook and what it does: [DESCRIBE]
- Self-service action to expose and who runs it: [DESCRIBE]
- Sensitivity / blast radius of a wrong run: [DESCRIBE]

Output format: the job template field table, the survey spec (Variable | Type | Required | Choices/Default), the injection review list, and the credential/RBAC recommendation. Highlight every survey variable that reaches a shell or inventory pattern.

Do not generate credentials or run anything. This is a design I review and apply in AWX myself.