Select Two (Multi-Select) Questions

Execution environments cannot be used with ansible-playbook directly.

Why it fails: Execution environments are container images consumed by ansible-playbook through the ansible-navigator or ansible-runner interface, so they can be used with ansible-playbook when container support is configured. The statement is tempting because execution environments do replace the legacy Python virtual environment workflow for many playbook runs.

Execution environments must be built using ansible-builder.

Why it fails: ansible-builder is the standard tool for constructing execution environments, but they can also be assembled manually with podman or docker build using a Containerfile. It is tempting because ansible-builder is the documented, supported method and the one most exam candidates encounter when creating custom execution environments.

Ansible Navigator is required to use execution environments.

Why it fails: Ansible Navigator is one supported way to consume execution environments, but ansible-runner and AWX or automation controller also run them, so it is not required. It is tempting because Navigator is the default CLI bundled with Ansible Automation Platform and is commonly demonstrated alongside execution environments in documentation.

Lookup plugins are always executed on the remote host.

Why it fails: Lookup plugins run on the control node.

Lookup plugins must be imported using the "lookup" keyword.

Why it fails: They are invoked via the lookup function, not imported.

The "file" lookup plugin reads the content of a file from the remote host.

Why it fails: The file lookup reads from the control node.

Use the debug module with verbosity to output passwords.

Why it fails: Verbose debug output writes task variables, including passwords, into plaintext logs and console history, exposing the very secrets the playbook should conceal. It is tempting because debug with verbosity is genuinely useful for troubleshooting variable values and task flow during development, but never for secret-bearing tasks.

Avoid using become: yes on tasks that access secrets.

Why it fails: Privilege escalation is orthogonal to secret protection: become controls which remote user runs a task, not whether vault-encrypted variables or no_log keep credentials out of logs. It is tempting because least privilege is a real hardening aim, but it belongs to access control, not to protecting sensitive data in playbooks.

Store credentials in plain text in the inventory.

Why it fails: Plaintext inventory credentials are readable by anyone with file access, so they cannot protect sensitive data. It is tempting because a static inventory is the quickest way to define hosts and connection variables, and it would be acceptable only in a disposable lab with no real secrets.

Storing the execution environment in a public registry only

Why it fails: Automation controller pulls execution environment images from private automation hub, registry.redhat.io or an internal registry; public-only storage ignores air-gapped and access-controlled deployments. It is tempting because public registries are convenient, but they cannot host organisation-specific, authenticated images.

Setting the execution_environment_image in the project's SCM

Why it fails: The execution environment image is defined on the job template or in the automation controller's execution environment configuration, not in project SCM. It is tempting because SCM holds playbooks and inventories, but execution_environment_image is not a valid project-level variable.

Using the default execution environment provided by controller

Why it fails: The default execution environment ships with automation controller and lacks the collections, Python libraries or system packages a custom job requires. It is tempting as a zero-configuration baseline, but the question asks about configuring a custom execution environment, which the default cannot satisfy.

The automation hub requires an external PostgreSQL database to store collections and execution environments.

Why it fails: Automation hub in a highly available deployment uses the platform's internal PostgreSQL rather than requiring an external database; only automation controller needs external PostgreSQL for HA. It is tempting because external databases are genuinely required for controller HA, making the statement plausible for the wrong component.

Execution nodes must have direct network access to the automation controller database.

Why it fails: Execution nodes run job containers and only need reachability to the controller's receptor and execution mesh endpoints, not the PostgreSQL database; that direct connection is required by the controller's own nodes. It is tempting because execution nodes do consume controller-issued work, but database access is confined to controller and database hosts in a HA topology.

The automation controller can use an embedded SQLite database for production deployments.

Why it fails: SQLite is a single-file, single-writer engine that cannot support the concurrent writes and replication a HA controller cluster demands; production deployments require an external PostgreSQL database. It is tempting because SQLite is the zero-configuration default for quick development installs, where no redundancy or horizontal scaling is needed.

In the 'extra_vars' field of the job template.

Why it fails: Extra_vars are runtime overrides, not inventory definition.

In a credential's 'Input Configuration' as a secret variable.

Why it fails: Credentials define authentication, not host variables.

include_vars

Why it fails: include_vars loads external variable data into a play, not task files, so it cannot import tasks. It is tempting because it is an include-style module that pulls external content at runtime, and would be correct when you need to read variables from a separate YAML or JSON file.

add_host

Why it fails: add_host dynamically adds a host to the in-memory inventory during a play; it cannot pull external task files into a playbook. It is tempting because it does extend a play at runtime, and would be correct when you need to register newly provisioned hosts so subsequent plays target them.

include_role

Why it fails: include_role imports a role's tasks, handlers and defaults as a unit; it does not include a standalone external task file. It is tempting because it does pull external task content, and would be correct when reusing a packaged, structured role rather than a loose list of tasks.

Collections can be installed only from Galaxy.

Why it fails: Collections can also be installed from Automation Hub, private automation hub, Git repositories, or local tarballs via ansible-galaxy, so 'only from Galaxy' is false. Galaxy is the default public source, making it the tempting answer when no other repository is configured.

The collection name must be a single word without namespace.

Why it fails: Collection names use a namespace.collection format, for example ansible.builtin, so a single word without namespace is invalid. The temptation comes from older standalone role names, which were single words, but collections require the namespace prefix.

A collection can contain only roles and playbooks.

Why it fails: Collections bundle roles, playbooks, plugins, modules and documentation, so restricting them to roles and playbooks is false. The temptation arises because roles and playbooks are the most visible content, yet plugins and modules are equally valid collection members.

It eliminates the need for an inventory file.

Why it fails: ansible-pull still requires an inventory or localhost target.

It supports a different syntax for playbooks that is more efficient.

Why it fails: ansible-pull uses standard playbook syntax.

It reduces load on the control node because it runs locally on each node.

Why it fails: ansible-pull runs on the managed node, not the control node.

Use 'strategy: free' to allow hosts to run tasks independently.

Why it fails: Free strategy lets each host proceed through the whole play without waiting, so hosts update concurrently rather than in controlled batches, defeating the serial ordering rolling updates require. It is tempting because free strategy shortens total runtime, and it is correct for independent, non-coordinated tasks across many hosts.

Use 'gather_facts: no' to speed up the playbook.

Why it fails: Disabling fact gathering removes the variables rolling updates depend on, such as host-specific values used in conditionals and templates, so per-host decisions break. It is tempting because skipping setup does cut runtime on large inventories, and it is correct when a playbook genuinely needs no host data.

Set 'any_errors_fatal: true' to stop the update on the first failure.

Why it fails: Any_errors_fatal aborts the entire play for all hosts on the first failure, so remaining batches never update, leaving the fleet split across versions. It is tempting because halting on failure sounds safe, and it is correct when a single failure must stop a tightly coupled deployment entirely.

Each inventory source can be assigned to multiple inventories.

Why it fails: An inventory source belongs to exactly one inventory.

Custom inventory scripts must be placed in the Tower home directory.

Why it fails: Custom scripts can be stored in projects.

Avoid using external secret management systems; keep all secrets in Automation Controller

Why it fails: External secret managers are recommended for better security and rotation.

Share the same credential across multiple organizations for simplicity

Why it fails: This violates the principle of least privilege.

"fields": [{"id": "password", "type": "string", "label": "Password"}]

Why it fails: Not needed when using SSH key authentication.

"fields": [{"id": "key_type", "type": "string", "label": "Key Type"}]

Why it fails: Unnecessary additional field.

In the ansible.cfg file.

Why it fails: ansible.cfg does not support variable definitions for playbooks.

In the role's vars/main.yml.

Why it fails: Role vars are only available within that role's scope.

Use a single instance of PostgreSQL on the controller node.

Why it fails: One PostgreSQL instance on the controller node cannot fail over, so a database or node outage takes the whole platform down. A single local database suits standalone development installs, whereas high availability needs an external, replicated PostgreSQL cluster shared by multiple controllers.

Installation on a single powerful node.

Why it fails: A single node is a single point of failure: any hardware or service fault halts the entire Automation Platform with no failover target. One powerful node suits lab, test or small non-critical deployments where uptime guarantees are absent.

Store all secrets in the Automation Platform vault.

Why it fails: Vault secret storage protects credentials at rest; it does nothing to keep automation services running when a controller or database node fails. Vault is the right control for centralised secret management and rotation, but high availability requires redundant controller and database nodes instead.

pattern

Why it fails: Incorrect: pattern is not a parameter of service module.

runlevel

Why it fails: Incorrect: runlevel is used by other modules, not service.

Vault-encrypted files cannot be used with include_vars.

Why it fails: They can be used if vault password is provided.

Vault uses AES-128 encryption by default.

Why it fails: It uses AES-256.

Vault passwords can be stored directly in ansible.cfg.

Why it fails: Only a path to a password file can be configured.

Collections cannot contain playbooks.

Why it fails: Collections may bundle playbooks alongside roles, plugins and modules, so this statement is false. It is tempting because collections are most commonly distributed for their roles and plugin content, which can make playbooks appear outside their scope, yet the collection directory structure explicitly permits a playbooks directory.

A role stored in a collection can be referenced by its short name without the collection prefix.

Why it fails: Roles inside a collection must be referenced using the fully qualified collection name, such as namespace.collection.role_name, so the short name alone fails to resolve. It is tempting because standalone roles in roles/ are called by short name, and that habit carries over incorrectly once the role moves into a collection.

Execution environments are required to use collections.

Why it fails: Execution environments are containers that package collections with their dependencies, but collections install and run without them via ansible-galaxy and standard Python environments. It is tempting because automation controller and AWX workflows commonly pair collections with execution environments, making the two appear inseparable.

Use `any_errors_fatal: true` to stop the playbook if any host fails.

Why it fails: This would halt the entire update on the first failure, which is not desirable for a rolling update where individual host failures are acceptable.

Use `throttle: 1` to limit the number of concurrent tasks across all hosts.

Why it fails: Throttle limits task concurrency but does not control the batch size within a rolling update; it is not a substitute for serial.

Use `async` and `poll` to run the update tasks in the background while proceeding to the next host immediately.

Why it fails: Async is not appropriate because the update must complete before the host is re-enabled; background execution could lead to premature re-enablement.

All credentials must be stored within the AAP database for security

Why it fails: External secret backends can be used for enhanced security.

Playbooks should contain hardcoded credentials for simplicity

Why it fails: Hardcoding credentials is insecure and against best practices.