Manage task execution and roles →easyMultiple Choice

EX294 Manage task execution and roles Practice Question

Exhibit

---
- hosts: dbservers
  tasks:
    - name: Create postgres user
      user:
        name: postgres
        state: present
      become: yes
      become_user: postgres
      become_method: sudo

Error: 

fatal: [server1]: FAILED! => {"msg": "Missing sudo password"}

Refer to the exhibit. An Ansible playbook task fails with 'Missing sudo password'. The playbook runs against a server where the remote user 'admin' has sudo privileges but requires a password. Which configuration change would resolve this issue?

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Set ansible_become_password or use the -K flag when running the playbook.

The error 'Missing sudo password' occurs because Ansible needs the sudo password for the remote user. Option A provides the password either by setting ansible_become_password in inventory or using the -K flag to prompt for it. Option B is incorrect because switching to su does not solve the password issue and is unnecessary. Option C is incorrect because removing become_user doesn't address the password requirement. Option D is incorrect because changing become_user to root doesn't provide the needed password.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✓
Set ansible_become_password or use the -K flag when running the playbook.
Why this is correct
Supplying the sudo password via `ansible_become_password` or the `-K` prompt lets Ansible satisfy the privilege-escalation credential the remote user requires. The stem's constraint is that `admin` holds sudo rights but sudo demands a password; without that secret, become fails with 'Missing sudo password'. This directly resolves it.
✗
Change become_method to su to avoid password prompts.
Why it's wrong here
Switching become_method to su does not remove the password requirement; su also prompts for the target account's credentials, so the task still fails. become_method selects the escalation binary, not credential provisioning. su is chosen on hosts where sudo is unavailable but su is permitted, which this scenario does not describe.
✗
Remove the become_user line and rely on default root.
Why it's wrong here
Removing become_user does not supply the sudo password; privilege escalation still fails because the remote user's sudoers entry demands authentication. The default become_user is already root, so this changes nothing. become_user is only relevant when escalating to a non-root account, such as deploying files owned by a service user.
✗
Change become_user to root.
Why it's wrong here
Setting become_user to root leaves the sudo password prompt unresolved; root is already the default, so the missing credential remains the blocker. become_user selects the target account after escalation, not the authentication method. It matters when tasks must run as a specific non-root user, not when supplying a password.

Visual reference

Go deeper

EX294 Manage task execution and roles Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question