easyMultiple Choice

200-901 Practice Question: Uses Ansible for configuration management and…

An organization uses Ansible for configuration management and wants to secure the automation secrets (e.g., SSH keys, API tokens). The secrets are currently stored in plaintext in inventory files. The security team requires that secrets be encrypted at rest and decrypted only at runtime by authorized users. Which solution should be implemented?

⚠ Common exam trap

Cisco often tests the distinction between access control (file permissions) and encryption at rest, leading candidates to mistakenly choose strict permissions as sufficient for securing secrets, when encryption is required to protect data from unauthorized access even if the file system is compromised.

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 sensitive variables in the inventory files

Ansible Vault is the built-in tool for encrypting sensitive data such as passwords, API tokens, and SSH keys at rest. It encrypts variables or entire files using AES-256, and decryption occurs only at runtime when the correct vault password is provided, meeting the requirement that secrets are decrypted only by authorized users.

Answer analysis

Option-by-option breakdown

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

✗
Store secrets in an encrypted SSH key file and use it for authentication
Why it's wrong here
An encrypted SSH key file protects only that one key, not API tokens or other secrets, and Ansible cannot decrypt arbitrary variables from it at runtime. It is tempting because SSH keys are themselves secrets, but this suits host authentication, not encrypting inventory variables.
✗
Set strict file permissions (0600) on the inventory files to limit access
Why it's wrong here
File permissions restrict who may read the plaintext inventory, but the secrets remain unencrypted at rest, failing the stated requirement. It is tempting because 0600 is a genuine hardening step, and would be correct for limiting local access to a file that is already encrypted.
✗
Use environment variables to pass secrets at runtime
Why it's wrong here
Environment variables hold secrets in plaintext in the process environment and shell history, so they are not encrypted at rest — the stated requirement. They suit ephemeral CI runners where a vault injects values, but here Ansible Vault encrypts secret files and decrypts them at runtime.
✓
Use Ansible Vault to encrypt sensitive variables in the inventory files
Why this is correct
Ansible Vault encrypts variables and files with AES-256, requiring a password or vault-password-file to decrypt at playbook runtime. This satisfies the encryption-at-rest and runtime-decryption constraints, replacing the plaintext inventory secrets while restricting decryption to authorised users holding the vault password.

Quick reference

Symmetric Encryption Algorithm Comparison

Algorithm	Key Size	Block Size	Status	Notes
AES-128	128-bit	128-bit	Current standard	NIST approved; WPA3, TLS
AES-256	256-bit	128-bit	Current standard	Preferred for sensitive / govt data
3DES	112-bit effective	64-bit	Deprecated (2023)	Replaced by AES
DES	56-bit	64-bit	Broken	Cracked in < 24 h; never deploy
ChaCha20	256-bit	Stream cipher	Current	TLS 1.3, WireGuard

Go deeper

200-901 Practice Question: Uses Ansible for configuration management and…

Why each option matters

Option-by-option breakdown

Symmetric Encryption Algorithm Comparison

Related to this question