Courseiva

CCNA Automation Security Ops Questions

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

Practice these questionsExam hubAll questions
1
MCQmedium

Refer to the exhibit. The user ran ansible-navigator without specifying an inventory. What does the warning indicate about the target hosts?

A.The playbook ran against all hosts in the default inventory
B.The playbook used the implicit localhost but it does not match 'all', causing no tasks to run
C.The playbook only ran against localhost because no inventory was defined
D.The playbook failed because no hosts matched
AnswerC

Only implicit localhost was available.

Why this answer

When `ansible-navigator` runs without a specified inventory, it defaults to using the implicit localhost as the only target host. However, because no inventory is defined, the implicit localhost is not part of the `all` group, so the playbook's `hosts: all` directive matches no hosts, resulting in no tasks being executed. Option C correctly identifies that the playbook only targeted localhost (implicitly) but failed to run tasks due to the group mismatch.

Exam trap

Red Hat often tests the misconception that the implicit localhost is automatically included in the `all` group, causing candidates to think tasks will run when no inventory is provided, when in fact they will not execute.

How to eliminate wrong answers

Option A is wrong because without an inventory, there is no default inventory to run against; Ansible requires an explicit inventory file or directory to define hosts, and the implicit localhost is not part of any inventory. Option B is wrong because the implicit localhost is used, but the warning indicates that it does not match 'all', so no tasks run—this is exactly what the warning says, but the option incorrectly states that the playbook 'used the implicit localhost' without acknowledging that the tasks did not execute. Option D is wrong because the playbook did not fail; it completed with a warning that no hosts matched, which is a non-fatal condition—Ansible reports 'ok=0 changed=0' rather than a failure.

Practice this question →
2
Multi-Selecteasy

Which two conditions could prevent an automation controller job from starting? (Choose two.)

Select 2 answers
A.The inventory source is empty
B.The project sync is pending
C.The job template is disabled
D.The user is a system auditor
E.The execution environment image tag is 'latest'
AnswersB, C

Controller may block jobs until project sync completes.

Why this answer

Options A and D are correct: a disabled job template cannot start, and a pending project sync can block execution. Option B is wrong: empty inventory may cause zero hosts but job still starts and fails. Option C is wrong: 'latest' tag is valid.

Option E is wrong: system auditors can still launch jobs if they have the role.

Practice this question →
3
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 secrets at rest and requires a password or key to decrypt.

Why this answer

Option B is correct because Ansible Vault provides encryption for sensitive data such as passwords and API keys, ensuring they are not stored in plaintext. This is a core security practice for automation controller secrets, as it protects credentials at rest and during transport when used with playbooks.

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 →
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

Controller needs registry credentials to pull the image.

Why this answer

Option C is correct because 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

You are managing an Ansible Automation Platform deployment that uses automation mesh with one control node and two execution nodes. The control node is in the DMZ, and the execution nodes are in a private network. The organization's security policy requires that all secrets (e.g., SSH keys, API tokens) be encrypted at rest and never transmitted in plaintext. You have configured vault-encrypted credentials and set the vault password as a credential on the control node. However, a recent audit reveals that when a job runs, the vault password is visible in the job output on the execution nodes. The execution nodes are configured to stream job events back to the control node. The automation controller version is 4.3. The following settings are in place: 'no_log' is not set for any variables; the vault password is stored as a 'Vault password' credential type. The job template uses a custom credential type that injects the vault password as an environment variable. The execution nodes have access to the vault password via that environment variable. The audit shows the environment variable is printed in the job output because the playbook uses the 'env' module to display environment variables for debugging. You must prevent the vault password from appearing in any job output without breaking the ability to decrypt vault-encrypted variables. Which action should you take?

A.Remove the 'env' task from the playbook and ensure no other tasks print environment variables.
B.Configure the automation controller's 'Settings' to enable 'Display secrets' = false.
C.Change the custom credential type to use the built-in 'Vault password' credential type and remove the custom credential type.
D.Edit the custom credential type's input injection to set 'no_log: true' for the environment variable that carries the vault password.
AnswerD

This ensures the vault password is never displayed in job output, while still being available for vault decryption.

Why this answer

Option D is correct because setting `no_log: true` on the environment variable injection in the custom credential type prevents Ansible from logging the value of that variable in job output, while still allowing the vault password to be used by the playbook to decrypt vault-encrypted variables. This directly addresses the audit finding without removing debugging capabilities or changing the credential type.

Exam trap

The trap here is that candidates often think removing the debugging task (Option A) is sufficient, but they miss that the underlying issue is the credential injection method, and that `no_log` is the proper way to prevent secret exposure in Ansible Automation Platform.

How to eliminate wrong answers

Option A is wrong because it only removes the specific `env` task but does not prevent other tasks or modules from inadvertently printing the environment variable, and it does not address the root cause of the vault password being exposed. Option B is wrong because there is no 'Display secrets' setting in automation controller; the relevant setting is `no_log` on credentials or variables, not a global toggle. Option C is wrong because the built-in 'Vault password' credential type does not inject the vault password as an environment variable; it only stores the password for use by the controller to decrypt vault files, and removing the custom credential type would break the ability to inject the vault password into the execution environment.

Practice this question →
6
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

Ansible-builder creates a standard image; private registry ensures security and signing.

Why this answer

Option A is correct because 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 →
7
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

Execute role on job template is required.

Why this answer

Option C is correct because 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 →
8
Matchingmedium

Match each Linux command to its function.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts
Matches

Socket statistics

Query systemd journal

Show current SELinux mode

Manage firewalld rules

Extend a logical volume

Why these pairings

Essential commands for system administration in RHEL.

Practice this question →
9
Drag & Dropmedium

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

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps
Order

Why this order

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

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

The become password must be supplied in the credential's 'Become password' field when the remote user requires a password for privilege escalation.

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
Multi-Selectmedium

Which TWO are valid ways to restrict access to job templates in Automation Controller?

Select 2 answers
A.Use tags in playbooks
B.Set job template to 'run at specific times'
C.Use inventory source filters
D.Use credential types with separate permissions
E.Assign RBAC roles to teams
AnswersD, E

Credential types can have permissions that restrict which users or teams can use specific credentials in job templates.

Why this answer

Assigning RBAC roles to teams and using credential types with separate permissions are both valid methods to control access to job templates. Tags filter tasks within playbooks, not access. Inventory source filters determine dynamic inventory hosts.

Scheduling sets execution time, not permissions.

Practice this question →
12
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

Vault files must be rekeyed when the password changes.

Why this answer

Option B is correct because 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 →
13
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

Smart inventory automatically includes hosts based on filter; RBAC controls access.

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 →
14
MCQhard

A security team requires that all automation controller job logs be forwarded to an external SIEM system. Which integration should be used?

A.Ansible Log Forwarder
B.Custom callback plugin
C.Automation controller's built-in logging aggregator
D.rsyslog configuration
AnswerC

Built-in aggregator forwards logs to external systems.

Why this answer

Automation controller (formerly Ansible Tower) includes a built-in logging aggregator that can forward job logs to external SIEM systems via supported protocols such as HTTPS, TCP, or UDP. This integration is configured directly in the controller's settings, requiring no additional scripts or system-level changes, making it the correct and supported method for centralized log forwarding.

Exam trap

The trap here is that candidates may confuse the built-in logging aggregator with system-level tools like rsyslog or assume a custom callback plugin is required, when in fact the controller provides a native, configuration-driven solution for this exact requirement.

How to eliminate wrong answers

Option A is wrong because 'Ansible Log Forwarder' is not a real component or integration in the automation controller; it is a fabricated term. Option B is wrong because custom callback plugins are used to extend Ansible's callback behavior during playbook execution, but they are not the standard or supported integration for forwarding job logs to an external SIEM; the controller's built-in logging aggregator is the intended mechanism. Option D is wrong because rsyslog configuration operates at the system level and would require manual setup to capture and forward logs, but it does not integrate with automation controller's job log structure or API, and it is not the recommended or supported method for this purpose.

Practice this question →
15
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

Encrypts secrets at rest.

Why this answer

Option A is correct because `ansible-vault` is the built-in Ansible tool for encrypting sensitive data such as passwords, API keys, and secret variables. It uses AES-256 encryption to protect secrets at rest, ensuring they are not exposed in plain text within playbooks, inventory files, or version control systems. This is a fundamental security best practice for any Ansible automation environment.

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 →
16
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

Team roles on job templates restrict launch access.

Why this answer

Option D is correct because 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 →
17
MCQhard

An organization uses a proprietary API service that requires token-based authentication with a base64-encoded payload including username, password, and tenant ID. The administrator wants to create a custom credential type in automation controller so that users can input these three values separately, and the playbook receives the final token. Which input configuration fields should be defined?

A.Three separate text fields (username, password, tenant ID) with a custom injector template that concatenates and base64-encodes them.
B.One text field for the token, and inject it as an environment variable.
C.Two fields: username and password, and use a lookup plugin to fetch tenant ID.
D.Create a single multiline text field where users paste the base64 string.
AnswerA

Allows separate inputs and injector creates the final token.

Why this answer

Custom credential types allow multiple inputs and an injector template to transform them. Option B allows users to input each component separately and the injector creates the base64 token. Option A only stores the token.

Option C misses tenant ID. Option D is not user-friendly.

Practice this question →
18
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

Centralized logging is a built-in feature of automation controller.

Why this answer

Option B is correct because 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 →
19
MCQmedium

A playbook fails with 'ERROR! 'become' is not a valid attribute for a Play'. What is the most likely cause?

A.The playbook lacks a hosts line
B.The become directive is misspelled
C.become is allowed only in tasks, not plays
D.The playbook uses an older syntax that requires 'sudo'
AnswerD

Older Ansible used 'sudo: yes' instead of 'become: yes'.

Why this answer

Option D is correct because in older versions of Ansible (prior to 2.0), privilege escalation was handled using the 'sudo' keyword at the play level. The error 'become' is not a valid attribute for a Play' indicates that the playbook is using the modern 'become' directive at the play level, but the installed Ansible version (likely 1.x) does not support it. The correct syntax for that version would be 'sudo: yes'.

Exam trap

The trap here is that candidates familiar with modern Ansible assume 'become' is universally valid, forgetting that EX294 covers RHEL 8 which ships with Ansible 2.9, but the question deliberately references an older version to test knowledge of version-specific syntax changes.

How to eliminate wrong answers

Option A is wrong because a missing 'hosts' line would cause a different error ('hosts is required for each play'), not a complaint about 'become'. Option B is wrong because if 'become' were misspelled, Ansible would treat it as an unknown key and likely ignore it or produce a warning, not a fatal error about an invalid attribute. Option C is wrong because 'become' is actually valid at the play level in Ansible 2.0+; the error occurs only when the Ansible version is too old to recognize it.

Practice this question →
20
MCQhard

A company has deployed Ansible Automation Platform with a single automation controller node. The operations team uses a workflow that includes three job templates: A, B, and C, each requiring different credentials. Recently, the workflow started failing intermittently with errors such as 'Timeout' and 'Connection refused' on certain hosts. The inventory is dynamic from a cloud provider. The administrator checks that the credentials are valid and the hosts are online. The job execution history shows that the failures occur only when the workflow attempts to run job template B on a subset of hosts that are located in a different subnet. Job templates A and C run fine on all hosts. What is the most likely cause and the best course of action?

A.The hosts in the problematic subnet are not reachable due to a firewall; add those hosts to a separate inventory and use a different cloud credential.
B.The credential used by job template B is associated with an incorrect SSH key for those hosts; create a new credential for that subnet and update the job template.
C.The automation controller does not have network access to the problematic subnet; install a second automation controller node in that subnet and configure clustering.
D.The job template B requires a sudo escalation that is not configured on those hosts; update the playbook to use become_method: su.
AnswerB

Incorrect SSH key causes connection refused; separate credentials per subnet can resolve.

Why this answer

Option B is correct because the intermittent failures on a specific subnet, despite valid credentials and online hosts, strongly indicate that the SSH key or credential used by job template B is not accepted by those hosts. Since job templates A and C work fine on all hosts, the issue is credential-specific, not network-wide. Creating a new credential with the correct SSH key for that subnet and updating job template B resolves the authentication failure.

Exam trap

The trap here is that candidates confuse network-level connectivity issues (firewall, routing) with authentication-level failures, assuming 'Connection refused' always means a firewall block rather than an SSH key rejection or credential mismatch.

How to eliminate wrong answers

Option A is wrong because adding hosts to a separate inventory with a different cloud credential does not address SSH key mismatch; cloud credentials are for API authentication to the cloud provider, not for host-level SSH access. Option C is wrong because if the automation controller lacked network access to the subnet, job templates A and C would also fail on those hosts, but they run fine; clustering does not fix credential issues. Option D is wrong because sudo escalation method (become_method) does not cause 'Timeout' or 'Connection refused' errors; those are network or authentication errors, not privilege escalation failures.

Practice this question →
21
MCQhard

A Red Hat Ansible Automation Platform deployment uses automation mesh to manage remote nodes across a high-latency WAN. An administrator notices that some job runs fail intermittently due to connection timeouts. The administrator wants to improve reliability without changing network infrastructure. Which configuration change is most effective?

A.Increase the 'timeout' value in the [defaults] section of ansible.cfg to 60 seconds.
B.Increase the 'retries' parameter for each task.
C.Increase the 'forks' value in ansible.cfg to 50.
D.Set 'async: 600' and 'poll: 10' in the playbook.
AnswerA

This extends the connection timeout, accommodating high-latency links.

Why this answer

Option A is correct because increasing the 'timeout' value in the [defaults] section of ansible.cfg extends the SSH connection timeout, which directly addresses intermittent failures caused by high-latency WAN links. This change allows Ansible to wait longer for a remote node to respond before aborting the connection, improving reliability without altering network infrastructure.

Exam trap

The trap here is that candidates often confuse connection timeouts with task execution failures, leading them to choose retries (Option B) or async (Option D), which do not address the root cause of SSH connection drops on high-latency links.

How to eliminate wrong answers

Option B is wrong because increasing the 'retries' parameter for each task only retries the task execution after a failure, but does not address the underlying connection timeout issue; the initial connection would still fail before any retry logic applies. Option C is wrong because increasing the 'forks' value to 50 increases parallelism, which can exacerbate network congestion and timeout issues on a high-latency WAN, making reliability worse. Option D is wrong because setting 'async: 600' and 'poll: 10' is designed for long-running tasks that should run in the background without blocking, not for fixing connection timeouts; it does not affect the SSH connection timeout that causes the intermittent failures.

Practice this question →
22
Multi-Selectmedium

An automation controller administrator must ensure that a playbook's output does not expose sensitive data. Which TWO actions should be taken? (Choose exactly two.)

Select 2 answers
A.Set 'no_log: true' on tasks that handle sensitive data.
B.Set 'stdout_callback = actionable' in ansible.cfg.
C.Use 'name: "Sensitive task"' but keep the task body visible.
D.Add 'display_args_to_stdout = false' to the execution environment's ansible.cfg.
E.Use 'tags: never' on sensitive tasks.
AnswersA, D

This prevents the output of those tasks from being displayed.

Why this answer

Setting 'no_log: true' on tasks that handle sensitive data (Option A) is the correct approach because it prevents Ansible from printing task arguments and output to the console or log files, ensuring that sensitive information like passwords or API keys are not exposed. This directive is a built-in Ansible feature specifically designed for security-sensitive operations.

Exam trap

The trap here is that candidates often confuse reducing output verbosity (Option B) with actually hiding sensitive data, not realizing that 'no_log' is the only mechanism that explicitly redacts task arguments and results from all output channels.

Practice this question →
23
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 data.

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 →
24
MCQhard

A managed node is not responding to Ansible automation. The administrator verifies that the node is reachable via SSH and that the SSH key is correctly deployed. However, 'ansible all -m ping' fails with 'UNREACHABLE'. The automation controller uses a custom execution environment. What is the most likely cause?

A.The SSH private key has incorrect permissions on the controller.
B.The remote user specified in the credential does not have sudo access.
C.The custom execution environment is missing the 'python3' or 'python' package.
D.The automation controller is behind a firewall that blocks SSH.
AnswerC

Ansible requires Python on the control node (execution environment) to execute modules; missing Python causes unreachable errors.

Why this answer

Option C is correct because the custom execution environment is a container image that must contain the Python interpreter (python3 or python) for Ansible to execute modules on the managed node. When the environment lacks Python, the 'ansible -m ping' module cannot be transferred and executed, resulting in an 'UNREACHABLE' status despite SSH connectivity being verified.

Exam trap

The trap here is that candidates often assume 'UNREACHABLE' always indicates a network or SSH issue, but EX294 tests the understanding that Ansible requires Python on the managed node, and a custom execution environment may lack it, causing a false unreachable status.

How to eliminate wrong answers

Option A is wrong because the administrator verified that the SSH key is correctly deployed, and incorrect permissions on the private key would cause an SSH authentication failure, not an 'UNREACHABLE' status after SSH connectivity is confirmed. Option B is wrong because sudo access is not required for the 'ping' module, which only tests Python availability and does not escalate privileges. Option D is wrong because the administrator verified that the node is reachable via SSH, which would fail if a firewall blocked SSH traffic.

Practice this question →
25
MCQhard

A large enterprise runs a multi-tenant Ansible Automation Platform deployment. The security team has mandated strict role-based access control (RBAC) for three departments: Network (manages routers/switches), Security (manages firewalls/IDS), and Operations (manages servers/applications). Each department must have its own projects, inventories, job templates, and credentials. Additionally, credentials must not be viewable by users who do not own them. The platform currently uses a single organization with one team and all users have admin permissions. Which course of action best meets these requirements?

A.Create three organizations (Network, Security, Operations). Within each organization, create a team, assign users, and grant appropriate permissions. Use custom roles to restrict credential access to team members only.
B.Create custom roles with no organizations. Assign users directly to resources via user-level permissions.
C.Keep a single organization but create three teams. Assign each team to its own projects and inventories, and use job template-level permissions to restrict access.
D.Use a single organization with one team. Set all credentials to 'read-only' to prevent viewing of secret values.
AnswerA

Organizations provide natural boundaries for resource isolation; teams and custom roles enforce fine-grained access.

Why this answer

Option A is correct because creating separate organizations for each department provides the strongest isolation boundary in Ansible Automation Platform. Within each organization, a dedicated team with custom roles ensures that credentials are scoped to that team and cannot be viewed by users outside it, satisfying the RBAC and credential visibility requirements.

Exam trap

The trap here is that candidates assume teams within a single organization can achieve full isolation, but they overlook that credentials and inventories are organization-scoped and can still be accessed by users from other teams if permissions are not meticulously restricted, and that credential 'view' permissions are separate from 'use' permissions.

How to eliminate wrong answers

Option B is wrong because user-level permissions without organizations or teams do not scale for multi-tenant environments and cannot enforce credential isolation at the organizational boundary. Option C is wrong because a single organization with three teams does not provide sufficient resource isolation; projects, inventories, and credentials would still be visible across teams unless explicitly restricted, and credential viewing cannot be fully prevented at the job template level. Option D is wrong because setting credentials to 'read-only' does not prevent users from viewing the credential values; read-only only prevents editing, not viewing secret fields, and a single team with admin permissions violates the RBAC mandate entirely.

Practice this question →
26
Multi-Selecthard

An organization has multiple automation controller clusters spread across different geographic regions. The security policy requires that job artifacts (such as logs and assets) must remain in the region where the job ran. Which THREE configurations support this requirement? (Choose exactly three.)

Select 3 answers
A.Disable the 'Enable remote logging' option in the controller configuration for each cluster.
B.Use a custom execution environment that writes artifacts to a network share.
C.Assign each cluster its own inventory and restrict node membership to that region's hosts.
D.Set the 'local' execution node for each cluster and configure the controller to store artifacts on the local filesystem.
E.Configure automation mesh to route jobs to the nearest execution node.
AnswersA, C, D

Remote logging would send logs to a central server, violating regional retention.

Why this answer

Option A is correct because disabling 'Enable remote logging' in the controller configuration ensures that job artifacts (logs, assets) are stored locally on the controller's filesystem rather than being forwarded to an external logging server. This directly enforces the regional data residency requirement by preventing artifacts from leaving the geographic region where the controller cluster resides.

Exam trap

Red Hat often tests the misconception that execution node placement alone (via automation mesh) guarantees data locality, but candidates forget that artifact storage configuration is a separate control that must be explicitly set.

Practice this question →
27
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

This command decrypts the file to a temporary file, opens an editor, and re-encrypts it when saved, minimizing exposure.

Why this answer

Option A is correct because `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 →
28
MCQmedium

An Ansible automation controller job template uses a custom credential type that requires a secret token. The token is stored as an extra variable in the job template definition. A security audit reveals the token is visible in plaintext in the job output. Which action should the administrator take to secure the secret?

A.Define the variable in the job template's 'extra variables' field with 'no_log: true' set in the playbook for that variable.
B.Vault-encrypt the variable in the playbook and reference it with {{ vault_var }}.
C.Create a custom credential type that injects the token as an environment variable, and remove the extra variable from the job template.
D.Store the token in a file on the controller with 600 permissions and use 'lookup' in the playbook.
AnswerA

Setting no_log on the variable prevents it from being displayed in logs and job output, meeting the security requirement.

Why this answer

Option A is correct because setting `no_log: true` on the variable in the playbook prevents Ansible from printing the value of that variable in any output, including job logs. This is the standard method to hide sensitive data like tokens when they are passed as extra variables, as it works at the task level to suppress logging of the variable's content.

Exam trap

The trap here is that candidates often assume vault encryption alone hides secrets in output, but vault only encrypts at rest; Ansible decrypts at runtime and the plaintext can still appear in logs unless `no_log` is explicitly set.

How to eliminate wrong answers

Option B is wrong because vault-encrypting the variable in the playbook only protects the data at rest; when the playbook runs, Ansible decrypts it and the plaintext value can still appear in job output unless `no_log` is also used. Option C is wrong because while injecting the token as an environment variable via a custom credential type is a secure practice, the question states the token is already stored as an extra variable; the correct action to secure the existing setup is to use `no_log`, not to redesign the credential type. Option D is wrong because storing the token in a file with 600 permissions and using `lookup` does not prevent the token from being displayed in job output; the `lookup` plugin reads the file and the value can still be logged unless `no_log` is applied.

Practice this question →
29
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

This error means no vault secrets were found to decrypt the file.

Why this answer

The error indicates that Ansible cannot locate vault secrets. This typically happens when the vault password file is missing or incorrect. Options B, C, and D produce different error messages.

Practice this question →
30
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 builds EE from definition.

Why this answer

Option B is correct because `ansible-builder` is the official tool for building custom execution environments, which are container images that include Ansible, collections, and dependencies needed for automation controller jobs. Option E is correct because a Containerfile (or Dockerfile) defines the base image, packages, and Python dependencies required for the custom execution environment, and it is used by `ansible-builder` or directly with `podman build` to create the image.

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 →
31
MCQhard

Your team manages a fleet of 200 Red Hat Enterprise Linux 8 servers. Security policy requires that all servers have a specific set of security configurations: (1) SELinux must be enforcing, (2) the firewall must allow only SSH and HTTPS, (3) SSH root login must be disabled, and (4) the 'auditd' service must be running and enabled. You have created an Ansible role 'security-hardening' that applies these settings. The role is idempotent and uses the 'lineinfile' module to modify /etc/ssh/sshd_config, the 'firewalld' module to configure firewall rules, the 'selinux' module to set SELinux to enforcing, and the 'service' module to enable and start auditd. You run the playbook against a test group of 10 servers, and it reports 'changed=0' for all tasks, indicating the servers are already compliant. However, a subsequent manual audit reveals that on two servers, SELinux is permissive and SSH root login is still permitted. What is the most likely cause of this discrepancy?

A.The 'become' privilege escalation is not configured, so the tasks cannot modify system files.
B.The playbook was run with the '--check' flag, which simulates changes without applying them.
C.The inventory hostnames for those two servers are incorrect, causing Ansible to connect to different hosts that are already compliant.
D.The Ansible modules used in the role are not installed on the control node.
AnswerC

Ansible reported changes on the hosts it connected to, but those are not the actual servers needing changes.

Why this answer

Option C is correct because if the inventory hostnames for the two non-compliant servers are incorrect, Ansible would connect to different hosts that are already compliant, resulting in 'changed=0' for all tasks. The playbook never actually ran against the intended servers, so the manual audit correctly found them non-compliant. This is a common inventory misconfiguration issue where the target hostname does not match the actual server.

Exam trap

The trap here is that candidates assume 'changed=0' means the target servers are compliant, but it actually means the tasks were applied to a different set of hosts due to inventory misconfiguration.

How to eliminate wrong answers

Option A is wrong because if 'become' privilege escalation were not configured, the tasks would fail with a permission error (e.g., 'Permission denied') rather than reporting 'changed=0'. Option B is wrong because running with '--check' would report 'changed=1' for tasks that would make changes, not 'changed=0' for all tasks, and the manual audit would still find the servers non-compliant. Option D is wrong because the Ansible modules used (lineinfile, firewalld, selinux, service) are all core modules included with Ansible Engine/Ansible Core and do not require separate installation on the control node.

Practice this question →
32
MCQeasy

An administrator needs to limit the number of concurrent jobs that can run on a specific automation controller node. Which setting should be adjusted?

A.The forks parameter in the playbook
B.The job template's 'allow simultaneous' option
C.The number of execution environments
D.The max concurrent jobs setting in the node's configuration
AnswerD

Limits jobs on that node.

Why this answer

The correct setting to limit concurrent jobs on a specific automation controller node is the 'max concurrent jobs' parameter in the node's configuration. This setting directly controls how many jobs the node can execute simultaneously, preventing resource exhaustion and ensuring predictable performance. Adjusting this value is the proper method for managing node-level concurrency in Red Hat Ansible Automation Platform.

Exam trap

The trap here is that candidates confuse the 'forks' parameter (task-level parallelism) with node-level job concurrency, or mistakenly think that job template settings like 'allow simultaneous' control node capacity.

How to eliminate wrong answers

Option A is wrong because the 'forks' parameter controls the number of parallel tasks within a single playbook run, not the number of concurrent jobs across the controller. Option B is wrong because the 'allow simultaneous' option in a job template permits multiple runs of the same template at once, but it does not limit overall node concurrency. Option C is wrong because the number of execution environments affects the runtime environment for jobs, not the concurrency limit on a specific node.

Practice this question →
33
MCQeasy

A systems administrator at a growing company uses Red Hat Ansible Automation Platform to manage configuration of web servers. They have a job template named 'Web Server Config' that runs a playbook to apply security hardening. The playbook includes variables encrypted with Ansible Vault using the default vault ID. The administrator has created a credential of type 'Ansible Vault Password' in Automation Controller and assigned it to the job template. When the job runs, it fails with the error: 'Decryption failed (no vault secrets would be found that would decrypt)'. However, other job templates that use the same vault credential run successfully. The administrator checks that the vault password is correct and that the credential is properly assigned. They also verify that the playbook's path is correct and the inventory is populated. What is the most likely cause of the failure?

A.The playbook references a different vault id than the one in the credential.
B.The playbook has a syntax error.
C.The vault password file is missing from the controller.
D.The vault credential is not assigned to this specific job template.
AnswerA

The error indicates no vault secrets found, meaning the vault id in the playbook does not match any provided vault secret.

Why this answer

Since other job templates with the same credential succeed, the credential is valid and assigned. The error 'no vault secrets would be found' typically occurs when the playbook references a vault id that was not provided. The most likely cause is a vault id mismatch between the playbook and the credential.

Practice this question →
34
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

Capacity limits cause jobs to wait in pending state.

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 →
35
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 ID must match if used during encryption.

Why this answer

Option D is correct because Ansible vault supports multiple vault IDs (labels) to manage different passwords for different encrypted files. If the vault ID used during decryption does not match the one used when encrypting the file, Ansible will fail to decrypt it, even if the correct password is provided. The `--vault-id` option or `ANSIBLE_VAULT_ID_MATCH` environment variable must align the ID with the encryption context.

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 →
36
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

Encrypts a single string inline.

Why this answer

Option D is correct because `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 →
37
MCQmedium

An administrator is configuring a job template in automation controller that runs a playbook to deploy a web application. The playbook requires a database password that changes quarterly. To avoid updating the credential each quarter, what is the best approach to dynamically provide the password without exposing it in the playbook?

A.Use a lookup plugin to fetch the password from an external secrets manager.
B.Store the password as a variable in the project repository and encrypt it with ansible-vault.
C.Define a survey prompt in the job template that asks for the password during launch.
D.Create a custom credential type that prompts for the password each launch.
AnswerC

Survey prompts allow dynamic input without storing the password in the playbook.

Why this answer

Option C is correct because a survey prompt in the job template allows the password to be entered at launch time, avoiding hardcoding or storing it in the playbook or project. This approach dynamically provides the password each quarter without requiring credential updates, as the survey can be configured to prompt for the password as a variable that the playbook uses. It aligns with automation controller's built-in survey feature for secure, runtime variable input.

Exam trap

The trap here is that candidates often confuse survey prompts with custom credential types, assuming that a custom credential type is the only way to prompt for input at launch, but surveys are the native and simpler mechanism for runtime variable input in job templates.

How to eliminate wrong answers

Option A is wrong because lookup plugins fetch data at playbook runtime from external sources, but they require the automation controller to have network access and authentication configured to the secrets manager, which adds complexity and does not inherently avoid credential updates if the password changes quarterly. Option B is wrong because storing the password as an ansible-vault encrypted variable in the project repository still requires updating the vault file each quarter when the password changes, which contradicts the goal of avoiding updates. Option D is wrong because a custom credential type that prompts for the password each launch is essentially a survey-like mechanism but is overly complex for a single variable; it is designed for injecting multiple credential fields, not for a simple runtime prompt, and still requires defining the credential type in the controller.

Practice this question →
38
MCQmedium

A workflow template in automation controller consists of three job templates that must run sequentially with different credentials. The first job template uses a machine credential to provision a VM, the second uses a network credential to configure the switch, and the third uses a cloud credential to deploy the application. To secure the credential usage, what should the administrator configure?

A.Create a single credential that covers all three environments.
B.Set each job template to use the appropriate credential and ensure workflow node permissions are set to 'use credential'.
C.Define credential validation rules in the workflow node properties.
D.Assign all three credentials to the workflow template directly.
AnswerB

Each job template uses its own credential; workflow nodes inherit those credentials.

Why this answer

Each job template can have its own credential defined. The workflow template does not directly hold credentials; it uses the credentials assigned to each job template. Option A (assign to workflow) is not possible.

Option C (single credential) is not appropriate. Option D (validation rules) does not exist.

Practice this question →
39
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

Allows launching and viewing output, but not modifying the job template.

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 →
40
MCQhard

Refer to the exhibit. A playbook fails with the above error when using ansible-vault. What is the most likely cause?

A.The file is not encrypted with ansible-vault.
B.The vault password file is missing.
C.The vault id used in the playbook does not match the one used to encrypt the file.
D.The user does not have read permissions on the file.
AnswerC

The error states 'for vault id default', which suggests the vault id is mismatched.

Why this answer

The error specifically mentions vault id 'default', indicating that the file was encrypted with a different vault id or the password for the default id is wrong. The most common cause is a mismatch between the vault id used in the playbook and the one used to encrypt the file.

Practice this question →
41
Multi-Selecthard

An organization uses automation controller with multiple projects and teams. They want to enforce that only the operations team can run job templates that make changes in production, while the development team can only run job templates that deploy to development environments. Which three components should be configured to achieve this? (Choose three.)

Select 3 answers
A.Assign different credentials to each job template.
B.Create separate job templates for production and development.
C.Define team roles for each job template.
D.Set execution environments to be team-specific.
E.Use a workflow template that routes based on user role.
AnswersA, B, C

Ensures only appropriate credentials are used.

Why this answer

Option A is correct because credentials in automation controller (formerly Ansible Tower/AWX) define the authentication context for a job template. By assigning different credentials (e.g., SSH keys or cloud API tokens) to production and development job templates, you can enforce that only the operations team's credentials have access to production infrastructure, while the development team's credentials are restricted to development environments. This is a fundamental access control mechanism that ties authentication directly to job execution.

Exam trap

The trap here is that candidates confuse execution environments (which are runtime containers) with access control mechanisms, or assume workflow templates can dynamically route based on user roles, when in fact RBAC is static and defined per object.

Practice this question →
42
MCQmedium

A playbook using the 'uri' module is timing out when connecting to an external API. The network team confirms connectivity. What Ansible configuration parameter can be adjusted to increase the timeout?

A.validate_certs
B.retries
C.ansible_timeout
D.delay
AnswerC

Sets the timeout for connections.

Why this answer

Option C is correct because `ansible_timeout` is an Ansible configuration parameter that controls the default socket-level timeout for network connections, including those made by the `uri` module. When an external API is slow to respond, increasing this value (default 10 seconds) allows the playbook to wait longer before aborting the connection attempt.

Exam trap

The trap here is that candidates confuse `ansible_timeout` with module-specific parameters like `retries` or `delay`, thinking those control the initial connection timeout when they actually only affect behavior after a failure.

How to eliminate wrong answers

Option A is wrong because `validate_certs` controls SSL certificate verification, not connection timeout; disabling it would bypass certificate checks but not extend the wait time. Option B is wrong because `retries` is a parameter for the `uri` module that controls how many times to retry a failed request, but it does not affect the initial connection timeout; retries only apply after a failure occurs. Option D is wrong because `delay` is a parameter for the `uri` module that specifies the time to wait between retries, not the initial connection timeout; it only matters if retries are configured.

Practice this question →
43
Multi-Selectmedium

An automation controller administrator needs to limit access to a sensitive inventory. Which two methods can be used to restrict access to that inventory? (Choose two.)

Select 2 answers
A.Assign the 'admin' role to the inventory and grant it only to specific users.
B.Place the inventory in an organization and assign appropriate roles to users and teams.
C.Use a custom role with read-only permissions on the inventory.
D.Encrypt the inventory with ansible-vault and share the vault password only with authorized users.
E.Set the inventory to 'private' in the inventory settings.
AnswersB, C

Organization RBAC controls access at the inventory level.

Why this answer

In Ansible Automation Platform, access to inventories is managed through Role-Based Access Control (RBAC) within organizations. Placing the inventory in an organization allows administrators to assign specific roles (e.g., Admin, Execute, Read) to users or teams, effectively restricting access. Additionally, using a custom role with read-only permissions ensures that users can view the inventory but cannot modify or delete it, providing a fine-grained access control mechanism.

Exam trap

The trap here is that candidates often confuse ansible-vault encryption (which protects data at rest or in transit) with RBAC access control (which governs who can view or modify resources in the controller), leading them to select Option D as a valid method for restricting inventory access.

Practice this question →
44
MCQeasy

An organization requires that all Ansible playbooks be executed using a specific service account that has limited permissions. The account can only run playbooks from a specific directory. Which approach best enforces this requirement in automation controller?

A.Use an inventory that contains only the allowed hosts.
B.Configure an execution environment that mounts the authorized directory as read-only.
C.Create a project that syncs only the authorized directory, and assign the service account as the only user with execute permissions on that project.
D.Assign the service account a machine credential that connects to the controller via SSH.
AnswerC

Projects control source of playbooks; RBAC can restrict execution to that project.

Why this answer

Option C is correct because Automation Controller (formerly Ansible Tower) uses Projects to manage playbook source code. By creating a Project that syncs only the authorized directory and assigning the service account as the only user with execute permissions on that Project, you restrict the service account to running playbooks exclusively from that directory. This enforces the requirement at the platform level, leveraging role-based access control (RBAC) within the controller.

Exam trap

The trap here is that candidates confuse execution environments (containers) with project-level access controls, or mistakenly think inventory or credentials can restrict which playbook directory is used, when in fact only Project permissions enforce that restriction in Automation Controller.

How to eliminate wrong answers

Option A is wrong because an inventory defines which hosts to target, not which playbooks or directories the service account can execute; it does not restrict the playbook source location. Option B is wrong because execution environments are container images that provide runtime dependencies, not directory access controls; mounting a directory as read-only does not prevent the service account from running playbooks from other directories within the controller. Option D is wrong because a machine credential is used for SSH authentication to managed nodes, not for controlling which playbooks or directories the service account can access in Automation Controller.

Practice this question →
45
MCQeasy

A systems administrator needs to securely store a database password for use in an Ansible playbook. The password should be encrypted at rest and decrypted only at runtime when the playbook is executed. Which approach should the administrator take?

A.Store the password as a plain text variable in the playbook and use the no_log: yes directive to prevent logging.
B.Use the ansible-vault encrypt_string command to encrypt the password and store it in a variables file.
C.Store the password in an unprotected external file and reference it with include_vars.
D.Save the password in an environment variable and access it via lookup('env','DB_PASS').
AnswerB

Encrypts the password at rest; decrypted at runtime with vault password.

Why this answer

Using ansible-vault encrypt_string is the standard method to encrypt sensitive data. Option A (no_log) hides output but the password is still in plain text. Option C (unprotected file) is insecure.

Option D (environment variable) can be seen in process listings.

Practice this question →
46
MCQmedium

An Ansible playbook is failing due to an undefined variable. Which approach would best help identify the source of the variable?

A.Add the 'ignore_errors: yes' directive
B.Set environment variable ANSIBLE_DEBUG=1
C.Add a debug task with var: hostvars[inventory_hostname]
D.Use the --syntax-check flag
AnswerC

Displays all host variables, helping locate undefined.

Why this answer

Option C is correct because adding a debug task with `var: hostvars[inventory_hostname]` dumps all variables for the current host, including those inherited from group_vars, host_vars, and play-level vars. This allows you to inspect the full variable namespace and identify which variable is undefined or missing, directly addressing the root cause of the failure.

Exam trap

The trap here is that candidates confuse syntax checking (--syntax-check) with runtime variable validation, or they think enabling debug mode (ANSIBLE_DEBUG=1) will magically reveal variable issues, when in fact only a targeted variable dump can show the actual defined values.

How to eliminate wrong answers

Option A is wrong because 'ignore_errors: yes' only suppresses task failure output; it does not resolve or diagnose an undefined variable error, which will still cause the playbook to fail unless the variable is defined. Option B is wrong because setting ANSIBLE_DEBUG=1 increases verbosity for debugging Ansible internals (e.g., SSH connections, module execution) but does not specifically help locate an undefined variable in your playbook or inventory. Option D is wrong because '--syntax-check' only validates YAML syntax and basic playbook structure; it does not evaluate variable definitions or runtime variable resolution.

Practice this question →
47
MCQeasy

Refer to the exhibit. An automation job failed with the given error. What is the most likely cause?

A.The playbook syntax is incorrect
B.The SSH port is blocked
C.The remote host is unreachable
D.The SSH key is not authorized for the remote user
AnswerD

Permission denied (publickey) indicates key not accepted.

Why this answer

The error message indicates an SSH authentication failure, which occurs when the SSH key presented by the control node is not authorized for the remote user's account. This is the most likely cause because Ansible relies on SSH key-based authentication by default, and a missing or mismatched public key on the remote host will prevent the connection.

Exam trap

The trap here is that candidates often confuse SSH authentication failures with network connectivity issues, but the specific 'Permission denied (publickey)' error clearly points to key authorization, not reachability or port blocking.

How to eliminate wrong answers

Option A is wrong because the error message does not indicate a YAML syntax or playbook structure issue; such errors would be caught during playbook parsing and would show a different message. Option B is wrong because a blocked SSH port (default 22) would result in a 'Connection refused' or 'No route to host' error, not an authentication failure. Option C is wrong because an unreachable host would produce a 'Name or service not known' or 'Network is unreachable' error, not an SSH authentication error.

Practice this question →
48
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

Encrypts sensitive variables at rest.

Why this answer

Option A is correct because `ansible-vault` encrypts variable files at rest using AES-256, allowing sensitive data like passwords or API keys to be stored securely in version control. When a playbook runs, the vault password must be provided (e.g., via `--ask-vault-pass` or a vault password file), and Ansible decrypts the file in memory only, never writing plaintext to disk. This ensures that sensitive values are not exposed in the playbook source code or logs.

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