If you have the become Boolean set to true (or yes) in the privilege_escalation section of your Ansible configuration file, then all plays in your playbook use privilege escalation by default. Those plays use the current value of become_method to change to the user specified by the become_user directive when running on the managed hosts.

You can also override the configuration file and specify privilege escalation settings when you run the playbook by using command-line options. The following table compares configuration directives and command-line options:

When you write a playbook, you might need privilege escalation for some plays but not for all plays. You can specify which plays should use privilege escalation. If the play does not specify to use privilege escalation, the default setting from the configuration file or the command line is used.

The following playbook contains three plays. The first play uses become: true to use privilege escalation no matter what the configuration file or command-line options specify. The second play uses become: false to not use privilege escalation, even if the configuration file or command-line options are specified. The third play does not have a become directive and uses privilege escalation based on the default settings from the Ansible configuration file or the command line. The ansible_user_id variable displays the name of the user on the managed host running the current play.

---
- name: Become the user "manager"
  hosts: webservers
  become: true
  tasks:
    - name: Show the user used by this play
      ansible.builtin.debug:
        var: ansible_user_id

- name: Do not use privilege escalation
  hosts: webservers
  become: false
  tasks:
    - name: Show the user used by this play
      ansible.builtin.debug:
        var: ansible_user_id

- name: Use privilege escalation based on defaults
  hosts: webservers
  tasks:
    - name: Show the user used by this play
      ansible.builtin.debug:
        var: ansible_user_id

To ensure that privilege escalation is used correctly by your play, specify the setting explicitly in the playbook. Specifying the escalation method or privileged user in configuration settings or inventory variables might be necessary depending on the task or the hosts in question.

You can enable or disable privilege escalation for specific tasks in a play. To do this, add the appropriate become directive to the task.

---
- name: Play with two tasks, one uses privilege escalation
  hosts: all
  become: false
  tasks:
    - name: This task needs privileges
      ansible.builtin.yum:
        name: perl
        state: installed
      become: true

    - name: This task does not need privileges
      ansible.builtin.shell: perl -v
      register: perlcheck
      failed_when: perlcheck.rc != 0

In the preceding example, the play has privilege escalation disabled by default, but the first task uses privilege escalation.

If you have a subset of tasks in your play that require (or do not require) privilege escalation, you can set become on a block. All tasks in the block share the same privilege escalation setting, which overrides the setting made at the play level. The following examples illustrate things you can do with this mechanism:

To use this option, add the necessary directives to the block dictionary. In the following example, the playbook contains one play that has privilege escalation turned off by default. The play consists of a block (containing two tasks) and a separate task. The tasks in the block use privilege escalation, even though it is off by default for the play. The final task does not use privilege escalation because it is outside of the block.

---
- name: Deploy web services
  hosts: webservers
  become: false
  tasks:

    - name: Tasks that need privilege escalation
      block:
        - name: Ensure httpd is installed
          ansible.builtin.yum:
            name: httpd
            state: installed
        - name: Start and enable webserver
          ansible.builtin.service:
            name: httpd
            state: started
            enabled: true
      become: true

    - name: Test website from itself, do not become
      ansible.builtin.uri:
        url: http://{{ ansible_host }}
        return_content: true
      register: webpage
      failed_when: webpage.status != 200

You can use either of the following methods to perform privilege escalation:

Alternatively, you can set the privilege escalation settings on the play that calls the role. You can also adjust these settings on individual roles, just like you can on individual tasks or blocks:

- name: Example play with one role
  hosts: localhost
  roles:
    - role: role-name
      become: true

You can also use connection variables to configure privilege escalation. Apply these connection variables as inventory variables on groups or individual hosts. The following table compares playbook and configuration directives with connection variable names:

You can use host-based or group-based connection variables such as ansible_become, ansible_become_method, ansible_become_user, and ansible_become_pass to override privilege escalation settings for individual hosts or groups that you originally set as configuration or playbook directives such as become, become_method, become_user, and become_pass.

The following example demonstrates configuring privilege escalation variables in a YAML inventory for a group:

webservers:
  hosts:
    servera.lab.example.com:
    serverb.lab.example.com:
  vars:
    ansible_become: true

You can set connection variables for privilege escalation at the host level. Doing this on a per-host basis is tedious, but can be helpful if one host in a larger group needs specific connection options. The following example demonstrates configuring privilege escalation by using connection variables at the host level:

webservers:
  hosts:
    servera.lab.example.com:
      ansible_become: true
    serverb.lab.example.com:

You can also set connection variables in the playbook; for example, on the play itself. This overrides the inventory variables (through normal variable precedence) and the setting of any become directives.

---
- name: Example play using connection variables
  hosts: webservers
  vars:
    ansible_become: true
  tasks:
    - name: Play will use privilege escalation even if inventory says no
      ansible.builtin.yum:
        name: perl
        state: installed