EX294 Manage inventories and credentials Practice Question
A junior admin is troubleshooting why a job template fails with 'Permission denied' when connecting to a target host. The job template uses a machine credential that appears correct. What is the first thing to check?
⚠ Common exam trap
Candidates often confuse 'Permission denied' with a network or inventory issue, leading them to check the inventory or project sync instead of the credential's authentication details.
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
✓
Check the credential's username and private key / password
The error 'Permission denied' during SSH connection to a target host indicates an authentication failure. Since the machine credential appears correct, the most immediate cause is that the username or private key/password stored in the credential is incorrect or mismatched. This is the first thing to check because the credential directly controls authentication to the target host.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Verify the inventory contains the correct host IP
Why it's wrong here
An incorrect host IP yields connection timeouts or unreachable-host errors, not 'Permission denied', which indicates the SSH credential was rejected after reaching the host. Verifying inventory addresses is the right first step when jobs fail with unreachable or connection-refused errors instead.
- ✓
Check the credential's username and private key / password
Why this is correct
A 'Permission denied' error during connection typically stems from an invalid credential, so verifying the username and private key or password is the first check. The credential may appear correct while containing a mismatched key or wrong user.
- ✗
Check the vault credential used in the job template
Why it's wrong here
Vault credentials decrypt secrets inside playbooks at runtime; they do not authenticate the SSH connection, so a vault problem surfaces as decryption errors, not 'Permission denied'. Checking vault credentials is correct when playbooks fail while reading encrypted variables or files.
- ✗
Check the project sync status
Why it's wrong here
Project sync status governs whether playbook content is current, not SSH authentication; a stale sync produces outdated or missing tasks, not 'Permission denied'. It is tempting because sync failures commonly break job runs, and checking it would be right when templates fail with missing roles or modules rather than credential rejection.
Go deeper
Related to this question
About these practice questions
Courseiva writes every EX294 question from scratch — 392 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or 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.