Ansible Vault and Secrets Management Flashcards

What is the recommended project structure for organizing Ansible Vault-encrypted variable files in a role-based project?

Answer: Store encrypted secrets in group_vars//vault.yml and plaintext variables in group_vars//vars.yml

Separating vault-encrypted variables (vault.yml) from plaintext variables (vars.yml) within group_vars enables partial file visibility and cleaner version control diffs.

How do you encrypt a single string value using ansible-vault for embedding in a variable file?

Answer: ansible-vault encrypt_string 'mypassword' --name 'db_password'

'ansible-vault encrypt_string' generates a vault-encrypted YAML variable definition that can be pasted directly into a variable file.

In a CI/CD pipeline, what is the most secure method to provide Ansible Vault passwords?

Answer: Inject the vault password as an environment variable (ANSIBLE_VAULT_PASSWORD) or a CI/CD secret that is written to a temp file at runtime

CI/CD secret management systems (Jenkins credentials, GitLab CI variables, GitHub Actions secrets) securely inject the vault password without storing it in code.

What ansible.cfg setting specifies the default vault password file location?

Answer: vault_password_file = /path/to/.vault-pass

The 'vault_password_file' setting in ansible.cfg's [defaults] section sets the default vault password file, eliminating the need to specify --vault-password-file on every command.

How does Ansible Vault handle files that contain both encrypted and unencrypted content?

Answer: Individual variables can be vault-encrypted inline using '!vault' YAML tags while the rest of the file remains plaintext

Using 'ansible-vault encrypt_string' generates '!vault' tagged values that can coexist with plaintext variables in the same YAML file.

What is the purpose of the 'ansible-vault encrypt_string' command's '--stdin-name' option?

Answer: It reads the secret value from stdin rather than as a command-line argument, preventing the secret from appearing in shell history

Reading sensitive values from stdin (rather than command-line arguments) prevents the secret from being logged in shell history, process listings, and audit logs.