How can a play set its own remote user and privilege escalation, independent of ansible.cfg?

With play keywords: remote_user: automation sets the login user and become: yes (or true) turns escalation to root on, no/false turns it off, overriding whatever ansible.cfg says.

- name: /etc/hosts is up to date
  hosts: datacenter-west
  remote_user: automation
  become: yes
  tasks:
    - name: server.example.com in /etc/hosts
      lineinfile:
        path: /etc/hosts
        line: '192.0.2.42 server.example.com server'
        state: present

Configuration in ansible.cfg is a project-wide default. Some plays need something else: editing /etc/hosts needs root, while a play that only reads data shouldn't escalate at all. Putting remote_user and become in the play keeps that requirement next to the tasks that need it, so the playbook works the same no matter which ansible.cfg a colleague has. The same keywords also exist at task level for even finer control, for example become: true on just the one task that installs a package.

The order of precedence runs from general to specific: config file, then play, then task.

Go deeper:

• Understanding privilege escalation: become (official docs) — become at play and task level, and how it overrides config.
• lineinfile module (official docs) — the module used in this play.