become, become_user and become_method

Back in the very first installation chapter, alice and bob were configured with passwordless sudo access. This course has relied on that setup silently ever since — every package install, every write to /etc/, every service restart needed elevated privileges to actually work. This chapter finally names the mechanism that’s been making all of that possible.

Why This Has Been Working All Along

Any task touching something outside alice’s own ordinary permissions — installing a package, restarting a system service, writing to a root-owned directory — needs privilege escalation to succeed at all. become: true is that mechanism, and it’s been implicitly necessary in a good number of this course’s own earlier examples, even where it wasn’t always shown explicitly for focus.

become: true: Requesting Elevated Privileges

- name: Install a package (requires root)
  ansible.builtin.apt:
    name: curl
    state: present
  become: true

Without become: true, this task runs as whatever ansible_user connects as — alice, in our lab — who doesn’t have permission to install packages directly. become: true escalates privileges, by default to root, before this specific task actually runs.

become_user: Escalating To A Specific Account, Not Just Root

The default escalation target is root, but become_user redirects it to a different specific account:

- name: Run a command as a different user
  ansible.builtin.command: whoami
  become: true
  become_user: bob

Genuinely useful when a task should run as a dedicated service account — a database’s or an application’s own user — rather than root specifically. Running as root when you only need bob’s permissions is more access than the task actually needs, a theme this section returns to directly later.

become_method: How The Escalation Actually Happens

become_method controls which underlying mechanism performs the escalation. sudo is the default, matching this course’s entire lab setup — alternatives (su, doas, and others) exist for less common environments:

- name: Escalate using su instead of sudo
  ansible.builtin.command: whoami
  become: true
  become_method: su

sudo is overwhelmingly the standard choice on Linux, and this course’s examples stick with the default throughout.

Setting become At Different Levels

Task-level, as shown above, or on a whole block (applying to every task inside it, the same propagation behavior established for other block-level keywords), or on an entire play:

- name: My Play
  hosts: servers
  become: true
  tasks:
    - name: Task one
      ansible.builtin.debug:
        msg: "..."

Every task in this play now escalates — often more than necessary, a point this section’s closing chapter argues directly.

A Realistic Example

become: true applied selectively, only where it’s genuinely needed:

- name: Install myapp
  ansible.builtin.package:
    name: myapp
    state: present
  become: true

- name: Deploy config (owned by alice, doesn't need root)
  ansible.builtin.template:
    src: app.conf.j2
    dest: /home/alice/app.conf

- name: Restart service
  ansible.builtin.systemd:
    name: myapp
    state: restarted
  become: true

The package install and service restart genuinely need root; the config deployment, writing to alice’s own home directory, doesn’t.

Best Practices

• Use become: true specifically on tasks that genuinely need elevated privileges, not by default on an entire play.
• Use become_user when a task should run as a specific non-root account, rather than escalating all the way to root unnecessarily.
• Stick with the default become_method (sudo) unless your specific environment genuinely requires an alternative.