Manage automation security and operations practice questions

Vault-encrypt the variable in the playbook and reference it with {{ vault_var }}.

Why it fails: Vault encryption protects the value at rest but does not hide it from job output when passed as an extra variable.

Create a custom credential type that injects the token as an environment variable, and remove the extra variable from the job template.

Why it fails: This is a good practice but does not address the existing extra variable; the token would still be visible if the extra variable remains.

Store the token in a file on the controller with 600 permissions and use 'lookup' in the playbook.

Why it fails: This does not prevent the token from being displayed in job output if it is used as a variable without no_log.

Increase the 'retries' parameter for each task.

Why it fails: Task retries re-run a failed task after it has already timed out, so the underlying connection timeout still occurs and the job remains unreliable. It is tempting because retries genuinely help with transient, one-off failures such as a momentarily unreachable host, rather than sustained high-latency WAN conditions.

Increase the 'forks' value in ansible.cfg to 50.

Why it fails: Raising forks increases parallel task execution, which multiplies concurrent connections and can worsen timeouts on a high-latency WAN rather than reduce them. It is tempting because forks is the standard tuning knob for speeding up large inventories against responsive, low-latency targets where parallelism is the bottleneck.

Set 'async: 600' and 'poll: 10' in the playbook.

Why it fails: Async with polling detaches the task and checks back periodically, but the initial connection still uses the same SSH timeout, so timeouts persist. It is tempting because async is the correct choice for long-running tasks that would otherwise exceed the connection timeout, not for slow connection establishment.

Use an inventory that contains only the allowed hosts.

Why it fails: Inventory does not restrict which playbooks can be run.

Configure an execution environment that mounts the authorized directory as read-only.

Why it fails: Execution environments provide runtime dependencies, not execution path restrictions.

Assign the service account a machine credential that connects to the controller via SSH.

Why it fails: Machine credentials provide authentication, not path restrictions.

The remote user specified in the credential does not have sudo access.

Why it fails: Incorrect. Missing sudo access would cause a privilege escalation failure (e.g., 'Permission denied' or 'Missing sudo password'), not an 'UNREACHABLE' status. The host would still be reachable.

The custom execution environment is missing the 'python3' or 'python' package.

Why it fails: Incorrect. Missing 'python3' or 'python' on the managed node would cause a module execution failure (e.g., 'FAILED! => {"msg": "...python in path..."}'), not an 'UNREACHABLE' status. The ping module itself does not require Python on the remote host; it uses raw SSH.

The automation controller is behind a firewall that blocks SSH.

Why it fails: Incorrect. If a firewall blocked SSH, the administrator would not have verified SSH connectivity. Since SSH is reachable, this is not the cause.

Set 'stdout_callback = actionable' in ansible.cfg.

Why it fails: This changes callback but does not hide sensitive data.

Use 'name: "Sensitive task"' but keep the task body visible.

Why it fails: The task name does not hide output.

Add 'display_args_to_stdout = false' to the execution environment's ansible.cfg.

Why it fails: This is not a valid Ansible configuration option. There is no 'display_args_to_stdout' setting in ansible.cfg. The only mechanism to hide sensitive data is 'no_log'.

Use 'tags: never' on sensitive tasks.

Why it fails: Tags control task execution, not output visibility.

Use a custom execution environment that writes artifacts to a network share.

Why it fails: Network shares could be in another region, violating the policy.

Configure automation mesh to route jobs to the nearest execution node.

Why it fails: Mesh routing does not control artifact storage location.

Remove the 'env' task from the playbook and ensure no other tasks print environment variables.

Why it fails: 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 fails: 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 fails: The built-in vault password credential type still injects the password as a variable that can be printed if not protected.

The 'become' privilege escalation is not configured, so the tasks cannot modify system files.

Why it fails: Without become, tasks run as the connecting user and cannot write /etc/ssh/sshd_config or change SELinux, so they would report failed or changed, not changed=0. It is tempting because privilege escalation is genuinely required for system-level configuration, and omitting it would be the cause if tasks errored on permissions.

The playbook was run with the '--check' flag, which simulates changes without applying them.

Why it fails: Check mode reports what would change, so a compliant run still shows changed counts rather than changed=0, and it never writes files. It is tempting because check mode genuinely prevents modifications, and would explain untouched servers if the playbook had been run that way.

The Ansible modules used in the role are not installed on the control node.

Why it fails: Modules execute on managed nodes, not the control node; missing control-node copies would cause task failures, not silent changed=0. It is tempting because module availability does matter, and missing collections on the control node would be the cause if tasks failed to resolve.

ls: Displays file contents

Why it fails: Incorrect — ls lists directory contents, not file contents. The command to display file contents is cat.

cp: Moves files

Why it fails: Incorrect — cp copies files; the command to move files is mv.

The playbook lacks a hosts line

Why it fails: Missing hosts causes a different error.

The become directive is misspelled

Why it fails: The correct attribute name is 'become', not misspelling.

become is allowed only in tasks, not plays

Why it fails: become can be set at play level.

Add the 'ignore_errors: yes' directive

Why it fails: ignore_errors lets the task continue after failure, masking the undefined variable rather than tracing its origin; the play still cannot resolve the value. It is tempting as a quick way to keep a playbook running, and would be correct when a task's failure is genuinely non-critical and later tasks must still execute.

Set environment variable ANSIBLE_DEBUG=1

Why it fails: ANSIBLE_DEBUG=1 dumps low-level connection and module execution detail, not variable provenance, so it will not reveal where the undefined variable was defined or expected. It is tempting because it is Ansible's general troubleshooting switch, and it would be the right choice when diagnosing SSH, privilege escalation or module invocation failures.

Use the --syntax-check flag

Why it fails: --syntax-check only parses playbook YAML and module arguments; it does not execute tasks, so an undefined variable surfaces at runtime, not during the check. It suits catching indentation or malformed syntax before a run. Registering variables or using debug with var, or -vvv, reveals the variable's source.

The forks parameter in the playbook

Why it fails: Forks controls parallel tasks, not jobs.

The job template's 'allow simultaneous' option

Why it fails: Controls concurrent runs of the same template.

The number of execution environments

Why it fails: Execution environments are not a job throttle.

validate_certs

Why it fails: Controls SSL certificate validation, not timeout.

retries

Why it fails: Used in loop retry, not connection timeout.

delay

Why it fails: Used in loop delays, not timeout.

Ansible Log Forwarder

Why it fails: No such standard component.

Custom callback plugin

Why it fails: Custom plugins are possible but not the standard method.

rsyslog configuration

Why it fails: Possible but not the intended integration.

The playbook ran against all hosts in the default inventory

Why it fails: No inventory was parsed, so no default inventory used.

The playbook used the implicit localhost but it does not match 'all', causing no tasks to run

Why it fails: Tasks did run on localhost despite the warning.

The playbook failed because no hosts matched

Why it fails: Playbook ran successfully on localhost.

The playbook syntax is incorrect

Why it fails: Syntax errors are caught before task execution.

The SSH port is blocked

Why it fails: Would produce 'Connection refused' or timeout.

The remote host is unreachable

Why it fails: Would give 'Connection timed out'.

The inventory source is empty

Why it fails: Job starts but may fail with no hosts.

The user is a system auditor

Why it fails: Auditors can have launch permissions.

The execution environment image tag is 'latest'

Why it fails: Tag 'latest' is acceptable.

Store the password as a plain text variable in the playbook and use the no_log: yes directive to prevent logging.

Why it fails: no_log only suppresses task output in logs and console; the variable stays plain text in the playbook file, so encryption at rest is absent. It is tempting because no_log genuinely prevents secret leakage into Ansible output, but it does nothing for storage; ansible-vault encrypts the file itself.

Store the password in an unprotected external file and reference it with include_vars.

Why it fails: include_vars loads a file as plain text, so the password remains readable at rest and the encryption-at-rest requirement is unmet. It is tempting because include_vars is the right mechanism for separating variables from playbooks, but it provides no encryption; ansible-vault encrypts the file instead.

Save the password in an environment variable and access it via lookup('env','DB_PASS').

Why it fails: An environment variable holds the password as plain text in the shell or process environment, so it is not encrypted at rest. It is tempting because lookup('env',...) cleanly injects secrets at runtime, but the value must already exist unencrypted; ansible-vault encrypts the source file instead.

Use a lookup plugin to fetch the password from an external secrets manager.

Why it fails: While valid, it requires additional infrastructure configuration and is not the simplest approach in this scenario.

Store the password as a variable in the project repository and encrypt it with ansible-vault.

Why it fails: Vault encryption is static; re-encryption needed when password changes.

Create a custom credential type that prompts for the password each launch.

Why it fails: Custom credential types do not prompt; they store static values.

Create a single credential that covers all three environments.

Why it fails: A single credential cannot cover different contexts (machine, network, cloud).

Define credential validation rules in the workflow node properties.

Why it fails: No such feature exists in automation controller.

Assign all three credentials to the workflow template directly.

Why it fails: Workflow templates do not store credentials; credentials are assigned to job templates.