Manage automation security and operations →easyMultiple Select

EX294 Manage automation security and operations Practice Question

A systems administrator is securing Ansible automation. Which two practices help protect sensitive data in playbooks? (Choose two.)

⚠ Common exam trap

Many candidates confuse `no_log` with encryption, thinking it protects data at rest, when it only prevents output from being displayed in logs, while `ansible-vault` provides actual file-level encryption.

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

✓

Use ansible-vault to encrypt variable files.

Option A is correct because ansible-vault encrypts sensitive files such as variable files (for example, vars.yml or group_vars files), so secrets like passwords and API keys are stored in ciphertext rather than readable plain text, and they can be decrypted at runtime with a vault password. Option B is correct because setting no_log: true on a task suppresses logging of that task's command output and arguments, preventing sensitive values such as passwords or tokens from being written into Ansible logs or console output. Option C is incorrect because using the debug module with increased verbosity would print sensitive values such as passwords to output, which is the opposite of protecting them. Option D is incorrect because avoiding become: yes does not protect secrets; privilege escalation is unrelated to whether sensitive data is encrypted or hidden, and become is often legitimately needed for secure tasks. Option E is incorrect because storing credentials in plain text in the inventory exposes them directly and is a classic insecure practice, not a protection measure.

Answer analysis

Option-by-option breakdown

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

✓
Use ansible-vault to encrypt variable files.
Why this is correct
Encrypting variable files with ansible-vault protects sensitive data at rest, satisfying the requirement to secure credentials within playbooks. Vault-encrypted files remain usable during execution once the vault password is supplied, so secrets are never stored in plaintext in the repository or on disk.
✓
Set the no_log flag on tasks that handle sensitive data.
Why this is correct
Setting `no_log: true` suppresses task output, preventing sensitive values from being written to Ansible logs, console output, or callback plugin records. This directly satisfies the stem's requirement to protect sensitive data during playbook execution, since credentials and secrets handled by those tasks would otherwise be exposed in plain text.
✗
Use the debug module with verbosity to output passwords.
Why it's wrong here
Verbose debug output writes task variables, including passwords, into plaintext logs and console history, exposing the very secrets the playbook should conceal. It is tempting because debug with verbosity is genuinely useful for troubleshooting variable values and task flow during development, but never for secret-bearing tasks.
✗
Avoid using become: yes on tasks that access secrets.
Why it's wrong here
Privilege escalation is orthogonal to secret protection: become controls which remote user runs a task, not whether vault-encrypted variables or no_log keep credentials out of logs. It is tempting because least privilege is a real hardening aim, but it belongs to access control, not to protecting sensitive data in playbooks.
✗
Store credentials in plain text in the inventory.
Why it's wrong here
Plaintext inventory credentials are readable by anyone with file access, so they cannot protect sensitive data. It is tempting because a static inventory is the quickest way to define hosts and connection variables, and it would be acceptable only in a disposable lab with no real secrets.

Go deeper

EX294 Manage automation security and operations Practice Question

Why each option matters

Option-by-option breakdown

Related to this question