EX294 Deploy Ansible Automation Platform Practice Question
A job template runs successfully on some hosts but fails on others with 'Permission denied' for the same task. The admin has verified that the credential is correct. What is the most likely cause?
⚠ Common exam trap
Many exam-takers assume 'Permission denied' always means an SSH key or credential issue, overlooking that privilege escalation (become) is a separate step that can fail even when the initial SSH connection succeeds.
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
✓
The privilege escalation method (become method) differs among hosts.
B is correct because the 'Permission denied' error on a task that runs successfully on some hosts but not others, despite a verified credential, typically indicates a privilege escalation issue. The become method (e.g., sudo, su, pbrun) may be configured differently or unsupported on the failing hosts, causing Ansible to fail when attempting to escalate privileges for the task. Since the credential is correct, the failure occurs during the become process, not authentication.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The package repository is not accessible from those hosts.
Why it's wrong here
Repository reachability governs package installation tasks, not SSH authentication; an unreachable repo yields dnf or yum errors, never 'Permission denied'. It is tempting because connectivity faults do break playbooks on subsets of hosts, and fixing repo access would be correct when a package task fails with a fetch or timeout error.
- ✓
The privilege escalation method (become method) differs among hosts.
Why this is correct
Differing become methods across hosts break privilege escalation: sudo, su and doas require distinct configuration and password handling, so a task succeeding where sudo is configured fails elsewhere with 'Permission denied' despite valid credentials. Aligning the become method with each host's available escalation tooling resolves the inconsistency.
- ✗
The credential's username is incorrect for some hosts.
Why it's wrong here
The stem states the credential is correct, so its username already matches every managed host; a wrong username would fail uniformly, not selectively. It is tempting because username mismatches do cause 'Permission denied' on SSH, and correcting the credential's username would be the right fix if authentication failed everywhere.
- ✗
The SSH key is not accepted on some hosts.
Why it's wrong here
The error is 'Permission denied' not 'Authentication failed', and credential uses password.
Go deeper
Related to this question
About these practice questions
This EX294 question is part of Courseiva's 392-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This EX294 practice question is part of Courseiva's free Red Hat certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the EX294 exam.