Courseiva

CCNA Automation Security Ops Questions

38 questions · Automation Security Ops topic · All types, answers revealed

Practice these questionsExam hubAll questions
1
MCQmedium

An automation engineer stores a sudo password inside a project variable file that is committed to Git. The team requires that the cleartext value never appears in the repository and that playbooks still consume the variable transparently. Which approach meets this requirement?

A.Encrypt the variable file with ansible-vault encrypt and reference it from the playbook with vars_files; commit the encrypted file to Git.
B.Run ansible-vault encrypt_string on the variable and store the resulting inline value directly in group_vars/all.yml.
C.Add the variable file to .gitignore and distribute it manually to each control node's home directory before running the playbook.
D.Store the password in an environment variable on the control node and reference it with lookup('env', 'SUDO_PASS') inside the playbook.
AnswerA

Encrypting the variable file with ansible-vault encrypt keeps the plaintext password out of the Git repository while the playbook still loads the variables through vars_files at runtime, prompting for or receiving the vault password via --vault-password-file or --ask-vault-pass. This satisfies both the storage requirement and transparent consumption.

Why this answer

Ansible Vault encrypts files and individual values using AES-256 so that secrets can be safely stored in source control. Encrypting the whole variable file with ansible-vault encrypt and loading it through vars_files keeps the plaintext out of Git while playbooks still resolve the variable normally. Decryption happens at runtime using a vault password provided interactively or through a password file.

Exam trap

The trap here is assuming that .gitignore or environment variables provide equivalent protection to Ansible Vault, when only vault encryption keeps the secret usable by Ansible while remaining unreadable in the repository.

Practice this question →
2
Multi-Selectmedium

Which TWO of the following are best practices for securing automation controller secrets and credentials?

Select 2 answers
A.Store secrets in plain text in inventory files for simplicity
B.Use Ansible Vault to encrypt sensitive data like passwords and API keys
C.Disable logging to prevent exposure of sensitive data in logs
D.Use OAuth2 tokens for API authentication instead of static credentials
E.Grant all users admin access to reduce permission complexity
AnswersB, D

Ansible Vault encrypts variables and files at rest using AES-256, so passwords and API keys stored in playbooks or variable files remain unreadable without the vault password. This satisfies the requirement to protect sensitive data rather than leaving it in plaintext.

Why this answer

Option B is correct because Ansible Vault encrypts sensitive variables, passwords, and API keys at rest with AES-256, so playbooks and variable files can be safely stored in version control without exposing plaintext secrets. Option D is correct because OAuth2 tokens provide scoped, time-limited, and revocable API authentication, which is far safer than long-lived static credentials that, if leaked, grant persistent access. Option A is wrong because storing secrets in plaintext in inventory files exposes them to anyone with file or repository access.

Option C is wrong because disabling logging reduces auditability and does not actually secure secrets; instead, you should use no_log and vaulted variables to keep sensitive data out of logs. Option E is wrong because granting all users admin access violates least privilege and dramatically increases the blast radius of any compromised account.

Exam trap

Red Hat often tests the misconception that disabling logging is a valid security measure, but the correct approach is to use selective data masking with no_log rather than eliminating logs entirely, which hinders auditing and troubleshooting.

Practice this question →
3
MCQeasy

A playbook must retrieve a secret from an external vault service at runtime instead of storing it in the repository. The team wants the value available as a variable named db_password. Which Ansible feature should be used?

A.An ansible-vault encrypted file committed to the project and decrypted with a password file.
B.A fact gathered by the setup module from the managed node's /etc/shadow file.
C.A lookup plugin such as community.hashi_vault.hashi_vault referenced in a set_fact task.
D.A host variable defined in the inventory and marked with no_log on the consuming task.
AnswerC

Lookup plugins query external systems at execution time, so a HashiCorp Vault lookup can fetch db_password dynamically without persisting it in the repository. Assigning the result with set_fact makes the value available to subsequent tasks, which matches the requirement for runtime secret retrieval from an external vault service.

Why this answer

Lookup plugins execute on the control node and query external data sources during a play run, which is the supported way to pull secrets from services such as HashiCorp Vault. Assigning the lookup result to a variable with set_fact makes the secret usable by later tasks while keeping it out of the repository entirely.

Exam trap

The trap here is confusing Ansible Vault, which encrypts secrets stored in the project, with lookup plugins that retrieve secrets from an external service at run time.

Practice this question →
4
MCQhard

A Red Hat Ansible Automation Platform installation uses a custom execution environment. The playbook runs fail with 'execution environment not found'. The execution environment is stored in a private registry requiring authentication. What must be configured?

A.Set the execution_environment_image variable in the playbook
B.Configure the execution environment in the inventory
C.Add the registry URL to the automation controller's container registry credentials
D.Add the registry to the project's source control
AnswerC

The controller must authenticate to the private registry before pulling the execution environment image, so adding the registry URL and credentials under container registry credentials satisfies that constraint. Without this, image pulls fail with 'not found' despite the image existing.

Why this answer

When an execution environment is stored in a private registry that requires authentication, the automation controller must have the registry's URL and credentials configured as a container registry credential. This credential is then used by the controller to authenticate and pull the execution environment image during job runs. Without this, the controller cannot access the private registry, resulting in the 'execution environment not found' error.

Exam trap

The trap here is that candidates often confuse setting the image name (Option A) with providing registry authentication, or they mistakenly think inventory or project settings can handle container registry access, when in fact only a dedicated container registry credential in automation controller can authenticate to a private registry.

How to eliminate wrong answers

Option A is wrong because setting the execution_environment_image variable in the playbook only specifies the image name/tag, but does not provide authentication credentials for a private registry. Option B is wrong because configuring the execution environment in the inventory is not a valid method; execution environments are defined at the job template or controller level, not in inventory files. Option D is wrong because adding the registry URL to the project's source control is unrelated to container registry authentication; source control handles playbook code, not container image access.

Practice this question →
5
MCQhard

An administrator is migrating playbooks to use execution environments in automation controller. They want to ensure that all playbook runs use a custom execution environment that includes the necessary Python libraries and is signed to comply with security policy. What should the administrator do?

A.Build the execution environment using ansible-builder and then push it to a private registry and reference it in the automation controller.
B.Push the custom execution environment to the default namespace and assign it to job templates.
C.Use the default execution environment and install Python libraries via the playbook.
D.Define the execution environment in the project repository and use a pre-run hook.
AnswerA

Building with ansible-builder bundles the required Python libraries into a container image, satisfying the dependency constraint, while pushing to a private registry and referencing it in automation controller ensures every playbook run pulls that signed, policy-compliant execution environment rather than the default image.

Why this answer

The administrator must build a custom execution environment using `ansible-builder`, which packages the required Python libraries and Ansible content into a container image. This image must then be pushed to a private registry (e.g., Quay.io or Red Hat Registry) and referenced in automation controller's execution environment configuration. Additionally, signing the image (e.g., via Podman or Skopeo) ensures compliance with security policies by verifying image integrity before execution.

Exam trap

The trap here is that candidates may think they can install Python libraries dynamically via a playbook (Option C) or use a project-level definition (Option D), but the exam tests the understanding that execution environments are immutable container images built externally and referenced by registry path.

How to eliminate wrong answers

Option B is wrong because pushing the custom execution environment to the 'default namespace' is not a valid concept in automation controller; execution environments are referenced by their full registry path and tag, not by namespace assignment. Option C is wrong because using the default execution environment and installing Python libraries via a playbook violates the purpose of execution environments, which are meant to provide immutable, pre-packaged dependencies; runtime installation also breaks security policy and reproducibility. Option D is wrong because defining the execution environment in the project repository is not supported; execution environments are configured at the job template or global level in automation controller, and 'pre-run hooks' are not a mechanism for specifying execution environments.

Practice this question →
6
MCQhard

Refer to the exhibit. An administrator deployed this configuration using the controller_configuration role. After deployment, user jdoe can administer Engineering organization but cannot launch a job template within it. What is the most likely reason?

A.The admin role for organization does not include job template launch permissions
B.The user's password is vault-encrypted and cannot be decrypted
C.The user needs to be added to the job template's role specifically
D.The role assignment should be at the team level, not user level
AnswerC

Job templates carry their own role-based access control, separate from organisation-level roles. Administering the Engineering organisation grants no execute permission on its templates, so jdoe must be assigned an execute role on the specific job template to launch it.

Why this answer

In Ansible Tower/AWX, organization-level admin roles grant administrative privileges over the organization's objects (e.g., users, teams, inventories) but do not automatically confer execute permissions on specific job templates. To launch a job template, a user must have the 'execute' role on that job template itself, either directly or via a team or user role assignment. Since user jdoe can administer the Engineering organization but cannot launch a job template, the missing piece is the explicit job template role assignment.

Exam trap

Red Hat often tests the misconception that an organization admin role automatically includes all permissions on objects within the organization, when in fact job template execution requires a separate explicit role assignment.

How to eliminate wrong answers

Option A is wrong because the admin role for an organization does include the ability to manage job templates (create, modify, delete) but does not include the 'execute' permission; the question is about launching (executing) a job template, not managing it. Option B is wrong because vault-encrypted passwords are decrypted at runtime by Ansible Tower using the vault password; if the password could not be decrypted, the user would not be able to log in at all, not just fail to launch a job template. Option D is wrong because role assignments can be made at the user level as well as the team level; the issue is not the level of assignment but the specific role (execute) that is missing.

Practice this question →
7
MCQhard

An automation controller administrator needs to allow a team of developers to run playbooks that use a vault-encrypted variable file. The vault password must not be stored in the playbook repository or exposed in job output. Which approach meets the requirement?

A.Configure the job template to prompt for the vault password at launch time.
B.Set the vault password as an environment variable named ANSIBLE_VAULT_PASSWORD on the automation controller host.
C.Store the vault password in an Ansible vault credential and attach it to the job template.
D.Embed the vault password in the playbook as an encrypted variable using ansible-vault encrypt_string.
AnswerC

Automation controller supports vault credentials that securely store the vault password. When attached to a job template, the controller injects the password at runtime without exposing it in the playbook repository or job output. This is the intended secure method for supplying vault passwords to jobs.

Why this answer

Automation controller vault credentials securely store secrets and inject them into jobs without exposing them in the repository or job output. Attaching such a credential to a job template provides the vault password at runtime, enabling decryption of vaulted files while keeping the secret centralized and auditable.

Exam trap

The trap here is thinking that embedding an encrypted password in the playbook or using host environment variables is a secure way to supply a vault password to automation controller.

Practice this question →
8
Drag & Dropmedium

Drag and drop the steps to configure a container using Podman with a custom Dockerfile in the correct order.

Drag or tap steps into the slots.

Steps
Order
1Step 1
2Step 2
3Step 3
4Step 4

Why this order

Podman workflow: create Dockerfile, build image, list images, run container, verify.

Practice this question →
9
MCQmedium

A playbook must read a vault-encrypted variable file named secrets.yml and also use a vault password stored in a file named vault_pass.txt. The playbook is executed with the command `ansible-playbook site.yml --vault-password-file vault_pass.txt`. The file secrets.yml was encrypted with the same password. During execution, the task that uses a variable from secrets.yml fails with an error indicating the variable is undefined. What is the most likely reason?

A.The vault password file must be passed with --vault-id instead of --vault-password-file.
B.The vault password file must have permissions of 0600, otherwise Ansible ignores it.
C.The vault-encrypted variable file must be included with vars_files in the playbook, not merely present in the same directory.
D.The variable file must be decrypted to plaintext before it can be used in a playbook.
AnswerC

Ansible does not automatically load variable files from the playbook directory. To use variables from secrets.yml, the playbook must explicitly include it, typically via vars_files: - secrets.yml. Without that inclusion, the variables are never loaded, causing an undefined variable error even though decryption succeeds.

Why this answer

Variables from a vault-encrypted file are only available to a play if the file is explicitly loaded, commonly through vars_files or include_vars. Merely placing the encrypted file alongside the playbook and supplying the vault password does not make its variables available, so the task referencing them fails with an undefined variable error.

Exam trap

The trap here is assuming that Ansible automatically loads vault-encrypted variable files from the playbook directory once a vault password is supplied.

Practice this question →
10
MCQmedium

An Ansible playbook uses 'become: yes' to install packages. The playbook works when run manually by the administrator but fails when run from automation controller with 'Missing sudo password'. The administrator has configured a machine credential with the SSH key and the 'Become password' field is blank. What is the most likely issue?

A.The machine credential does not include the become password.
B.The become method is set to 'su' instead of 'sudo'.
C.The remote user is not in the sudoers file.
D.The SSH private key is not loaded into the automation controller.
AnswerA

With become enabled, Ansible escalates via sudo, which needs the privilege password when NOPASSWD is not configured. The blank Become password field in the machine credential leaves sudo without credentials, producing the 'Missing sudo password' error.

Why this answer

The playbook uses 'become: yes' to escalate privileges, which requires a become password when the remote user's sudo configuration demands password authentication. Since the machine credential's 'Become password' field is blank, Automation Controller cannot supply the password during the privilege escalation step, causing the 'Missing sudo password' error. The administrator's manual run succeeds because the SSH session can prompt interactively for the password, but Automation Controller's non-interactive execution requires the password to be pre-configured in the credential.

Exam trap

Red Hat often tests the distinction between SSH authentication (private key) and privilege escalation (become password) in Automation Controller, tempting candidates to focus on SSH key issues when the error clearly points to the missing become password.

How to eliminate wrong answers

Option B is wrong because the error message explicitly mentions 'sudo', and the default become method in Ansible is 'sudo'; changing to 'su' would produce a different error or require different configuration. Option C is wrong because if the remote user were not in the sudoers file, the error would typically be 'user is not in the sudoers file' or a permission denied message, not 'Missing sudo password'. Option D is wrong because the playbook runs successfully when executed manually by the administrator, proving the SSH key works; the issue is specifically with the become password, not the SSH authentication.

Practice this question →
11
MCQmedium

You are reviewing an Ansible playbook that uses the `ansible.builtin.shell` module to run a command that includes a sensitive API key as an argument. You want to prevent the API key from being displayed in the job output. Which task-level directive should you add?

A.changed_when: false
B.no_log: true
C.ignore_errors: true
D.become: true
AnswerB

The `no_log` directive, when set to true on a task, prevents Ansible from logging the task's output, including the command and its arguments. This ensures that the sensitive API key passed to the shell module is not displayed in job output. It is the correct task-level control to suppress logging of sensitive data. It works regardless of the module used, as long as it is applied to the task.

Why this answer

The `no_log: true` directive on a task suppresses all logging for that task, including the command line and its output. This prevents the sensitive API key from appearing in job output. The other directives control privilege escalation, error handling, or change reporting, none of which affect logging of task details.

Therefore, `no_log` is the correct choice.

Exam trap

The trap here is assuming that other task directives like `become` or `ignore_errors` might hide output, when only `no_log` controls logging.

Practice this question →
12
MCQmedium

A playbook must write a sensitive token to a remote managed node's /etc/app/token.conf file. The security team requires that the token never appear in plaintext in the playbook or in the controller's job output. The token is stored in an Ansible Vault-encrypted variable file. Which task implementation best meets these requirements?

A.Use the shell module with a command that echoes the token into the file and redirect the output to /dev/null.
B.Use the copy module with content: "{{ vault_token }}" and set no_log: true on the task.
C.Use the lineinfile module with line: "token={{ vault_token }}" and rely on Vault encryption alone.
D.Use the template module with a Jinja2 template that contains the token literal and add no_log: true.
AnswerB

The copy module writes the decrypted token to the managed node without exposing it in logs when no_log is true. The variable is sourced from the vault-encrypted file, so the playbook itself contains no plaintext. This satisfies both the no-plaintext-in-playbook and no-leak-in-output requirements.

Why this answer

The copy module with content and no_log: true ensures the decrypted vault variable is written to the remote file while suppressing sensitive task output. Storing the token only in the vault-encrypted file keeps the playbook free of plaintext. The other approaches either embed the secret in a template or allow the expanded token to be logged, violating the security requirements.

Exam trap

The trap here is assuming that Vault encryption alone prevents secrets from appearing in job output; it protects the variable file at rest but does not suppress task logging.

Practice this question →
13
MCQhard

A playbook that manages user accounts must run a task that passes a decrypted service account password to a command. Job output currently shows the password in the task result. Which change ensures the password is not displayed while keeping the task functional?

A.Run the playbook with --diff to show only changes and hide unchanged task output.
B.Add the password variable to a vault-encrypted file and reference it with vars_files.
C.Set display_skipped_hosts and display_ok_hosts to false in ansible.cfg.
D.Set no_log: true on the task so its output is suppressed in the job log.
AnswerD

no_log: true suppresses the task's return data, including any values that would otherwise be printed in the job output. The task still executes and returns success or failure, but the sensitive argument such as the password is masked. This is the supported Ansible mechanism for hiding task output that would otherwise expose decrypted secrets.

Why this answer

Ansible renders task return data in the job output, so any secret passed as an argument or registered value can leak. Applying no_log: true to the specific task suppresses that output while leaving the task's execution intact. This is the targeted control for hiding sensitive values at runtime, complementing vault encryption that only protects data at rest.

Exam trap

The trap here is believing that encrypting a variable with Ansible Vault also hides it at runtime, when vault only protects the file on disk and no_log is required to mask the decrypted value in job output.

Practice this question →
14
Multi-Selectmedium

An automation team must ensure that sensitive variables used in playbooks are protected both at rest and during job execution in Ansible Automation Platform. Which TWO actions should be taken? (Choose two.)

Select 2 answers
A.Store the vault password in the project repository as a plaintext file for easy access.
B.Mark tasks that use sensitive variables with no_log: true to prevent values from appearing in job output.
C.Define sensitive variables in group_vars/all in plaintext so they are available to all hosts.
D.Enable verbose logging with -vvv to capture all variable values for auditing.
E.Store sensitive variables in an Ansible Vault-encrypted file and provide the vault password through a controller credential.
AnswersB, E

The no_log: true directive suppresses task output, preventing expanded sensitive variables from being displayed in job logs. While it does not protect data at rest, it addresses runtime exposure in job output, complementing vault encryption for a complete protection strategy.

Why this answer

Encrypting sensitive variables with Ansible Vault and supplying the vault password via a controller credential protects data at rest, while no_log: true prevents runtime exposure in job output. Plaintext group_vars, verbose logging, and repository-stored vault passwords all undermine security and fail to meet the dual protection requirement.

Exam trap

The trap here is focusing only on encryption at rest and forgetting that job output can leak decrypted secrets unless no_log: true is applied to tasks handling sensitive data.

Practice this question →
15
MCQhard

After rotating the Ansible Vault password in the automation controller, several job templates that use vault credentials start failing with 'decryption failed'. The vault credential has been updated with the new password. What is the most likely cause of the failure?

A.The automation controller needs a restart to apply the new vault credential.
B.The vault file in the project repository still uses the old vault password and needs to be re-encrypted with the new password.
C.The vault credential is not linked to the job template correctly.
D.The vault credential type requires the old password to be stored separately.
AnswerB

Re-encrypting the vault file with the new password is required because Ansible Vault decrypts file contents using the password embedded at encryption time. Updating the credential in the automation controller only changes the password supplied at runtime; the repository file still carries ciphertext derived from the old password, so decryption fails until re-encrypted.

Why this answer

The vault file itself is encrypted with a specific password. When the vault password is rotated in the automation controller, the vault file stored in the project repository is still encrypted with the old password. The job template uses the vault credential to decrypt the file, but since the credential now holds the new password, decryption fails.

The vault file must be re-encrypted with the new password using `ansible-vault rekey` or by decrypting and re-encrypting it.

Exam trap

The trap here is that candidates assume updating the vault credential in the controller is sufficient, but they overlook that the vault file itself must be re-encrypted with the new password.

How to eliminate wrong answers

Option A is wrong because the automation controller does not require a restart to apply updated vault credentials; credential changes are applied dynamically to subsequent job runs. Option C is wrong because the vault credential is correctly linked to the job template (as stated in the scenario), and the failure is due to a password mismatch, not a linkage issue. Option D is wrong because the vault credential type does not require storing the old password separately; the credential simply stores the current password used for decryption.

Practice this question →
16
MCQmedium

An organization uses automation controller and has multiple teams. They want to create an inventory that automatically includes all hosts from a cloud provider that belong to the 'production' tag, and this inventory should be accessible only to the SRE team. What is the correct way to achieve this?

A.Create a smart inventory with a filter for tag 'production' and assign the SRE team the 'read' role on that inventory.
B.Create a static inventory file and restrict access via a custom script.
C.Use groups in the inventory and assign all production hosts to a group, then restrict access to that group.
D.Create a dynamic inventory plugin in each playbook and include a condition to check team membership.
AnswerA

A smart inventory applies a host filter against the existing inventory source, dynamically including only hosts tagged 'production' without manual maintenance. Assigning the SRE team the 'read' role on that inventory object enforces the access constraint, since automation controller RBAC grants visibility per inventory rather than globally.

Why this answer

A smart inventory in automation controller allows you to dynamically filter hosts from an existing source (like a cloud provider) based on criteria such as tags. By creating a smart inventory with a filter for the 'production' tag, you automatically include all matching hosts. Assigning the SRE team the 'read' role on that inventory restricts access to only that team, meeting both requirements without manual updates.

Exam trap

The trap here is that candidates confuse smart inventories with static groups or assume that playbook-level conditions can replace inventory-level RBAC, but automation controller enforces access control strictly at the inventory object level, not within playbook logic or group membership.

How to eliminate wrong answers

Option B is wrong because a static inventory file would require manual updates and cannot automatically include hosts from a cloud provider based on a tag; custom scripts do not integrate with automation controller's role-based access control (RBAC) for inventory-level permissions. Option C is wrong because groups within an inventory do not provide independent access control; RBAC in automation controller is applied at the inventory level, not at the group level, so restricting access to a group would not prevent users from seeing other hosts in the same inventory. Option D is wrong because dynamic inventory plugins are defined at the inventory level, not per playbook, and checking team membership in a playbook condition does not enforce access control at the inventory level; it would only skip tasks, not prevent the inventory from being visible or accessible.

Practice this question →
17
Multi-Selecthard

An organization needs to implement security best practices for Ansible automation. Which three measures should be taken? (Choose three.)

Select 3 answers
A.Use ansible-vault to encrypt sensitive variables
B.Store all secrets in plain text in repository
C.Regularly rotate Ansible Vault passwords
D.Disable SSH host key checking globally
E.Limit access to automation controller using RBAC
AnswersA, C, E

Encrypting sensitive variables with ansible-vault protects credentials and secrets at rest, satisfying the requirement to secure automation data. Vault-encrypted files remain usable in playbooks via the vault password, so confidentiality is achieved without breaking execution. This directly addresses the security best-practise constraint in the stem.

Why this answer

Option A is correct because ansible-vault encrypts sensitive variables and files (e.g., via `ansible-vault encrypt` or `encrypt_string`) so secrets such as passwords and API keys are not exposed in plain text within playbooks or repositories. Option C is correct because regularly rotating Ansible Vault passwords limits the impact of a compromised vault password and should be paired with `ansible-vault rekey` to re-encrypt vaulted content under the new password. Option E is correct because limiting access to the automation controller with role-based access control (RBAC) enforces least privilege, ensuring only authorized users or teams can launch jobs, edit credentials, or manage inventories.

Option B is not acceptable since storing secrets in plain text in a repository exposes them to anyone with repo access and violates security best practices. Option D is wrong because disabling SSH host key checking globally removes protection against man-in-the-middle attacks and should not be done as a security measure.

Exam trap

The trap here is that candidates may think disabling SSH host key checking is acceptable for convenience in lab environments, but the exam expects you to recognize it as a security risk that should never be applied globally in production.

Practice this question →
18
MCQhard

An organization uses Automation Controller with multiple teams. They want to ensure that team members can only launch job templates that are explicitly assigned to their team. Which configuration approach should be used?

A.Assign each team to an organization and set organization-level permissions
B.Set 'allow simultaneous' to false on job templates
C.Use an Identity Provider (IdP) to restrict access
D.Create roles and assign them at the job template level using team roles
AnswerD

Assigning team roles directly on each job template grants the team execute permission only for that template, satisfying the constraint that members launch solely explicitly assigned templates. Organisation-wide roles would over-grant access, so template-level role assignment is required.

Why this answer

Automation Controller (formerly Ansible Tower) uses Role-Based Access Control (RBAC) where roles (e.g., Execute, Admin) can be assigned to teams at the job template level. This ensures that only members of a specific team can launch the job templates explicitly assigned to that team, without affecting other teams or requiring organization-wide permissions.

Exam trap

The trap here is confusing authentication (IdP) with authorization (RBAC), leading candidates to choose Option C, even though IdPs like LDAP or SAML only verify who the user is, not what they can do within Automation Controller.

How to eliminate wrong answers

Option A is wrong because setting organization-level permissions grants access to all teams within the organization, not restricting job template access to a specific team. Option B is wrong because 'allow simultaneous' controls whether multiple concurrent runs of the same job template are permitted, not who can launch it. Option C is wrong because an Identity Provider (IdP) handles authentication (verifying user identity), not authorization (controlling access to specific resources like job templates); RBAC within Automation Controller is required for fine-grained access control.

Practice this question →
19
MCQmedium

An automation team uses Ansible Automation Platform to manage secrets. They have a requirement that certain tasks must not log sensitive output to the Ansible logs. Which Ansible task keyword should be used to prevent a task from logging its output?

A.`no_log: true`
B.`ignore_errors: true`
C.`check_mode: true`
D.`become: true`
AnswerA

The `no_log` keyword, when set to `true` on a task, prevents Ansible from logging the task's output, including any sensitive data. This is the correct way to ensure that secrets are not exposed in logs. It can be applied at the task level or globally in `ansible.cfg` with `no_log = True`. This directly addresses the requirement to avoid logging sensitive output.

Why this answer

The `no_log` keyword is specifically designed to prevent Ansible from logging a task's output. When set to `true`, it suppresses the output that would normally appear in logs, including any sensitive data. This is the recommended approach for tasks that handle passwords, API keys, or other secrets.

The other keywords control privilege escalation, error handling, or dry-run mode, none of which address logging of sensitive information.

Exam trap

The trap here is confusing `no_log` with other task keywords that control behavior but do not affect logging, such as `become` or `ignore_errors`.

Practice this question →
20
Multi-Selectmedium

An organization uses automation controller and must ensure that sensitive data such as passwords and API keys are not exposed in job output. Which TWO actions should the administrator take? (Choose two.)

Select 2 answers
A.Use automation controller credentials to store secrets instead of plaintext variables.
B.Disable job output entirely for all job templates that use secrets.
C.Mark sensitive variables as no_log: true in tasks that might display them.
D.Enable verbose logging on the job template to audit variable usage.
E.Store all secrets in an unencrypted file on the automation controller and rely on file permissions.
AnswersA, C

Automation controller credentials securely store secrets and inject them at runtime without writing them to job output. Using credentials instead of plaintext variables in playbooks prevents accidental exposure in logs and job details, aligning with the requirement to keep sensitive data out of output.

Why this answer

Using no_log: true on tasks that handle secrets prevents their output from being logged or displayed. Storing secrets in automation controller credentials keeps them out of playbooks and job output. Together, these actions ensure sensitive data is not exposed while maintaining operational visibility.

Exam trap

The trap here is believing that increasing logging or relying on file permissions alone will protect secrets, when in fact those approaches can increase exposure or fail to secure the data.

Practice this question →
21
MCQeasy

A company uses Ansible Automation Platform and wants to ensure that all playbook runs are logged for audit purposes. What is the simplest way to achieve centralized logging of job runs?

A.Use the logging module in each playbook to write to a central syslog.
B.Configure the syslog server in the automation controller settings.
C.Add a playbook callback that sends output to a file on each node.
D.Enable verbose logging in the inventory file.
AnswerB

Configuring the syslog server in automation controller settings forwards job-run audit records directly to a central collector, satisfying the requirement for centralised logging without extra tooling. Automation controller emits job events, activity stream entries and login attempts over syslog, so a single setting delivers the audit trail the stem demands.

Why this answer

Automation Controller (formerly Ansible Tower) has a built-in setting under 'System → Logging' where you can configure a syslog server (e.g., using RFC 5424). Once configured, all job runs, playbook output, and audit events are automatically forwarded to that central syslog server without modifying any playbooks or adding custom callbacks. This is the simplest, most centralized, and most maintainable approach for audit logging.

Exam trap

The trap here is that candidates often think they need to modify playbooks (Option A) or write custom callback plugins (Option C) to achieve logging, when the platform already provides a simple, built-in configuration option for centralized syslog forwarding.

How to eliminate wrong answers

Option A is wrong because adding a 'logging' module call to every playbook is not centralized; it requires manual insertion into each playbook, violates the principle of separation of concerns, and does not capture system-level events like job launches or failures. Option C is wrong because a callback plugin that writes to a file on each node creates distributed logs, not centralized logging, and requires custom development and deployment to all nodes. Option D is wrong because enabling verbose logging in the inventory file is not a valid Ansible concept; inventory files do not have a 'verbose' setting, and even if you meant verbosity at the ansible-playbook command level, that only increases output detail locally and does not send logs to a central server.

Practice this question →
22
MCQeasy

An automation team wants to securely store SSH private keys for use in playbooks. Which Ansible feature should they use?

A.Ansible Collections
B.Ansible Vault
C.Ansible Fact Cache
D.Ansible Galaxy
AnswerB

Ansible Vault encrypts sensitive files and variables at rest using AES-256, so SSH private keys can be stored in encrypted form and decrypted at runtime with the vault password. This satisfies the requirement for secure storage rather than plaintext in the repository.

Why this answer

Ansible Vault is the correct feature for securely storing SSH private keys because it encrypts sensitive data at rest using AES-256, allowing keys to be decrypted at runtime when a vault password or key is provided. This enables playbooks to reference encrypted SSH key files without exposing plaintext credentials in version control or on disk.

Exam trap

The trap here is that candidates might confuse Ansible Vault with Ansible Galaxy, assuming Galaxy provides security features because it is a central repository, but Galaxy only distributes content and has no encryption or secure storage capabilities.

How to eliminate wrong answers

Option A is wrong because Ansible Collections are a distribution format for packaging and sharing automation content (roles, modules, plugins), not a mechanism for encrypting or securing sensitive data like SSH keys. Option C is wrong because Ansible Fact Cache stores gathered system facts (e.g., IP addresses, OS version) in a backend like Redis or Memcached to improve performance, and it does not provide encryption or secure storage for secrets. Option D is wrong because Ansible Galaxy is a public hub for sharing Ansible content (roles, collections) and a command-line tool for downloading them, with no built-in encryption or secure storage capability for SSH private keys.

Practice this question →
23
MCQhard

An automation controller administrator needs to ensure that a vault password used by multiple job templates is rotated periodically without editing each job template. Which approach is most efficient and secure?

A.Store the vault password in a file on the automation controller and reference it from each job template's extra variables.
B.Use a separate vault credential for each job template so that rotation can be done independently.
C.Create a single vault credential, attach it to all relevant job templates, and update the credential when rotating the password.
D.Embed the vault password in the playbook repository and use a source control webhook to trigger updates.
AnswerC

A single vault credential can be shared across multiple job templates. When the password is rotated, updating the credential automatically propagates the new password to all attached job templates, avoiding individual edits. This centralizes management and reduces the risk of missing a template.

Why this answer

A shared vault credential in automation controller allows multiple job templates to use the same secret. Rotating the password only requires updating the credential, which automatically applies to all attached job templates. This is both efficient and secure, as the credential is encrypted and access-controlled.

Exam trap

The trap here is thinking that separate credentials per job template or storing the password in the repository is necessary, when a shared credential provides centralized rotation.

Practice this question →
24
MCQhard

You are using Ansible Automation Platform to manage a large number of servers. You need to ensure that playbooks that run against production servers use a separate set of credentials than those used for development servers. The production credentials must be stored securely and audited. Which Ansible Automation Platform feature should you use to achieve this?

A.Use the `--ask-pass` and `--ask-become-pass` options when launching playbooks from the command line.
B.Use Ansible Vault to encrypt the production credentials and store them in the playbook repository.
C.Configure the production inventory with a separate `ansible_user` and `ansible_ssh_pass` in the inventory file.
D.Create separate credentials in automation controller and assign them to different job templates based on the environment.
AnswerD

Automation controller allows you to create multiple credentials, each with its own secrets, and associate them with job templates. By creating distinct credentials for production and development, you ensure that playbooks use the appropriate set. Credentials are stored encrypted in the controller's database and their usage is audited in job runs. This directly meets the requirement for secure storage and auditing.

Why this answer

Automation controller credentials are designed for secure storage and auditing. By creating separate credentials for production and development and assigning them to the appropriate job templates, you ensure that each environment uses its own set of secrets. The controller encrypts credentials and logs their usage, providing the required audit trail.

The other options either store credentials insecurely or lack centralized management and auditing.

Exam trap

The trap here is thinking that Ansible Vault alone can provide the same level of secure storage and auditing as automation controller credentials.

Practice this question →
25
MCQeasy

A junior administrator needs to rotate the password for a database user stored in an Ansible Vault-encrypted file (secrets.yml). The current password is unknown to the admin, but they have the vault password file (vault-pass.txt). The admin wants to edit the file securely without exposing the decrypted content in the terminal history or logs. Which command should they run?

A.ansible-vault edit --vault-password-file vault-pass.txt secrets.yml
B.ansible-vault decrypt --vault-password-file vault-pass.txt secrets.yml
C.ansible-vault rekey --vault-password-file vault-pass.txt secrets.yml
D.ansible-vault view --vault-password-file vault-pass.txt secrets.yml
AnswerA

ansible-vault edit decrypts into a temporary file and opens the editor, so plaintext never enters shell history or terminal output; supplying --vault-password-file avoids an interactive prompt. This satisfies the requirement to edit securely without exposing decrypted content.

Why this answer

`ansible-vault edit` decrypts the file to a temporary file, opens it in the default editor (e.g., vi), and upon saving, re-encrypts it transparently. This prevents the decrypted content from ever being written to the terminal history or logs, as the editing happens in a secure temporary location that is cleaned up after the editor closes.

Exam trap

The trap here is that candidates may confuse `edit` with `decrypt` (thinking they need to decrypt first, then edit, then re-encrypt), or they may think `rekey` is for changing the content, when in fact it only changes the vault encryption password.

How to eliminate wrong answers

Option B is wrong because `ansible-vault decrypt` permanently decrypts the file to plaintext on disk, which would expose the password in the filesystem and potentially in logs or history if the file is later read. Option C is wrong because `ansible-vault rekey` is used to change the vault password (encryption key) itself, not to edit the content of the encrypted file. Option D is wrong because `ansible-vault view` only displays the decrypted content to stdout (terminal), which would expose the password in the terminal output and potentially in scrollback or logs, without allowing any editing.

Practice this question →
26
Multi-Selecthard

An automation controller administrator must ensure that a job template handling credentials follows security best practices for both storage and execution. Which TWO actions should be taken in automation controller? (Choose two.)

Select 2 answers
A.Reference the credential from the job template so it is injected at runtime instead of hardcoding it in the playbook.
B.Enable the job template option to suppress Ansible output so sensitive data is not written to job logs.
C.Grant the operator system administrator role on the organization so they can manage all credentials centrally.
D.Store the SSH private key as a machine credential in automation controller rather than in a project repository.
E.Mark the job template as prompting for the credential on launch so operators supply secrets interactively.
AnswersA, D

Attaching the credential to the job template lets automation controller inject it into the execution environment at run time, removing hardcoded secrets from playbooks and inventories. This complements encrypted storage and ensures the value is only present transiently during the job, which is the intended best practice.

Why this answer

Automation controller stores credentials encrypted and injects them at run time, so keeping SSH keys in a machine credential and referencing that credential from the job template removes secrets from source control and from static inventories. Together these actions centralize secret storage and limit exposure to the moment of execution, which is the intended best practice.

Exam trap

The trap here is assuming that a job template option can globally hide Ansible output, when output masking is handled per task with no_log and controller's role is encrypted storage plus runtime injection.

Practice this question →
27
MCQeasy

Refer to the exhibit. A playbook fails with the given error. What is the most likely cause?

A.The playbook syntax is wrong.
B.The vault password file is missing or incorrect.
C.The inventory file is encrypted.
D.The remote host is unreachable.
AnswerB

Ansible decrypts vaulted variables at runtime using the supplied vault password; if that file is absent or holds the wrong secret, decryption fails immediately, producing the exhibited vault error rather than a syntax or connectivity fault.

Why this answer

The error in the exhibit (typically 'Attempting to decrypt but no vault secrets found' or 'no vault password file') indicates Ansible cannot decrypt vault-encrypted content because the vault password file is missing, unreadable, or contains the wrong password. Ansible needs either --ask-vault-pass or --vault-password-file pointing to a valid file. If the file path is wrong or the password is incorrect, decryption fails before the play can run.

Exam trap

EX294 often tests the confusion between vault decryption errors and inventory/host connectivity errors, so candidates blame the inventory or SSH when the real issue is the vault password file.

How to eliminate wrong answers

Option A is wrong because a YAML syntax error produces a different message (e.g., 'Syntax Error while loading YAML') and would fail at parse time, not at vault decryption. Option C is wrong because an encrypted inventory file would produce a vault decryption error specifically tied to the inventory, but the exhibit's error is about vault secrets generally, and encrypting inventory is uncommon. Option D is wrong because an unreachable host produces 'UNREACHABLE' or SSH timeout errors, not a vault decryption failure.

Practice this question →
28
Multi-Selectmedium

Which two actions are appropriate when configuring a custom execution environment for an automation controller job? (Choose two.)

Select 2 answers
A.Storing the execution environment in a public registry only
B.Building the execution environment using ansible-builder
C.Setting the execution_environment_image in the project's SCM
D.Using the default execution environment provided by controller
E.Creating a Containerfile with the required packages
AnswersB, E

ansible-builder reads an execution environment definition and produces the container image that automation controller pulls to run jobs. It satisfies the requirement for a custom execution environment by assembling dependencies into a runnable image, rather than relying on the default image.

Why this answer

Option B is correct because ansible-builder is the supported tool for creating custom execution environments; it reads an execution-environment.yml definition file and produces a container image containing the required collections, Python packages, and system dependencies. Option E is correct because the execution environment image is defined by a Containerfile (or Dockerfile) that specifies the base image and installs the needed packages, which ansible-builder uses as its build input. Option A is incorrect because execution environments can be stored in private registries (e.g., automation hub, private container registries), not only public ones, and public-only storage is not a requirement.

Option C is incorrect because execution_environment_image is configured on the job template or organization in the automation controller, not in the project's SCM repository. Option D is incorrect because using the default execution environment does not constitute configuring a custom execution environment, which is what the scenario requires.

Exam trap

The trap here is that candidates confuse the `execution_environment_image` field (set in the controller UI or API) with a setting in the project's SCM, or they assume that custom execution environments must always be stored in a public registry, ignoring private registry options.

Practice this question →
29
MCQmedium

Refer to the exhibit. What is the most likely cause of the job being in 'pending' state?

A.The job is queued because the capacity limit of the automation controller is reached.
B.The credential is invalid and the system is attempting to validate it.
C.The job template is configured with a survey that requires approval.
D.The project needs to be updated before the job can run.
AnswerA

Reaching the automation controller's capacity limit caps concurrent job execution, so the task queues in 'pending' until a running job finishes and frees a slot. This matches the stem's constraint: the exhibit shows no execution errors, only a job awaiting available capacity rather than failing outright.

Why this answer

In Ansible Automation Platform, when a job is in 'pending' state, it typically indicates that the automation controller has queued the job because the maximum number of concurrent jobs (capacity limit) has been reached. The controller uses a job fork limit and instance group capacity to determine how many jobs can run simultaneously; once that limit is hit, additional jobs are placed in a pending queue until capacity frees up.

Exam trap

Red Hat often tests the distinction between 'pending' (capacity queue) and 'awaiting approval' (survey or workflow approval), so candidates mistakenly choose the survey option when they see a job not starting immediately.

How to eliminate wrong answers

Option B is wrong because an invalid credential would cause the job to fail immediately with an authentication error, not remain in a pending state; the system does not retry validation indefinitely. Option C is wrong because a survey requiring approval would place the job in an 'awaiting approval' state, not 'pending'; approval is a separate workflow step before the job is even queued. Option D is wrong because a project update is a prerequisite for launching a job template, but if the project is outdated, the job would either fail or prompt an update, not sit in pending; pending specifically relates to capacity, not project sync status.

Practice this question →
30
Multi-Selecteasy

A managed node is configured with an Ansible vault-encrypted variable file. When running a playbook that uses these variables, the user receives a 'decryption failed' error. Which two steps should the user take to resolve the issue?

Select 2 answers
A.Verify the file permissions are set to 600.
B.Check that the SSH private key has access to the managed node.
C.Make sure the vault password file contains the path to the vault file.
D.Ensure the vault ID matches the one used when encrypting the file.
E.Verify the correct vault password is being provided.
AnswersD, E

Vault matches decryption to the vault ID recorded in the file's header. If the playbook supplies a different ID, or none, decryption fails even with the right password, so aligning the vault ID used at encryption with the one supplied at runtime resolves it.

Why this answer

Option D is correct because Ansible vault supports multiple vault IDs, and if the playbook or ansible-vault command specifies a vault ID that differs from the one used at encryption time, decryption will fail with a 'decryption failed' error; the vault ID must match exactly. Option E is correct because the most common cause of a vault decryption failure is supplying the wrong vault password, whether via --ask-vault-pass, --vault-password-file, or the ANSIBLE_VAULT_PASSWORD_FILE environment variable, so verifying the correct password resolves the error. Option A is not correct because file permissions of 600 affect access control, not the cryptographic decryption of vault contents.

Option B is not correct because SSH private key access to the managed node is unrelated to decrypting a local vault-encrypted variable file. Option C is not correct because a vault password file should contain the password itself, not the path to the vault file, so that step is technically inaccurate.

Exam trap

The trap here is that candidates often assume 'decryption failed' always means a wrong password, overlooking that Ansible vault IDs must match exactly when multiple vault passwords are in use.

Practice this question →
31
MCQeasy

A developer wants to encrypt a string in a playbook variable file. Which command should they use?

A.ansible-vault rekey
B.ansible-vault create
C.ansible-vault edit
D.ansible-vault encrypt_string
AnswerD

The ansible-vault encrypt_string subcommand encrypts a single string value inline, producing ciphertext suitable for embedding directly in a variable file. This satisfies the requirement to encrypt one string rather than an entire file, which encrypt would handle.

Why this answer

`ansible-vault encrypt_string` is specifically designed to encrypt a single string value for use in a playbook variable file, without encrypting the entire file. This command outputs the encrypted string in a format that can be directly pasted into a YAML variable definition, preserving the rest of the file as plaintext.

Exam trap

The trap here is that candidates confuse encrypting a single string with encrypting an entire file, leading them to choose `ansible-vault create` or `ansible-vault edit` instead of the specific `encrypt_string` subcommand.

How to eliminate wrong answers

Option A is wrong because `ansible-vault rekey` is used to change the password of an already encrypted file, not to encrypt a string. Option B is wrong because `ansible-vault create` creates a new encrypted file from scratch, not a single string for a variable file. Option C is wrong because `ansible-vault edit` opens an existing encrypted file for modification, not to encrypt a new string.

Practice this question →
32
MCQeasy

A playbook uses the `copy` module to distribute a configuration file to managed nodes. The file contains a sensitive API key. You want to ensure the API key is not visible in the playbook source or in Ansible logs. Which approach should you use?

A.Store the API key in an environment variable on the control node and use the `lookup` plugin `env` to inject it into the copy module.
B.Use the `copy` module with the API key hardcoded in the content parameter and rely on Ansible's automatic log redaction.
C.Use the `template` module with a Jinja2 template that includes the API key as a plaintext variable defined in the playbook.
D.Store the API key in a vault-encrypted variable file, reference it in the copy module's content parameter, and set no_log: true on the task.
AnswerD

Using a vault-encrypted variable file keeps the API key encrypted at rest and out of the playbook source. Referencing it in the content parameter allows the file to be generated with the secret. Setting no_log: true prevents the task output from displaying the secret in logs or console. Together, these measures protect the key in both storage and execution, meeting the requirement.

Why this answer

To protect a sensitive API key, it should be stored encrypted using Ansible Vault and referenced in the playbook without exposing plaintext. Marking the task with no_log: true prevents the secret from appearing in output or logs. Using plaintext variables, hardcoded values, or environment variables without no_log leaves the secret exposed in the playbook source or execution logs, failing the security requirement.

Exam trap

The trap here is assuming Ansible automatically hides sensitive data in module parameters, when only explicit no_log: true suppresses task output.

Practice this question →
33
MCQeasy

An automation team wants to grant a group of operators the ability to launch job templates in automation controller but prevent them from modifying the job template configuration. They also need to troubleshoot failed jobs by viewing job output. Which predefined role should be assigned to the team for a specific job template?

A.Execute role
B.Read role
C.Admin role
D.Update role
AnswerA

The Execute role grants permission to launch a job template and view its job output, without allowing edits to the template configuration. Assigning it on the specific job template satisfies both the launch and troubleshooting requirements.

Why this answer

The Execute role is the correct predefined role because it grants permission to launch a job template and view job output (including standard out and error logs) without allowing any modifications to the job template's configuration. This aligns exactly with the requirement: operators can execute and troubleshoot failed jobs but cannot edit the template.

Exam trap

The trap here is that candidates often confuse the Execute role with the Read role, assuming that Read allows launching jobs, when in fact Read only permits viewing the template and its output, not executing it.

How to eliminate wrong answers

Option B (Read role) is wrong because it only allows viewing the job template definition and job output, but does not include the permission to launch the job template. Option C (Admin role) is wrong because it grants full administrative privileges, including the ability to modify the job template configuration, which violates the requirement to prevent modifications. Option D (Update role) is wrong because it allows updating the job template's configuration, which is explicitly prohibited by the requirement.

Practice this question →
34
MCQmedium

You are preparing an Ansible playbook that will run on a managed node. The playbook includes a task that uses the `ansible.builtin.user` module to create a user. The playbook is stored in a Git repository that multiple engineers can access. You need to ensure that the password for the new user is not stored in plain text in the repository. Which Ansible feature should you use to protect the password?

A.ansible-vault create
B.ansible-vault encrypt_string
C.ansible-vault encrypt
D.ansible-vault rekey
AnswerB

`ansible-vault encrypt_string` encrypts a single string value, such as a password, which can then be embedded directly in a playbook or variable file. This keeps the secret out of plain text while allowing the playbook to decrypt it at runtime with the vault password. It is ideal for inline secrets that are not part of a larger file, and it integrates seamlessly with Ansible's vault mechanism.

Why this answer

The password must not be stored in plain text in the Git repository. Using `ansible-vault encrypt_string` allows you to encrypt just the password value and include it inline in the playbook or variables file. At runtime, Ansible decrypts the string using the vault password, so the secret remains protected in version control.

The other commands either encrypt entire files or manage vault keys, which do not address an inline secret.

Exam trap

The trap here is confusing file-level encryption with string-level encryption, assuming any ansible-vault command can protect an inline secret.

Practice this question →
35
MCQeasy

A Red Hat Certified Engineer is configuring Ansible to run playbooks against managed nodes. The security policy requires that all communication between the control node and managed nodes is encrypted and authenticated. The engineer decides to use SSH keys for authentication. Which Ansible configuration parameter should be set to specify the private key file to use for SSH connections?

A.`ansible_ssh_common_args`
B.`ansible_ssh_pass`
C.`ansible_ssh_private_key_file`
D.`ansible_user`
AnswerC

`ansible_ssh_private_key_file` is an Ansible connection variable that specifies the path to the private key file used for SSH authentication. Setting this variable in the inventory or as a host variable ensures that Ansible uses the correct key when connecting to managed nodes. This directly satisfies the requirement to use SSH keys for encrypted and authenticated communication.

Why this answer

To specify a private key file for SSH connections in Ansible, the connection variable `ansible_ssh_private_key_file` is used. It can be set in the inventory, in group_vars, host_vars, or as an extra variable. This ensures that Ansible uses the designated key for authentication, meeting the security policy.

The other options either specify a password, username, or additional SSH arguments, none of which directly designate the private key file.

Exam trap

The trap here is confusing `ansible_ssh_common_args` with the dedicated private key variable; while you can pass `-i` via common args, the correct parameter is `ansible_ssh_private_key_file`.

Practice this question →
36
MCQhard

An automation team uses Ansible Automation Platform to manage a large number of servers. They need to ensure that sensitive data such as passwords and API keys are not stored in plain text in playbooks or inventory files. They decide to use Ansible Vault to encrypt these secrets. Which of the following best describes how Ansible Vault integrates with playbook execution to protect secrets at runtime?

A.Ansible Vault decrypts secrets on the control node at runtime and passes the decrypted values to managed nodes as needed.
B.Ansible Vault stores secrets in an encrypted keyring on the control node and retrieves them only when explicitly requested by a task.
C.Ansible Vault decrypts secrets on the managed node and stores them in memory only during task execution.
D.Ansible Vault encrypts secrets on the control node and decrypts them on the managed node using a shared vault password.
AnswerA

Ansible Vault operates on the control node. When a playbook references a vault-encrypted file, Ansible decrypts it using the provided vault password. The decrypted variables are then available during playbook execution and are passed to managed nodes as part of task parameters when required. This ensures secrets are not stored in plain text in the repository while still allowing them to be used in automation.

Why this answer

Ansible Vault decrypts encrypted files on the control node when the playbook runs, using the vault password supplied via command line or configuration. The decrypted variables are then used in playbook execution and can be passed to managed nodes as needed. This keeps secrets encrypted at rest in source control while enabling their use in automation.

The other options incorrectly place decryption on managed nodes or describe non-existent keyring features.

Exam trap

The trap here is assuming that managed nodes perform decryption or that a shared vault password is used on managed nodes, when in fact decryption only happens on the control node.

Practice this question →
37
Multi-Selecthard

An organization uses Ansible Automation Platform to manage a large infrastructure. They need to implement security best practices for managing secrets and credentials. Which TWO of the following actions should they take to enhance security? (Choose two.)

Select 2 answers
A.Disable logging for all playbook runs to prevent any possibility of secrets being logged.
B.Use Ansible Vault to encrypt sensitive variables and files before committing them to source control.
C.Store all secrets in plain text in the Git repository to simplify version control.
D.Share the vault password among all team members via email to ensure everyone can run playbooks.
E.Configure automation controller credentials to use external secret management systems like HashiCorp Vault or CyberArk.
AnswersB, E

Ansible Vault encrypts sensitive data at rest, allowing safe storage in source control. By encrypting variables and files, the organization ensures that secrets are not exposed in plain text. This is a recommended best practice for managing secrets in Ansible. It integrates seamlessly with playbook execution, decrypting only at runtime with the proper password.

Why this answer

Using Ansible Vault to encrypt sensitive data before committing to source control and integrating automation controller with external secret management systems are two key best practices. They ensure secrets are encrypted at rest and managed centrally with access controls. Storing secrets in plain text, disabling all logging, or sharing vault passwords insecurely are harmful practices that would weaken security.

These two actions align with the principle of least privilege and defense in depth.

Exam trap

The trap here is thinking that disabling all logging or sharing vault passwords insecurely might be acceptable shortcuts, when they actually undermine security.

Practice this question →
38
Multi-Selecteasy

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

Select 2 answers
A.Use ansible-vault to encrypt variable files.
B.Set the no_log flag on tasks that handle sensitive data.
C.Use the debug module with verbosity to output passwords.
D.Avoid using become: yes on tasks that access secrets.
E.Store credentials in plain text in the inventory.
AnswersA, B

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.

Why this answer

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.

Exam trap

The trap here is that candidates often 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.

Practice this question →

Ready to test yourself?

Try a timed practice session using only Automation Security Ops questions.

Start 20-question session