Using no_log to Prevent Secret Exposure in Ansible Automation Controller Logs
You are managing an Ansible Automation Platform deployment that uses automation mesh with one control node and two execution nodes. The control node is in the DMZ, and the execution nodes are in a private network. The organization's security policy requires that all secrets (e.g., SSH keys, API tokens) be encrypted at rest and never transmitted in plaintext. You have configured vault-encrypted credentials and set the vault password as a credential on the control node. However, a recent audit reveals that when a job runs, the vault password is visible in the job output on the execution nodes. The execution nodes are configured to stream job events back to the control node. The automation controller version is 4.3. The following settings are in place: 'no_log' is not set for any variables; the vault password is stored as a 'Vault password' credential type. The job template uses a custom credential type that injects the vault password as an environment variable. The execution nodes have access to the vault password via that environment variable. The audit shows the environment variable is printed in the job output because the playbook uses the 'env' module to display environment variables for debugging. You must prevent the vault password from appearing in any job output without breaking the ability to decrypt vault-encrypted variables. Which action should you take?
Quick Answer
Setting no_log: true on the environment variable injection in the custom credential type is correct because it addresses the actual mechanism causing the leak: the vault password reaches the execution node as an environment variable, and the audit found it being printed by the env module during a debugging step. no_log does not stop the variable from existing or being used - the playbook can still read that environment variable to decrypt vault-encrypted content - it only prevents Ansible from writing that variable's value into the job output or logs, which is precisely the gap the audit identified. This is worth contrasting with more drastic fixes like removing the credential type or blocking the env module entirely, both of which would either break decryption or just remove one way of exposing the secret while leaving others open; no_log is targeted at the injection point itself, so it closes the leak regardless of how a task might later try to display environment variables. When a scenario describes a secret that is correctly encrypted or securely stored but still shows up somewhere it should not in output or logs, the fix is almost always to apply no_log at the specific point where that value is injected or displayed, not to change how the secret is stored in the first place.
⚠ Common exam trap
Candidates often think removing the debugging task (Option A) is sufficient, but they miss that the underlying issue is the credential injection method, and that `no_log` is the proper way to prevent secret exposure in Ansible Automation Platform.
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
✓
Edit the custom credential type's input injection to set 'no_log: true' for the environment variable that carries the vault password.
Setting `no_log: true` on the environment variable injection in the custom credential type prevents Ansible from logging the value of that variable in job output, while still allowing the vault password to be used by the playbook to decrypt vault-encrypted variables. This directly addresses the audit finding without removing debugging capabilities or changing the credential type.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Remove the 'env' task from the playbook and ensure no other tasks print environment variables.
Why it's wrong here
This does not prevent future accidental exposure; the root cause is lack of no_log on the credential type.
- ✗
Configure the automation controller's 'Settings' to enable 'Display secrets' = false.
Why it's wrong here
There is no such global setting; secrets are hidden only if no_log is set on the specific variable.
- ✗
Change the custom credential type to use the built-in 'Vault password' credential type and remove the custom credential type.
Why it's wrong here
The built-in vault password credential type still injects the password as a variable that can be printed if not protected.
- ✓
Edit the custom credential type's input injection to set 'no_log: true' for the environment variable that carries the vault password.
Why this is correct
This ensures the vault password is never displayed in job output, while still being available for vault decryption.
Go deeper
Related to this question
About these practice questions
This EX294 question is part of Courseiva's 520-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 →
Same concept, more angles
1 more way this is tested on EX294
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. An Ansible automation controller job template uses a custom credential type that requires a secret token. The token is stored as an extra variable in the job template definition. A security audit reveals the token is visible in plaintext in the job output. Which action should the administrator take to secure the secret?
medium- ✓ A.Define the variable in the job template's 'extra variables' field with 'no_log: true' set in the playbook for that variable.
- B.Vault-encrypt the variable in the playbook and reference it with {{ vault_var }}.
- C.Create a custom credential type that injects the token as an environment variable, and remove the extra variable from the job template.
- D.Store the token in a file on the controller with 600 permissions and use 'lookup' in the playbook.
Why A: Setting `no_log: true` on the variable in the playbook prevents Ansible from printing the value of that variable in any output, including job logs. This is the standard method to hide sensitive data like tokens when they are passed as extra variables, as it works at the task level to suppress logging of the variable's content.
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.