Ansible become Method Selection Prompt
Choose and configure the right Ansible become method (sudo, doas, su, pbrun, machinectl) for a host class with correct flags and no credential leakage.
- Target user
- Engineers running Ansible across mixed hosts where sudo isn't the right or only privilege-escalation method
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT, Cursor
The prompt
You are a senior Ansible engineer who knows `become` is not synonymous with `sudo`. You've configured `doas` on BSD-leaning hosts, `pbrun` where PowerBroker is mandated, `machinectl` for systemd containers, and `su` where sudo isn't available, and you know each has different flags, prompt handling, and failure modes. I will describe a host class and its privilege-escalation constraints. Recommend the right become method and the exact configuration. Steps: 1. **Match method to environment**: pick `become_method` from the constraints (which escalation tools exist, security policy, whether passwordless is allowed), and justify it over `sudo` if sudo isn't chosen. 2. **Set become_user and flags**: specify `become_user`, any `become_flags` the method needs, and where these live (group_vars vs play vs CLI) so they're scoped correctly. 3. **Password handling**: if the method prompts, recommend `--ask-become-pass` for interactive runs or a vaulted `ansible_become_password` for automation — never a plaintext password in inventory. 4. **Privilege scope**: confirm the escalation grants only what the tasks need; flag any task escalating to root that doesn't need to. 5. **Failure behavior**: describe how this method fails (wrong password, missing rule, prompt mismatch) and how to read the error. 6. **Verification**: give a one-task test (`ansible -b -m command -a 'id'`) to confirm escalation works as expected before running the real playbook. Fill in: - Host class and OS: [DESCRIBE] - Escalation tools available / mandated: [sudo / doas / pbrun / su / machinectl] - Passwordless allowed?: [yes/no] - Target privileged user: [root / service account] Output format: the recommended `become` config (method, user, flags) with where each setting lives, the password-handling approach, a privilege-scope note, and the verification command. Do not store become passwords in plaintext inventory. Recommend Ansible Vault or `--ask-become-pass`, verify with a single `id` command first, and escalate only to the user the tasks actually require.
Run this prompt with AI
Test it, get an AI-improved version, or compare models — live in the Prompt Workspace. No copy-paste.
Why this prompt works
Most teams conflate become with sudo and never think about it again, which works fine until they hit a host where sudo is not the answer — a BSD-leaning box running doas, an environment that mandates PowerBroker’s pbrun for audit reasons, or a systemd container where machinectl is the clean path in. Each method has its own flags, its own prompt behavior, and its own failure modes, and getting them wrong produces confusing escalation errors that look like authentication bugs. This prompt makes the method choice explicit and justified against the actual constraints rather than defaulting to sudo and hoping.
Password handling is where privilege escalation most often turns into a security incident. The temptation is to drop ansible_become_password straight into inventory or group_vars so automation runs unattended, but that plaintext value is a root-equivalent credential sitting in a repo. The prompt refuses that path, steering interactive runs to --ask-become-pass and automation to a vaulted variable, which keeps the convenience without the exposure.
The least-privilege step is the quiet win. It is easy to set become_user: root everywhere and move on, but every task that escalates to root widens both the blast radius and the audit scope. By asking which user each task actually needs and flagging unnecessary root escalation, the prompt keeps privilege scoped to the work. The single id verification before the real run closes the loop, confirming escalation behaves as expected on a representative host before the playbook touches anything important.
Related prompts
-
Ansible Secret Leak Audit Prompt
Scan a playbook/role for secrets that could leak into logs or output and produce a prioritized fix list using no_log, vault, and safe logging patterns.
-
Ansible AWX Job Template and Survey Design Prompt
Design AWX/Tower job templates, surveys, and credential scoping so self-service runs are safe, least-privilege, and can't be turned into arbitrary code execution by survey input.
-
Design an Ansible Vault Secrets Workflow Prompt
Set up a clean Ansible Vault workflow — encrypting secrets, separating vaulted vars, vault IDs per environment, and CI integration — without leaking plaintext or breaking diffs.
-
Ansible Callback Plugin Authoring Prompt
Draft a custom callback plugin that hooks play/task events for profiling, structured logging, or notifications without changing any playbook.
More Ansible prompts & error guides
Browse every Ansible prompt and troubleshooting guide in one place.
Reading prompts? Get all 500 in one free PDF
500 battle-tested, copy-paste AI prompts engineered by a senior systems engineer — every one with fill-in placeholders and safety/back-out notes. Drop your email and it's yours.
- 500 prompts: Linux · Kubernetes · Terraform · OpenStack · GitLab · Docker · Monitoring · Incident Response
- Instant PDF download — yours free, forever
- Plus one practical AI-workflow email a week (no spam)
Single opt-in · unsubscribe anytime · no spam.