Courseiva

CCNA Create content collections and execution environments Questions

64 questions · Create content collections and execution environments · All types, answers revealed

Practice these questionsDomain overviewAll questions
1
MCQeasy

Based on the exhibit, which file is generated by `ansible-builder` to support the build?

A.requirements.yml
B.execution-environment.yml
C.Containerfile
D.ansible.cfg
AnswerC

`ansible-builder` generates a Containerfile (the Podman/Buildah equivalent of a Dockerfile) that defines the execution environment image build. It satisfies the stem's requirement by producing this build recipe from `execution-environment.yml`, which `ansible-builder build` then passes to Podman or Buildah to assemble the image.

Why this answer

The `ansible-builder` tool uses a definition file (typically `execution-environment.yml`) to construct a container image. During the build process, it generates a `Containerfile` (or `Dockerfile`) that contains the exact instructions for building the container image, such as base image selection, package installation, and collection inclusion. This generated file is the actual artifact that the container runtime (e.g., Podman or Docker) uses to create the execution environment image.

Exam trap

Red Hat often tests the distinction between the input definition file (`execution-environment.yml`) and the output build artifact (`Containerfile`), causing candidates to mistakenly select the input file as the generated output.

How to eliminate wrong answers

Option A is wrong because `requirements.yml` is an input file used to specify Ansible collections or Python dependencies for an execution environment, not a file generated by `ansible-builder` during the build process. Option B is wrong because `execution-environment.yml` is the definition file that you provide to `ansible-builder` as input, describing the base image, dependencies, and other settings; it is not generated by the tool. Option D is wrong because `ansible.cfg` is a configuration file for Ansible itself, controlling settings like inventory, roles path, and connection parameters, and it has no direct role in the `ansible-builder` build process.

Practice this question →
2
MCQeasy

Which command publishes a collection to Automation Hub?

A.ansible-galaxy collection import ./namespace-name-1.0.0.tar.gz
B.ansible-galaxy collection upload ./namespace-name-1.0.0.tar.gz
C.ansible-galaxy collection push ./namespace-name-1.0.0.tar.gz
D.ansible-galaxy collection publish ./namespace-name-1.0.0.tar.gz --token MYTOKEN
AnswerD

The ansible-galaxy collection publish subcommand uploads the built tarball to Automation Hub, authenticating with the API token via --token. This satisfies the requirement to push a collection artefact to the Hub, since the tarball must already exist before publishing.

Why this answer

`ansible-galaxy collection publish` is the specific command used to upload a collection tarball to Automation Hub (or any Galaxy server). The `--token` flag provides the required API authentication token for the publish operation. This command sends the tarball to the server's API endpoint, which validates and imports the collection.

Exam trap

The trap here is that candidates confuse the `ansible-galaxy role push` command (used for roles) with the collection workflow, mistakenly assuming 'push' or 'upload' are valid for collections, when only `publish` is correct.

How to eliminate wrong answers

Option A is wrong because `ansible-galaxy collection import` is not a valid command; the correct command for importing a collection from a source (like a Git repository) is `ansible-galaxy collection build` followed by `publish`, and `import` is used for roles, not collections. Option B is wrong because `ansible-galaxy collection upload` does not exist; the verb 'upload' is not used in the Ansible Galaxy CLI for collections. Option C is wrong because `ansible-galaxy collection push` is not a valid subcommand; 'push' is used with `ansible-galaxy role` (e.g., `ansible-galaxy role push`), not for collections.

Practice this question →
3
Multi-Selecthard

Which THREE components are typically included in an execution environment?

Select 3 answers
A.Base OS image
B.Ansible Navigator
C.Ansible Core and collections
D.Python interpreter and dependencies
E.Ansible Tower/AWX
AnswersA, C, D

Every execution environment is built FROM a base OS image, which supplies the filesystem, package manager and libraries upon which the Ansible runtime and Python dependencies are layered. It forms the foundational layer of the container definition.

Why this answer

An execution environment is a container image that bundles everything needed to run Ansible automation, so option A (Base OS image) is correct because the container must be built on a base operating system layer such as a UBI or Debian image. Option C (Ansible Core and collections) is correct because the execution environment packages ansible-core together with the required collections so playbooks and roles have their modules and plugins available. Option D (Python interpreter and dependencies) is correct because Ansible runs on Python, and the environment must include the Python interpreter plus any Python libraries the modules and collections depend on.

Option B (Ansible Navigator) is not included; it is a separate command-line tool used to build, run, and inspect execution environments, not a component inside them. Option E (Ansible Tower/AWX) is not included either, since AWX and Tower are automation controller platforms that consume execution environments rather than being packaged within one.

Exam trap

Red Hat often tests the distinction between tools that manage execution environments (like Ansible Navigator) versus components that are actually inside the execution environment, leading candidates to mistakenly include Navigator or Tower/AWX as part of the image.

Practice this question →
4
MCQmedium

An automation engineer is preparing an execution environment for a project that requires the `community.general` collection and the `netaddr` Python library. The engineer has created an `execution-environment.yml` file in the project directory. Which command should be used to build the execution environment image?

A.ansible-galaxy collection build
B.ansible-navigator build execution-environment.yml
C.podman build -t my-ee:latest .
D.ansible-builder build --file execution-environment.yml
AnswerD

The `ansible-builder build` command reads the execution environment definition file (by default `execution-environment.yml` in the current directory) and builds a container image. The `--file` flag can explicitly specify the definition file, though it is optional when the file has the default name. This command is the standard way to create an execution environment image from a definition.

Why this answer

The `ansible-builder build` command is the correct tool to create an execution environment image from an `execution-environment.yml` definition. It parses the definition, installs collections and Python dependencies, and produces a container image. Other commands like `ansible-galaxy collection build` or `podman build` serve different purposes and do not automate the execution environment creation process.

Exam trap

The trap here is confusing the collection packaging command `ansible-galaxy collection build` with the execution environment build command `ansible-builder build`.

Practice this question →
5
MCQeasy

An administrator is creating a new execution environment and wants to use a minimal base image provided by Red Hat that includes `ansible-core` and essential Python libraries. Which base image should be specified in the `execution-environment.yml` file?

A.`quay.io/ansible/ansible-runner:latest`
B.`registry.redhat.io/ansible-automation-platform-23/ee-minimal-rhel8:latest`
C.`registry.access.redhat.com/ubi8/ubi:latest`
D.`docker.io/library/python:3.9-slim`
AnswerB

Red Hat provides minimal execution environment base images under the `ansible-automation-platform` namespace. The `ee-minimal-rhel8` image includes `ansible-core` and essential Python libraries, optimized for building custom execution environments. It is maintained and supported by Red Hat. Specifying this image as the base ensures a minimal footprint and compatibility with Ansible Automation Platform.

Why this answer

Red Hat offers minimal execution environment base images specifically designed for Ansible Automation Platform. The `ee-minimal-rhel8` image includes `ansible-core` and required Python libraries, providing a supported and optimized foundation. Other images either lack Ansible components or are not minimal for this purpose.

Using the Red Hat-provided minimal image simplifies the build and ensures compatibility.

Exam trap

The trap here is assuming any UBI or Python image is sufficient as a base for an execution environment, when Red Hat provides a dedicated minimal EE base image.

Practice this question →
6
Multi-Selecteasy

Which TWO factors should be considered when choosing a base container image for an execution environment?

Select 2 answers
A.The date of the last update.
B.The presence of ansible-core and ansible-runner.
C.The size of the image.
D.The base operating system version.
E.The number of layers.
AnswersB, D

A suitable base image must already provide ansible-core and ansible-runner, since execution environments rely on these to execute playbooks and communicate with the controller. Choosing an image lacking them forces manual installation and risks version incompatibilities.

Why this answer

Option B is correct because an execution environment must contain ansible-core and ansible-runner to actually execute Ansible playbooks and roles; without these packages the image cannot function as an automation execution environment. Option D is correct because the base operating system version determines package availability, supported Python versions, and compatibility with the ansible-core and collection dependencies you install, so it must be chosen deliberately. Option A is not a primary selection factor because a recent update date alone does not guarantee the required Ansible tooling or OS compatibility.

Option C is not a primary factor because image size affects pull time and storage but does not determine whether the environment can run Ansible content. Option E is not a primary factor because the number of layers is an optimization detail, not a functional requirement for an execution environment.

Exam trap

Red Hat often tests the misconception that image size or layer count are critical selection criteria, when in fact the mandatory technical requirement is the presence of `ansible-core` and `ansible-runner` to ensure the container can actually run Ansible jobs.

Practice this question →
7
Drag & Dropmedium

Drag and drop the steps to configure SELinux to allow Apache to read a custom web directory in the correct order.

Drag or tap steps into the slots.

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

Why this order

SELinux for web: create dir, set context, verify, configure Apache, restart and test.

Practice this question →
8
MCQeasy

An automation engineer has written a custom Ansible role called `db_deploy` and wants to package it inside a new collection named `acme.database`. Which command initializes the collection skeleton with the correct directory layout for roles, modules, and plugins?

A.ansible-galaxy role init acme.database
B.ansible-galaxy collection init acme.database
C.ansible-galaxy collection build acme.database
D.ansible-galaxy collection install acme.database
AnswerB

The `ansible-galaxy collection init` subcommand scaffolds a new collection directory tree containing `plugins/`, `roles/`, `docs/`, `meta/`, and a `galaxy.yml` manifest. Running it with `acme.database` creates `acme/database/` with the namespace and name already populated in `galaxy.yml`, which is exactly what is needed before dropping the `db_deploy` role into the `roles/` directory.

Why this answer

Scaffolding a new collection requires the dedicated `ansible-galaxy collection init` subcommand, which generates the namespace/name directory tree plus a `galaxy.yml` manifest. Role initialization, building, and installing all operate on artifacts that already exist and therefore cannot produce the initial skeleton needed before a custom role is placed under `roles/`.

Exam trap

The trap here is confusing `ansible-galaxy role init` with `ansible-galaxy collection init`, since both create directory skeletons but only one produces a collection manifest and namespace layout.

Practice this question →
9
MCQhard

Refer to the exhibit. A developer builds an execution environment using this execution-environment.yml. After building, the container starts but ansible-navigator cannot connect to the container because the required SSH packages are missing. Which file most likely needs to be updated?

A.The base image itself
B.requirements.yml
C.requirements.txt
D.bindep.txt
AnswerD

bindep.txt declares system-level RPM and DEB packages installed into the execution environment image during build. Missing SSH binaries such as openssh-clients must be listed there, since requirements.yml and requirements.txt cover only collections and Python packages respectively.

Why this answer

D is correct because `bindep.txt` specifies system-level package dependencies (like `openssh-clients` or `sshpass`) that must be installed in the container image. When building an execution environment, `ansible-builder` reads `bindep.txt` to install RPM packages via `dnf` (or `apt` on Debian-based images). If SSH packages are missing, the `bindep.txt` file is the most likely place to add them, as it directly controls which system packages are included in the final image.

Exam trap

Red Hat often tests the distinction between system-level dependencies (`bindep.txt`), Python dependencies (`requirements.txt`), and Ansible collections (`requirements.yml`), and the trap here is that candidates confuse `requirements.txt` (Python packages) with system packages, leading them to incorrectly select option C.

How to eliminate wrong answers

Option A is wrong because the base image itself (e.g., `quay.io/ansible/ansible-runner:latest`) is a pre-built container that already includes Ansible and Python but does not include SSH client packages by default; modifying the base image is not the standard approach—`bindep.txt` is the intended mechanism. Option B is wrong because `requirements.yml` is used to install Ansible collections from Galaxy or Automation Hub, not system packages like SSH clients. Option C is wrong because `requirements.txt` is used to install Python packages via `pip` (e.g., `ansible-core`, `pywinrm`), not RPM-level dependencies like `openssh-clients`.

Practice this question →
10
MCQmedium

Your organization uses Ansible Automation Platform 2.2 with private Automation Hub. You have developed a custom collection named 'my_company.network' that depends on 'cisco.ios' and 'vyos.vyos'. The collection is published in your private hub. You are building an execution environment using ansible-builder. The execution-environment.yml specifies 'EE_BASE_IMAGE: registry.redhat.io/ansible-automation-platform-22/ee-supported-rhel8:latest'. The dependencies section points to a requirements.yml file that includes your collection. When you run 'ansible-builder build', the build succeeds, but when running a playbook that uses modules from 'cisco.ios', you get an error 'module not found'. What is the most likely reason and the correct action to resolve it?

A.Reinstall the collection on the controller node using 'ansible-galaxy collection install'
B.Use a different base image that includes 'cisco.ios'
C.Update the collection metadata to include dependencies and rebuild
D.Add 'cisco.ios' to the requirements.yml file used during the execution environment build
AnswerD

Adding `cisco.ios` to the build-time `requirements.yml` lets ansible-builder resolve and install the transitive dependency into the execution environment image, satisfying the constraint that the module must exist inside the container. Private Automation Hub must host it, since the build pulls collections from configured sources.

Why this answer

The execution environment build process uses the requirements.yml file to determine which collections to include in the image. If the custom collection 'my_company.network' depends on 'cisco.ios', but that dependency is not explicitly listed in the requirements.yml, the builder will not include 'cisco.ios' in the execution environment. Adding 'cisco.ios' to the requirements.yml ensures it is installed during the build, making the module available at runtime.

Exam trap

The trap here is that candidates assume collection dependencies declared in metadata are automatically resolved during the execution environment build, but ansible-builder only installs collections explicitly listed in requirements.yml, not their transitive dependencies.

How to eliminate wrong answers

Option A is wrong because reinstalling the collection on the controller node does not affect the execution environment; the controller uses the execution environment's content, not locally installed collections. Option B is wrong because the base image 'ee-supported-rhel8' already includes many supported collections, but 'cisco.ios' is not guaranteed to be included; the issue is the build process, not the base image selection. Option C is wrong because updating the collection metadata to declare dependencies only affects the collection's metadata, but the execution environment builder does not automatically resolve transitive dependencies from the metadata; it only installs what is explicitly listed in requirements.yml.

Practice this question →
11
MCQhard

Refer to the exhibit. A user attempts to download the collection using the download URL but the signature verification fails. What is the most likely reason?

A.The collection version does not match.
B.The user's client does not have the corresponding public key.
C.The collection is not properly signed.
D.The download URL is invalid.
AnswerB

Signature verification requires the signer's public key imported into the local GPG keyring. Without that corresponding public key, ansible-galaxy cannot validate the detached signature, so verification fails even when the collection archive itself is intact.

Why this answer

B is correct because signature verification of a downloaded collection requires the client to have the corresponding public key that was used to sign the collection. If the user's client lacks this public key, the verification process will fail, even if the collection itself is properly signed and the URL is valid.

Exam trap

Red Hat often tests the misconception that signature verification failures are always due to a corrupted or unsigned collection, when in reality the client-side public key management is a common oversight.

How to eliminate wrong answers

Option A is wrong because a version mismatch would not cause a signature verification failure; it would instead result in a different collection being downloaded or a version conflict error. Option C is wrong because if the collection were not properly signed, the signature verification would fail for that reason, but the question states the user attempts to download using the download URL, implying the collection exists and is signed; the most likely reason is the missing public key on the client side. Option D is wrong because an invalid download URL would prevent the download from starting or return a 404 error, not cause a signature verification failure after the download completes.

Practice this question →
12
MCQmedium

An organization uses a private Automation Hub. A user has configured the server in ansible.cfg. Which command installs a collection from this server?

A.ansible-galaxy collection install my_namespace.my_collection --api-key=mykey
B.ansible-galaxy collection install my_namespace.my_collection --server=https://privatehub.example.com
C.ansible-galaxy collection download my_namespace.my_collection
D.ansible-galaxy collection install my_namespace.my_collection
AnswerD

Once the private Automation Hub server is configured in ansible.cfg, ansible-galaxy resolves the collection from that configured source automatically, so the standard install command with the fully qualified collection name retrieves it without extra flags.

Why this answer

When the Automation Hub server is already configured in ansible.cfg under the [galaxy] section with the server_url and auth_url, the ansible-galaxy collection install command will automatically use that server and its authentication. No additional flags are needed; the command simply specifies the collection name in the format namespace.collection.

Exam trap

The trap here is that candidates may think they need to specify the server URL or API key on the command line, but the EX294 exam expects you to know that the server is pre-configured in ansible.cfg, so only the collection name is required.

How to eliminate wrong answers

Option A is wrong because the --api-key flag is not a valid argument for ansible-galaxy collection install; authentication is handled via the server configuration in ansible.cfg or the GALAXY_TOKEN environment variable, not a command-line API key. Option B is wrong because the --server flag is not a valid option for ansible-galaxy collection install; the server URL is defined in ansible.cfg, not passed as a command-line argument. Option C is wrong because ansible-galaxy collection download is used to download a collection without installing it, not to install it from a configured server.

Practice this question →
13
MCQmedium

You are developing a content collection and need to include a custom Ansible module that requires a specific Python library. The library is not available as a system package and must be installed via pip. Where should you declare this Python dependency so that it is automatically installed when the collection is used in an execution environment?

A.In the galaxy.yml file under the dependencies key, specifying the Python package name.
B.In the module file itself, using a try/except ImportError block to install the library at runtime.
C.In the requirements.txt file within the collection root.
D.In the execution-environment.yml file under the dependencies section with the python option.
AnswerD

The execution-environment.yml file allows you to specify Python packages under the dependencies section using the python key. This tells ansible-builder to install those packages via pip during the execution environment build. This is the correct place to declare Python library dependencies for collections used in the execution environment.

Why this answer

When building an execution environment, Python dependencies can be declared in the execution-environment.yml file under the dependencies section with the python key. This instructs ansible-builder to install the specified Python packages via pip into the execution environment, making them available to modules and plugins that require them.

Exam trap

The trap here is assuming that Python dependencies for a collection can be declared in galaxy.yml or requirements.txt, when in fact the execution environment definition is the correct place for build-time installation.

Practice this question →
14
MCQmedium

An organization uses a private automation hub to distribute collections. A developer has created a new collection and needs to ensure it is available in the hub for others. Which command should the developer use to upload the collection to the private automation hub?

A.ansible-galaxy collection import
B.ansible-galaxy collection build
C.ansible-galaxy collection publish
D.ansible-galaxy collection install
AnswerC

`ansible-galaxy collection publish` uploads a built collection tarball to a Galaxy-compatible repository, satisfying the requirement to distribute it via the private automation hub. It authenticates using the API token configured in `ansible.cfg` or passed with `--api-key`, then pushes the artefact so other developers can install it.

Why this answer

`ansible-galaxy collection publish` is the command specifically designed to upload a built collection artifact (a .tar.gz file) to a Galaxy server, including a private automation hub. This command sends the collection to the configured Galaxy server endpoint, making it available for others to install via `ansible-galaxy collection install`.

Exam trap

The trap here is that candidates confuse `build` (which only creates the artifact) with `publish` (which uploads it), or they mistakenly think `import` is the correct command for uploading a built artifact, when in fact `import` is for source-based imports from a repository.

How to eliminate wrong answers

Option A is wrong because `ansible-galaxy collection import` is used to import a collection from a Git repository or a source distribution into a Galaxy server, but it is not the command for uploading a pre-built collection artifact; it expects a source repository URL or a path to a source directory, not a built .tar.gz file. Option B is wrong because `ansible-galaxy collection build` creates the collection artifact (a .tar.gz file) from the collection source files, but it does not upload or publish it to any server; it only produces the local artifact. Option D is wrong because `ansible-galaxy collection install` downloads and installs a collection from a Galaxy server or a local path, but it does not upload or publish collections to a hub.

Practice this question →
15
MCQhard

The build fails with a DNS resolution error for `registry.redhat.io`. Which troubleshooting step is most likely to resolve the issue?

A.Run `podman login registry.redhat.io` to authenticate.
B.Restart the container runtime service.
C.Verify DNS settings in `/etc/resolv.conf` or configure a custom DNS server for the container runtime.
D.Use the `--no-cache` flag to force a fresh build.
AnswerC

The DNS resolution failure means the container runtime cannot resolve registry.redhat.io, so checking /etc/resolv.conf or configuring a custom DNS server for the runtime restores name resolution. This addresses the constraint directly, unlike authentication or firewall changes.

Why this answer

A DNS resolution error for `registry.redhat.io` indicates that the container runtime (e.g., Podman) cannot resolve the registry's hostname to an IP address. This is a network/DNS issue, not an authentication or caching problem. Verifying or correcting DNS settings in `/etc/resolv.conf` or configuring a custom DNS server for the container runtime directly addresses the root cause by ensuring the host or container runtime can resolve the registry's FQDN.

Exam trap

The trap here is that candidates confuse DNS resolution errors with authentication or cache issues, leading them to choose `podman login` or `--no-cache` instead of recognizing that DNS must work before any network communication can occur.

How to eliminate wrong answers

Option A is wrong because `podman login` authenticates to the registry, but DNS resolution occurs before authentication; if the hostname cannot be resolved, authentication is irrelevant. Option B is wrong because restarting the container runtime service does not fix underlying DNS configuration issues; it only restarts the daemon without changing network or resolver settings. Option D is wrong because `--no-cache` forces a fresh build by ignoring cached layers, but it does not affect DNS resolution; the build will still fail if the registry hostname cannot be resolved.

Practice this question →
16
MCQhard

A developer is creating a new content collection named `acme.automation` and wants to ensure that the collection is structured correctly for distribution. After running `ansible-galaxy collection init acme.automation`, which directory should contain the custom Ansible modules that the collection will provide?

A.`roles/modules/`
B.`plugins/modules/`
C.`modules/`
D.`library/`
AnswerB

In an Ansible collection, custom modules are placed in the `plugins/modules/` directory. This is the standard location that Ansible searches when resolving modules from a collection. After initializing with `ansible-galaxy collection init`, the directory structure includes `plugins/modules/` by default, ready for module files. Placing modules here ensures they are discoverable and usable in playbooks via the collection's fully qualified name.

Why this answer

Ansible collections organize plugins by type. Modules are a type of plugin and belong in `plugins/modules/`. This structure allows Ansible to load modules from the collection namespace.

Other directories like `roles/` or `library/` serve different purposes and are not scanned for collection modules. Using the correct directory is essential for the collection to work as intended.

Exam trap

The trap here is confusing the collection plugin directory structure with legacy role or playbook directory layouts.

Practice this question →
17
MCQhard

A developer is creating a new content collection and wants to include a custom module that requires the `requests` Python library. The collection will be used in an execution environment. Where should the developer declare this Python dependency so that it is automatically installed when the execution environment is built?

A.In a `requirements.txt` file at the root of the collection.
B.In the collection's `meta/runtime.yml` file under `requires_ansible`.
C.In the `execution-environment.yml` file under the `dependencies` section with a `python` key.
D.In the collection's `galaxy.yml` file under a `dependencies` key.
AnswerC

The `execution-environment.yml` file is the central place to define all dependencies for an execution environment, including Python packages. Under the `dependencies` section, you can specify a `python` list that includes `requirements.txt` or direct package names. This ensures `ansible-builder` installs the required Python libraries during the image build. This is the correct location for declaring `requests`.

Why this answer

Python dependencies for an execution environment are declared in the `execution-environment.yml` file under the `dependencies` section, using the `python` key to list packages or a requirements file. This allows `ansible-builder` to install them during the build process. Other files like `galaxy.yml` or `meta/runtime.yml` serve different purposes and do not trigger Python package installation.

Exam trap

The trap here is assuming that a `requirements.txt` file at the collection root is automatically used by `ansible-builder`, when actually the execution environment definition must explicitly reference it.

Practice this question →
18
Multi-Selectmedium

Which TWO statements are true about Ansible content collections?

Select 2 answers
A.Collections can be installed from Automation Hub, Galaxy, or a Git repository.
B.Collections cannot contain playbooks.
C.A role stored in a collection can be referenced by its short name without the collection prefix.
D.Execution environments are required to use collections.
E.Fully qualified collection names (FQCN) help avoid naming conflicts.
AnswersA, E

Collections are distributed as tarballs or Git repositories, so installation works from Automation Hub, Galaxy, or a Git URL via `ansible-galaxy collection install`. This satisfies the stem's requirement that content can be sourced from multiple locations, including private Git repositories, rather than being limited to a single distribution channel.

Why this answer

Option A is correct because Ansible collections can be installed from multiple sources, including Automation Hub (Red Hat's certified content repository), Ansible Galaxy (the public community hub), and directly from a Git repository using ansible-galaxy collection install with a git URL or a requirements.yml entry specifying type: git. Option E is correct because Fully Qualified Collection Names (FQCN), such as ansible.builtin.copy or community.general.ufw, namespace each module, role, and plugin under its collection, preventing collisions when different collections define content with the same short name. Option B is wrong because collections may contain playbooks in their playbooks/ directory alongside roles, modules, and plugins.

Option C is wrong because a role inside a collection must be referenced with its FQCN (for example, my_namespace.my_collection.my_role) or via the collections keyword in a playbook, not by its bare short name. Option D is wrong because execution environments are an optional containerized packaging mechanism for dependencies, not a prerequisite for using collections.

Exam trap

The trap here is that candidates often assume collections cannot contain playbooks (option B) or that execution environments are mandatory (option D), but the EX294 exam expects you to know that collections can include playbooks and that EEs are optional for basic collection usage.

Practice this question →
19
MCQhard

A build of an execution environment fails with an error that ansible-builder cannot find the collection acme.internal.utils in any configured Galaxy server. The collection exists on the private Automation Hub, and the build host can reach it. The execution-environment.yml lists the collection under dependencies.galaxy pointing to requirements.yml. What is the most likely cause?

A.The collection name in requirements.yml must be prefixed with the Galaxy server name, such as hub_internal.acme.internal.utils.
B.The ansible.cfg used by ansible-builder does not define the private Automation Hub as a Galaxy server with valid credentials.
C.The execution environment base image does not include ansible-galaxy, so collection installation is skipped.
D.The collection version in requirements.yml is pinned to a version that does not exist on the private Automation Hub.
AnswerB

If ansible-builder's ansible.cfg lacks the private Automation Hub entry or its token, the build will not authenticate to that server and will report the collection as unfindable. Even though the host can reach the Hub, the builder must be told the server URL and token to resolve the collection during the build.

Why this answer

The error indicates the collection cannot be found in any configured Galaxy server. Since the collection exists on the private Automation Hub and the host can reach it, the most likely cause is that the ansible.cfg used by ansible-builder does not define that Hub with valid credentials. Without the server URL and token, the builder cannot authenticate and will not see the collection.

Exam trap

The trap here is assuming network reachability is sufficient, when ansible-builder also needs the Galaxy server and token declared in its ansible.cfg.

Practice this question →
20
MCQeasy

Which file is required to define the content of an Ansible execution environment when using ansible-builder?

A.Dockerfile
B.requirements.yml
C.ansible.cfg
D.execution-environment.yml
AnswerD

The execution-environment.yml file defines an execution environment's content, specifying the base image, Galaxy dependencies, Python requirements and additional build files that ansible-builder consumes. Without it, ansible-builder has no definition to construct the container image from.

Why this answer

The `execution-environment.yml` file is the required definition file for `ansible-builder` because it specifies the base image, custom dependencies (Python, system, or collections), and additional build instructions needed to construct a containerized Ansible execution environment. Without this file, `ansible-builder` has no manifest to process, as it is the sole input that defines the environment's content.

Exam trap

The trap here is that candidates confuse the generated `Dockerfile` (an output artifact) with the required input file, or they assume `requirements.yml` is the main definition because it is commonly used for collection installation in playbooks, but `ansible-builder` specifically requires `execution-environment.yml` as the blueprint.

How to eliminate wrong answers

Option A is wrong because a `Dockerfile` is not required; `ansible-builder` generates a `Dockerfile` automatically from the `execution-environment.yml` definition, so providing one manually would override the builder's logic and is not the required input. Option B is wrong because `requirements.yml` is an optional file used to list Ansible collections for installation, but it is not the primary definition file; it can be referenced within `execution-environment.yml` under the `dependencies` section. Option C is wrong because `ansible.cfg` is a configuration file for Ansible's runtime behavior (e.g., inventory, roles path, forks) and has no role in defining the content of an execution environment for `ansible-builder`.

Practice this question →
21
MCQmedium

When building an execution environment with ansible-builder, a developer notices that the build process fails with an error about missing dependencies. The developer wants to ensure all required Python packages are installed in the execution environment. Which file should be used to specify additional Python packages?

A.meta/runtime.yml
B.galaxy.yml
C.bindep.txt
D.requirements.txt
AnswerD

Listing Python packages in requirements.txt lets ansible-builder install them into the execution environment image during the build, resolving the missing-dependency failure. The bindep.txt file handles system-level packages instead, so requirements.txt is the correct file for the Python dependencies the stem requires.

Why this answer

In Ansible Builder, the `requirements.txt` file is used to specify additional Python packages that should be installed in the execution environment. When building an execution environment, Ansible Builder reads this file and installs the listed packages via pip, ensuring all required Python dependencies are present.

Exam trap

The trap here is that candidates confuse `bindep.txt` (for system packages) with `requirements.txt` (for Python packages), as both are used in execution environment builds but serve different dependency types.

How to eliminate wrong answers

Option A is wrong because `meta/runtime.yml` is used to define runtime dependencies and compatibility for Ansible collections, not for specifying Python packages for an execution environment. Option B is wrong because `galaxy.yml` is a metadata file for Ansible collections, used to define collection name, version, and dependencies, not for listing Python packages. Option C is wrong because `bindep.txt` is used to specify system-level package dependencies (e.g., for apt or yum), not Python packages.

Practice this question →
22
MCQeasy

An automation team wants to build an execution environment that includes a specific collection from a private Automation Hub. Which file must be present in the build context to specify the collection and its source?

A.execution-environment.yml
B.galaxy.yml
C.bindep.txt
D.requirements.yml
AnswerD

`requirements.yml` is used by `ansible-builder` to list Ansible collections and roles that should be installed into the execution environment. It can specify collections from Automation Hub, including private sources, by using the `source` key or by configuring the server in `ansible.cfg`. This file is essential for including the collection.

Why this answer

To include a collection in an execution environment, `ansible-builder` reads `requirements.yml` from the build context. This file lists collections (and roles) to install, and can specify the source server, making it the correct place to declare a collection from a private Automation Hub.

Exam trap

The trap here is confusing the execution environment definition file (`execution-environment.yml`) with the requirements file that actually lists collections.

Practice this question →
23
MCQmedium

Based on the exhibit, what is the purpose of the `galaxy` dependency entry?

A.Set the base container image.
B.Define which Ansible collections to install in the execution environment.
C.Specify Python packages to install via pip.
D.Configure environment variables for the container.
AnswerB

The `galaxy` entry specifies Ansible collections and roles that the execution environment must include, satisfying the requirement to declare dependencies for the automation content. During image build, ansible-builder reads this key and installs the listed collections into the container, ensuring the playbook's modules are available at runtime.

Why this answer

In the context of Ansible execution environments (EEs), the `galaxy` key within the `dependencies` section of the `execution-environment.yml` file specifies a list of Ansible collections to be installed from Ansible Galaxy or an Automation Hub. This allows the EE to include the necessary content collections required for playbook execution, ensuring all roles and modules are available inside the container.

Exam trap

Red Hat often tests the distinction between `galaxy` (for Ansible collections) and `python` (for pip packages) in the `dependencies` section, leading candidates to confuse the two or assume `galaxy` installs Python packages.

How to eliminate wrong answers

Option A is wrong because the base container image is defined by the `base_image` key in the `execution-environment.yml` file, not by the `galaxy` dependency entry. Option C is wrong because Python packages to install via pip are specified under the `python` key within `dependencies`, not under `galaxy`. Option D is wrong because environment variables for the container are configured using the `environment` key in the `execution-environment.yml` file, not through the `galaxy` dependency entry.

Practice this question →
24
Multi-Selectmedium

Which TWO statements about Ansible Execution Environments (EE) are true?

Select 2 answers
A.Execution environments are primarily used for developing new Ansible modules.
B.Execution environments use ansible-navigator as the default entrypoint.
C.Execution environments are container images built with ansible-builder.
D.Execution environments package Ansible Core, collections, and Python dependencies.
E.Execution environments can only be used with the ansible-navigator command-line tool.
AnswersC, D

Ansible-builder is the supported tool that assembles execution environments, producing a container image from an execution-environment definition file. The resulting image is what ansible-navigator or AWX runs, satisfying the requirement that EEs are container images.

Why this answer

Option C is correct because Ansible Execution Environments are defined in an execution-environment.yml file and built into container images using the ansible-builder tool, producing OCI-compliant images that bundle everything needed to run automation. Option D is correct because an EE image packages ansible-core, the required Ansible collections, and their Python dependencies (plus system packages) into a single portable container, ensuring consistent runtime environments. Option A is incorrect because EEs are runtime artifacts for executing playbooks and roles, not a development framework for authoring new modules.

Option B is incorrect because ansible-navigator is a CLI tool that consumes EEs, not the default entrypoint inside the image (the entrypoint is typically the ansible-runner based execution). Option E is incorrect because EEs are standard container images and can be run with podman, docker, ansible-runner, AWX/Controller, and other tools, not exclusively ansible-navigator.

Exam trap

The trap here is that candidates may confuse the purpose of execution environments (packaging and running automation) with module development, or assume that `ansible-navigator` is the only way to use them, when in fact they are container images that can be used with multiple Ansible tools.

Practice this question →
25
Multi-Selectmedium

Which TWO options are valid methods for including collections in an execution environment?

Select 2 answers
A.Use ansible-galaxy collection install command in a pre-build script.
B.List collections under 'collections' in execution-environment.yml.
C.Use a 'galaxy.yml' file in the build context.
D.Add a requirements.yml file with collections.
E.Include collections in the base image directly.
AnswersB, D

Listing collections under the collections key in execution-environment.yml lets ansible-builder resolve and install them directly from configured Galaxy or Automation Hub sources during the image build, satisfying the requirement to include collections in the execution environment.

Why this answer

Option B is correct because the execution-environment.yml definition file supports a 'collections' key where you list collection names (and optionally versions/sources) that ansible-builder will install into the resulting execution environment image. Option D is correct because ansible-builder recognizes a requirements.yml file (referenced via the 'dependencies' section, e.g. galaxy: requirements.yml) that specifies collections to install, using the standard Galaxy requirements format. Option A is not the intended answer because running ansible-galaxy collection install in a pre-build script is a manual workaround rather than a declared, supported method for including collections in the execution environment definition.

Option C is incorrect because galaxy.yml is a collection's own metadata/manifest file used when building or publishing a collection, not a mechanism for adding collections to an execution environment. Option E is incorrect because baking collections into the base image is not a valid ansible-builder method for including collections; collections should be declared in the execution environment definition so they are installed during the build.

Exam trap

The trap here is that candidates confuse the `galaxy.yml` file (used for defining a collection's metadata) with the `execution-environment.yml` file (used for specifying collections to include in an execution environment), or they mistakenly think runtime commands like `ansible-galaxy collection install` are valid build-time methods.

Practice this question →
26
Multi-Selecthard

Which TWO statements about Ansible content collections are correct?

Select 2 answers
A.Collections can be installed only from Galaxy.
B.The collection name must be a single word without namespace.
C.Collections can be distributed via Automation Hub or Galaxy.
D.A collection can contain only roles and playbooks.
E.A collection must have a galaxy.yml file in its root directory.
AnswersC, E

Collections are distributed as tarballs through Galaxy, Automation Hub, or private Galaxy servers, which is the standard distribution mechanism. This satisfies the statement's requirement, distinguishing collections from standalone roles shared via Git or Galaxy alone.

Why this answer

Option C is correct because Ansible content collections can be obtained from both public Ansible Galaxy and Red Hat Automation Hub (as well as private Automation Hub instances), which are the standard distribution sources configured via ansible.cfg or the ansible-galaxy CLI. Option E is correct because a collection's source tree requires a galaxy.yml metadata file at its root, which defines the namespace, name, version, authors, and dependencies used when building and publishing the collection artifact. Option A is wrong because collections can also be installed from Automation Hub, private automation hubs, Git repositories, tarballs, or local paths, not only Galaxy.

Option B is wrong because a collection name uses the format namespace.collection (for example, ansible.builtin), so it must include a namespace rather than being a single word. Option D is wrong because collections can contain many content types beyond roles and playbooks, including modules, plugins, filters, tests, and documentation.

Exam trap

Red Hat often tests the requirement for a `galaxy.yml` file in the collection root, as candidates may mistakenly think it is optional or confuse it with other configuration files like `meta/main.yml`.

Practice this question →
27
MCQhard

A collection version is already published on Automation Hub. The developer needs to update the collection with a new feature. What must be done to the version number before publishing again?

A.No change needed; Automation Hub overwrites.
B.Increment the patch or minor version number.
C.Increment the major version number.
D.Change the version to a pre-release identifier.
AnswerB

Automation Hub rejects republishing an existing version, so the version field in galaxy.yml must be incremented before rebuilding and publishing. A patch bump suits a feature addition only if the project's convention allows it; otherwise a minor increment is used to signal new functionality.

Why this answer

Automation Hub enforces immutable collection versions; once a version is published, it cannot be overwritten or deleted. To publish a new feature, you must increment the patch (e.g., 1.0.0 → 1.0.1) or minor (e.g., 1.0.0 → 1.1.0) version number in the galaxy.yml file, following semantic versioning (semver) as required by Ansible collections.

Exam trap

The trap here is that candidates assume Automation Hub behaves like a mutable artifact repository (e.g., overwriting on re-upload), but Red Hat enforces immutability to ensure version integrity and reproducibility across environments.

How to eliminate wrong answers

Option A is wrong because Automation Hub does not allow overwriting an existing version; collections are immutable once published, and attempting to publish the same version will result in an error. Option C is wrong because incrementing the major version (e.g., 1.0.0 → 2.0.0) is only required when introducing breaking changes, not for a new feature that is backward-compatible. Option D is wrong because pre-release identifiers (e.g., 1.0.0-alpha.1) are used for testing or development versions and are not intended for publishing a stable new feature to Automation Hub.

Practice this question →
28
MCQeasy

An administrator needs to create a new Ansible content collection named `myorg.automation` that will contain roles and modules. Which command initializes the collection directory structure with the required skeleton files?

A.ansible-galaxy collection init myorg.automation
B.ansible-playbook --init-collection myorg.automation
C.ansible-galaxy init myorg.automation
D.ansible-builder init myorg.automation
AnswerA

The `ansible-galaxy collection init` command creates a new collection directory structure with the specified namespace and name. It generates skeleton files including `galaxy.yml`, `README.md`, `docs/`, `plugins/`, `roles/`, and `playbooks/`. This command is the standard way to start a new collection, ensuring all necessary files are present for development and packaging.

Why this answer

The `ansible-galaxy collection init` command is the correct way to create a new collection skeleton. It sets up the directory structure with the namespace and collection name, and generates essential files like `galaxy.yml` and `README.md`. Other commands either initialize roles (`ansible-galaxy init`) or serve entirely different purposes.

Exam trap

The trap here is confusing `ansible-galaxy init` for roles with `ansible-galaxy collection init` for collections, as both use the `ansible-galaxy` command but target different content types.

Practice this question →
29
Matchingmedium

Match each firewall zone to its default behavior.

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

Concepts
Matches

Default zone, untrusted network

Private network, slightly trusted

Demilitarized zone, limited access

All traffic accepted

All incoming packets dropped

Why these pairings

Common firewalld zones include public (default deny), trusted (allow all), external (NAT with limited inbound), dmz (limited inbound for public servers), internal (trusted but filtered), and drop (silent discard). Common confusions involve swapping the behaviors of public and trusted, or misunderstanding dmz as fully blocking instead of selectively allowing.

Practice this question →
30
MCQhard

An automation team is designing a content collection to distribute internal Ansible modules across the organization. The collection should be installed from a private Galaxy server. To minimize namespace conflicts and ensure discoverability, which naming convention should be used for the collection?

A.collection_name.namespace
B.namespace_collection_name
C.namespace-collection_name
D.namespace.collection_name
AnswerD

The namespace.collection_name format is mandatory for Galaxy-hosted collections, where the namespace scopes ownership and prevents conflicts between organisations. This satisfies the stem's requirement to minimise namespace conflicts and ensure discoverability on a private Galaxy server.

Why this answer

In Ansible, collections are distributed using a fully qualified collection name (FQCN) in the format `namespace.collection_name`. This naming convention is required by the Ansible Galaxy server and the `ansible-galaxy collection install` command to uniquely identify and install collections, minimizing namespace conflicts and ensuring discoverability across the organization.

Exam trap

The trap here is that candidates may confuse the dot separator with other common naming conventions (like underscores or hyphens used in Python packages or Ansible roles), but Ansible collections strictly require the `namespace.collection_name` format with a dot.

How to eliminate wrong answers

Option A is wrong because `collection_name.namespace` reverses the required order; the namespace must come first, followed by a dot and then the collection name. Option B is wrong because `namespace_collection_name` uses an underscore separator, but Ansible collections require a dot (`.`) as the delimiter between namespace and collection name. Option C is wrong because `namespace-collection_name` uses a hyphen, which is not the correct separator; the dot is the only valid separator in Ansible's FQCN for collections.

Practice this question →
31
MCQeasy

A user wants to use a collection from Automation Hub. Which command downloads and installs the collection to the default collections path?

A.ansible-pull collection install
B.ansible-playbook collection install
C.ansible-collection install
D.ansible-galaxy collection install
AnswerD

ansible-galaxy collection install resolves and downloads the named collection from the configured Automation Hub server, placing it under the default collections path (~/.ansible/collections). It performs both retrieval and installation in one command, satisfying the requirement.

Why this answer

The correct command to download and install a collection from Automation Hub to the default collections path is `ansible-galaxy collection install`. This command uses the `ansible-galaxy` utility, which is the standard tool for managing Ansible roles and collections, and the `collection install` subcommand specifically handles collection installation from configured sources like Automation Hub or Ansible Galaxy.

Exam trap

The trap here is that candidates confuse the `ansible-galaxy` command with other Ansible executables like `ansible-playbook` or `ansible-pull`, or assume a non-existent command like `ansible-collection` exists, because the exam tests precise knowledge of which tool handles collection management.

How to eliminate wrong answers

Option A is wrong because `ansible-pull` is used for pulling and applying playbooks from a repository in a reverse mode, not for installing collections; it does not have a `collection install` subcommand. Option B is wrong because `ansible-playbook` is used to execute playbooks, not to manage collections; it has no `collection install` subcommand. Option C is wrong because `ansible-collection` is not a valid Ansible command; the correct utility is `ansible-galaxy`.

Practice this question →
32
Multi-Selectmedium

An engineer is preparing to build an execution environment using `ansible-builder`. The build must include several collections and also install additional Python packages. Which two files are used to declare these dependencies? (Choose two.)

Select 2 answers
A.requirements.yml
B.galaxy.yml
C.execution-environment.yml
D.bindep.txt
E.requirements.txt
AnswersA, E

`requirements.yml` is used to list Ansible collections and roles that should be installed into the execution environment. It is the standard file for declaring collection dependencies, including those from Automation Hub or Galaxy. This file ensures the required collections are present.

Why this answer

The correct files are `requirements.yml` for Ansible collections and roles, and `requirements.txt` for Python packages. These are referenced by the `execution-environment.yml` file and are used by `ansible-builder` to install the necessary dependencies into the execution environment.

Exam trap

The trap here is confusing `bindep.txt` (system packages) with `requirements.txt` (Python packages), or assuming that `execution-environment.yml` directly lists all dependencies.

Practice this question →
33
MCQhard

A DevOps engineer is creating an execution environment for a team that needs both Ansible and the 'requests' Python library. The engineer creates an execution environment definition file (EE.yml) with the following content: --- version: 3 images: base_image: name: registry.redhat.io/ansible-automation-platform-22/ee-minimal-rhel8:latest options: package_manager_path: /usr/bin/microdnf dependencies: python: requirements.txt system: bindep.txt What is missing from this definition to ensure the 'requests' library is installed?

A.The package_manager_path should be /usr/bin/yum.
B.The requirements.txt file must contain 'requests'.
C.The galaxy.yml file must be added to the dependencies section.
D.The base image should be ee-supported-rhel8 instead.
AnswerB

The definition references requirements.txt under dependencies.python, so pip installs whatever that file lists. Because the file's contents are not shown, the 'requests' library is only guaranteed to be present if requirements.txt explicitly names it; otherwise nothing installs it.

Why this answer

The execution environment definition file (EE.yml) specifies dependencies via external files like requirements.txt for Python packages. To install the 'requests' library, the requirements.txt file must explicitly list 'requests' as a dependency. Without it, the build process will not include the library, regardless of other configuration options.

Exam trap

The trap here is that candidates may focus on the package manager or base image details, overlooking that the Python dependency must be explicitly declared in the requirements.txt file referenced by the definition.

How to eliminate wrong answers

Option A is wrong because the package_manager_path is correctly set to /usr/bin/microdnf for the specified RHEL 8 base image, which uses microdnf as its package manager; changing it to /usr/bin/yum would be incorrect. Option C is wrong because the galaxy.yml file is used for Ansible Galaxy content collections, not for Python package dependencies like 'requests'. Option D is wrong because the base image 'ee-minimal-rhel8' is appropriate for this execution environment; 'ee-supported-rhel8' is not a standard Red Hat image name and would not resolve the missing Python dependency.

Practice this question →
34
MCQmedium

Your team maintains a collection that includes custom modules and plugins. You have been tasked with creating a content collection that adheres to the Red Hat Ansible Content Collection requirements. You have created the directory structure and written the collection code. Now you need to package the collection for distribution to your internal automation hub. You run 'ansible-galaxy collection build' and it completes successfully, generating a tarball. However, when you try to publish it to your private automation hub using 'ansible-galaxy collection publish', you get an authentication error. You have verified that your automation hub server URL and API token are correct. What is the most likely cause of the error?

A.The automation hub server is not reachable from your network.
B.The collection tarball is corrupted and needs to be rebuilt.
C.The collection contains a module that violates a content policy enforced by the hub.
D.The 'namespace' or 'name' in galaxy.yml does not match the namespace you are allowed to publish to on the automation hub.
AnswerD

Publishing authenticates the token, but authorisation is scoped per namespace. If galaxy.yml's namespace differs from the one your automation hub account may publish to, the server rejects the upload with an authentication-style error even though the token itself is valid.

Why this answer

The authentication error despite correct server URL and API token indicates that the issue is not with credentials or connectivity, but with authorization. Ansible Automation Hub enforces namespace-based access control: the `namespace` field in `galaxy.yml` must match a namespace you are permitted to publish to. If the namespace does not match, the hub rejects the upload with an authentication/authorization error, even though the token itself is valid.

Exam trap

The trap here is that candidates assume any error during `publish` with a valid token must be a network or credential issue, overlooking the namespace authorization check that Ansible Automation Hub performs before allowing upload.

How to eliminate wrong answers

Option A is wrong because the user verified the server URL is correct, and a connectivity issue would typically produce a timeout or connection refused error, not an authentication error. Option B is wrong because the `ansible-galaxy collection build` command completed successfully, which includes integrity checks; a corrupted tarball would likely cause a build failure or a checksum mismatch during upload, not an authentication error. Option C is wrong because content policy violations (e.g., disallowed modules) would result in a policy rejection error message, not an authentication error — the hub would accept the token but refuse the content based on policy rules.

Practice this question →
35
Multi-Selectmedium

Which THREE files are commonly used when building an execution environment with ansible-builder?

Select 3 answers
A.bindep.txt
B.ansible.cfg
C.galaxy.yml
D.execution-environment.yml
E.requirements.txt
AnswersA, D, E

bindep.txt lists system-level package dependencies, which ansible-builder installs into the execution environment's base image before Python requirements. This satisfies the stem's need for build-input files: bindep.txt supplies OS packages, complementing requirements.txt and ansible.cfg as the three commonly used files.

Why this answer

ansible-builder builds an execution environment from a definition directory, and the three commonly used input files are execution-environment.yml, requirements.txt, and bindep.txt. Option D (execution-environment.yml) is the main definition file that declares the base image, dependencies, and additional build steps for the execution environment. Option E (requirements.txt) lists the Python packages (such as ansible-core, ansible-runner, and collections' Python dependencies) to install into the image.

Option A (bindep.txt) specifies system-level (RPM/OS) package requirements that must be installed in the container image. Option B (ansible.cfg) is an Ansible runtime configuration file and is not a standard ansible-builder input, and Option C (galaxy.yml) is a collection metadata file used when building or publishing Ansible collections, not for building execution environments.

Exam trap

Red Hat often tests the misconception that `ansible.cfg` is part of the execution environment build process, but it is only used at runtime by Ansible, not by `ansible-builder` to construct the container image.

Practice this question →
36
MCQeasy

An Ansible developer needs to use the `podman_container` module in a playbook. The module is part of the `containers.podman` collection. Which command must be run first to make the module available?

A.`ansible-galaxy install containers.podman`
B.`ansible-galaxy collection install containers.podman`
C.`ansible-galaxy collection search containers.podman`
D.`ansible-galaxy collection install containers.podman:1.0.0`
AnswerB

`ansible-galaxy collection install containers.podman` retrieves the collection from Galaxy and places it in the configured collections path, so the `podman_container` module resolves during playbook execution. This satisfies the stem's requirement to make the module available before use, since collections must be installed rather than bundled with ansible-core.

Why this answer

The `podman_container` module is part of the `containers.podman` collection, which must be installed from Ansible Galaxy before it can be used in a playbook. The correct command is `ansible-galaxy collection install containers.podman`, which downloads and installs the collection into the local collections path, making all its modules and plugins available.

Exam trap

The trap here is that candidates may confuse `ansible-galaxy install` (for roles) with `ansible-galaxy collection install` (for collections), or mistakenly think that searching for a collection makes it available for use.

How to eliminate wrong answers

Option A is wrong because `ansible-galaxy install` is used for installing roles, not collections; collections require the `collection` subcommand. Option C is wrong because `ansible-galaxy collection search` only searches for collections in Galaxy but does not install them, so the module would remain unavailable. Option D is wrong because while it specifies a version (`1.0.0`), the question does not require a specific version; the generic install command is sufficient, and pinning an arbitrary version may cause compatibility issues or fail if that version does not exist.

Practice this question →
37
MCQmedium

An organization wants to include custom Python packages in their execution environment to support custom modules. Which method should be used to define these Python dependencies?

A.List them in the `galaxy-requirements.yml` file.
B.Use `ansible-navigator` to install them during runtime.
C.Create a `requirements.txt` file and reference it in the `execution-environment.yml` under `dependencies: python:`.
D.Add them to the `collection-requirements.yml` file.
AnswerC

Ansible Builder reads the python section of dependencies and passes the referenced requirements.txt to pip inside the build, so custom Python packages land in the execution environment image and the custom modules can import them at runtime.

Why this answer

The `execution-environment.yml` file supports a `dependencies` key with a `python` subkey that points to a `requirements.txt` file. This is the standard method defined by the Ansible Builder specification for including custom Python packages in an execution environment, ensuring they are installed during the build process.

Exam trap

The trap here is that candidates confuse the file used for Ansible collections (`galaxy-requirements.yml` or `collection-requirements.yml`) with the file used for Python dependencies, leading them to pick options A or D instead of recognizing the correct `execution-environment.yml` structure.

How to eliminate wrong answers

Option A is wrong because `galaxy-requirements.yml` is used to specify Ansible Galaxy content collections, not Python packages. Option B is wrong because `ansible-navigator` is a runtime tool for running execution environments, not for installing dependencies during the build; Python dependencies must be defined at build time. Option D is wrong because `collection-requirements.yml` is another name for a file that lists Ansible collections, not Python packages.

Practice this question →
38
MCQmedium

A developer is preparing a collection for distribution and must declare its metadata, including version, license, and the list of collections it depends on. Which file at the collection root contains these declarations?

A.requirements.yml
B.meta/runtime.yml
C.plugins/README.md
D.galaxy.yml
AnswerD

`galaxy.yml` is the collection manifest. It carries the namespace, name, version, authors, license, tags, and a `dependencies` mapping that lists other collections and their version constraints. When the collection is built and published, this file supplies the metadata the Galaxy server records and the resolver uses to pull dependent collections.

Why this answer

The manifest that describes a collection to Galaxy and to dependency resolution is `galaxy.yml`, which holds version, license, and the `dependencies` mapping. Runtime requirements live elsewhere, and consumer-side requirement files are unrelated to how the collection itself is described when packaged.

Exam trap

The trap here is mixing up a collection's own manifest with a consumer `requirements.yml` that merely lists collections to install into an environment.

Practice this question →
39
MCQhard

Ansible Builder fails during the build of an execution environment with error: 'No matching manifest for linux/amd64 in the manifest list entries'. What is the most likely cause?

A.The ansible-builder version is too old.
B.The definition file has invalid syntax.
C.The container registry requires authentication.
D.The base image specified is incompatible with the host architecture.
AnswerD

The base image's manifest list lacks a linux/amd64 entry, so the container runtime cannot resolve a matching image for the host's architecture. Ansible Builder pulls the specified base image during execution environment creation, and this architecture mismatch halts the build before dependency installation begins.

Why this answer

The error 'No matching manifest for linux/amd64 in the manifest list entries' indicates that the base image specified in the execution environment definition file does not have a container image manifest for the host's CPU architecture (linux/amd64). Ansible Builder pulls the base image from a registry, and if that image only supports other architectures (e.g., linux/arm64), the build fails. This is a common issue when using a base image built for a different platform.

Exam trap

Red Hat often tests the misconception that registry authentication or syntax errors cause all build failures, but here the specific manifest list error is a clear indicator of an architecture mismatch, not a credential or syntax problem.

How to eliminate wrong answers

Option A is wrong because an outdated ansible-builder version would not cause this specific manifest mismatch error; it might cause other build failures or deprecation warnings, but the error is architecture-related. Option B is wrong because invalid syntax in the definition file typically results in YAML parsing errors or missing key errors, not a manifest list mismatch. Option C is wrong because registry authentication failures produce errors like 'unauthorized: authentication required' or 'denied: requested access to the resource is denied', not a manifest architecture mismatch.

Practice this question →
40
Multi-Selecthard

An administrator needs to create a custom execution environment that includes a specific Ansible collection and a Python package. Which two steps are required to build and use the execution environment? (Choose two.)

Select 2 answers
A.Create a Dockerfile that installs the collection and package.
B.Define the execution environment in ansible.cfg.
C.Build the execution environment using ansible-builder.
D.Push the execution environment to a private container registry.
E.Create a requirements.yml file listing the collection.
AnswersC, E

Correct: ansible-builder builds a container image from the execution environment definition.

Why this answer

`ansible-builder` is the official tool for building Ansible execution environments, which are container images that bundle Ansible, collections, and dependencies. It uses a definition file (execution-environment.yml) to specify collections and Python packages, then builds the container image. Option E is correct because a `requirements.yml` file is the standard way to list Ansible collections for inclusion in an execution environment, and `ansible-builder` reads this file during the build process.

Exam trap

The trap here is that candidates often confuse the manual Dockerfile approach (Option A) with the correct `ansible-builder` workflow, or they think pushing to a registry (Option D) is mandatory when the question only asks for steps to build and use the execution environment locally.

Practice this question →
41
MCQeasy

You are creating a new Ansible content collection named 'acme.corp' using the ansible-galaxy collection init command. After running the command, you need to add a module that will be part of this collection. Where should you place the module file within the collection directory structure?

A.In the roles directory under a role named after the module.
B.In the library directory at the root of the collection.
C.In the plugins/modules directory.
D.In the modules directory at the root of the collection.
AnswerC

Ansible collections follow a standard directory layout. Modules are stored in the plugins/modules directory. When the collection is installed, Ansible automatically discovers modules in this location. Placing the module file there ensures it is properly loaded and available for use in playbooks with the fully qualified collection name (FQCN).

Why this answer

Ansible collections have a defined structure where plugins, including modules, are stored under the plugins directory. Modules specifically go in plugins/modules. This structure allows Ansible to automatically discover and load the module when the collection is installed, making it available for use in playbooks via the collection's fully qualified name.

Exam trap

The trap here is confusing the collection plugin directory structure with the legacy library directory used for standalone playbook modules.

Practice this question →
42
MCQmedium

An organization's execution environment must include a custom RPM that is not in the default base image. How should this be added in the execution-environment.yml?

A.Add the RPM to the 'dependencies' section under 'system'.
B.Add the RPM to the 'dependencies' section under 'python'.
C.Use a 'prepended_base' directive.
D.Use a custom base image that includes the RPM.
AnswerA

The dependencies section's system subsection maps to dnf or microdnf package installation during the build, so listing the RPM there causes ansible-builder to install it into the final image. This satisfies the requirement that the custom RPM be present.

Why this answer

In an execution-environment.yml file, custom RPM packages that are not part of the default base image must be listed under the 'dependencies' section with the 'system' key. This instructs ansible-builder to install those RPMs using the system package manager (e.g., dnf or yum) during the build process, ensuring the execution environment includes the required system-level libraries or tools.

Exam trap

The trap here is that candidates often confuse the 'system' and 'python' dependency sections, mistakenly thinking RPMs can be added under 'python' because both are under 'dependencies', but 'python' is strictly for pip-installable packages.

How to eliminate wrong answers

Option B is wrong because the 'python' key under 'dependencies' is used for Python packages (e.g., pip install), not for RPM packages. Option C is wrong because there is no 'prepended_base' directive in execution-environment.yml; the correct way to modify the base image is through the 'base_image' field or by adding dependencies. Option D is wrong because while using a custom base image that includes the RPM is a valid approach, the question specifically asks how to add it in the execution-environment.yml file, and the correct method is to list it under 'dependencies: system' rather than building a separate custom base image.

Practice this question →
43
MCQeasy

Which directory is the default location for installed Ansible collections on a control node for a regular user?

A.~/.ansible/collections
B./usr/share/ansible/collections
C./etc/ansible/collections
D./opt/ansible/collections
AnswerA

Ansible installs collections into `~/.ansible/collections` when a regular user runs `ansible-galaxy collection install`, satisfying the stem's non-root constraint. The system-wide path `/usr/share/ansible/collections` applies only to root installs, so the per-user default is the correct location here.

Why this answer

For a regular (non-root) user on an Ansible control node, the default location for installed collections is `~/.ansible/collections`. This is defined by Ansible's default collection search path, which includes the user's home directory under `~/.ansible/collections` for user-level installations. When a user runs `ansible-galaxy collection install` without specifying a custom path, the collection is placed in this directory by default.

Exam trap

The trap here is that candidates often confuse the system-wide default (`/usr/share/ansible/collections`) with the user-level default, forgetting that regular users lack write permissions to system directories and that Ansible defaults to the home directory for non-root installations.

How to eliminate wrong answers

Option B is wrong because `/usr/share/ansible/collections` is the default location for system-wide (root) collection installations, not for a regular user. Option C is wrong because `/etc/ansible/collections` is not a standard default path for collections; `/etc/ansible/` is typically used for configuration files like `ansible.cfg` and `hosts`, not collections. Option D is wrong because `/opt/ansible/collections` is not a default Ansible collection path; it might be used in custom setups but is not the default for any user level.

Practice this question →
44
MCQhard

A team develops an Ansible collection and wants to distribute it internally. They have a private Automation Hub. Which approach best ensures that collection dependencies from external sources are also available?

A.Manually install each dependency on the control node
B.Define a requirements.yml in the execution environment that references both the private hub and external sources
C.Include all dependencies directly in the collection's repository
D.Use ansible-galaxy collection download and then upload to private hub
AnswerB

A requirements.yml in the execution environment lists collections from both the private Automation Hub and external sources, so ansible-builder resolves and bundles every dependency. It satisfies the constraint that external dependencies remain available alongside internally distributed collections.

Why this answer

Defining a `requirements.yml` in the execution environment allows you to specify collections from both the private Automation Hub and external sources (e.g., Ansible Galaxy). When building the execution environment, `ansible-builder` processes this file and resolves dependencies from the listed sources, ensuring all required collections are bundled into the container image. This approach automates dependency management and avoids manual installation or repository bloat.

Exam trap

The trap here is that candidates often assume dependencies must be manually installed or bundled directly, missing the fact that `requirements.yml` in the execution environment context is the standard way to aggregate collections from multiple sources automatically.

How to eliminate wrong answers

Option A is wrong because manually installing each dependency on the control node is error-prone, not scalable, and does not ensure dependencies are available in the execution environment or to other team members. Option C is wrong because including all dependencies directly in the collection's repository violates best practices—collections should declare dependencies in `galaxy.yml` or `requirements.yml`, not bundle them, as this leads to repository bloat and version conflicts. Option D is wrong because `ansible-galaxy collection download` only downloads collections for offline use; uploading them to the private hub does not automatically resolve dependencies from external sources unless those dependencies are also downloaded and uploaded, which is not guaranteed by this approach.

Practice this question →
45
Multi-Selectmedium

You are preparing to publish a new version of a content collection to a private Automation Hub. The collection includes several roles and modules. Before publishing, you need to ensure the collection is properly built and packaged. Which two commands are required to build and publish the collection? (Choose two.)

Select 2 answers
A.ansible-galaxy collection build
B.ansible-galaxy collection install
C.ansible-galaxy collection publish
D.ansible-galaxy collection verify
E.ansible-galaxy collection init
AnswersA, C

The ansible-galaxy collection build command compiles the collection into a tarball (.tar.gz) that can be published. It reads the galaxy.yml file for metadata and packages all necessary files. This is a required step before publishing, as the Automation Hub expects a built collection artifact.

Why this answer

To publish a collection to Automation Hub, you first build it into a tarball using ansible-galaxy collection build, then publish that tarball using ansible-galaxy collection publish. These two commands form the standard build and publish workflow, ensuring the collection is packaged correctly and uploaded to the repository.

Exam trap

The trap here is confusing the publish workflow with installation or initialization commands, which serve different purposes in the collection lifecycle.

Practice this question →
46
MCQmedium

A developer wants to create a new collection named 'myutils' under namespace 'myorg'. Which command initializes the collection structure?

A.ansible-galaxy collection scaffold myorg.myutils
B.ansible-galaxy collection create myorg.myutils
C.ansible-galaxy collection new myorg.myutils
D.ansible-galaxy collection init myorg.myutils
AnswerD

`ansible-galaxy collection init myorg.myutils` scaffolds the namespace/collection directory tree, generating `galaxy.yml`, `README.md`, `plugins/`, `roles/` and `docs/` under `myorg/myutils/`. The `init` subcommand is the only one that creates this skeleton, satisfying the stem's requirement to initialise the collection structure rather than build or install it.

Why this answer

The correct command to initialize a new Ansible collection structure is `ansible-galaxy collection init <namespace.collection>`. This creates the required directory layout, including `galaxy.yml`, `README.md`, and subdirectories like `roles/`, `playbooks/`, and `plugins/`. Option D matches this syntax exactly.

Exam trap

The trap here is that candidates confuse role scaffolding commands (`ansible-galaxy init` or `ansible-galaxy role init`) with collection initialization, and mistakenly apply verbs like `scaffold`, `create`, or `new` which are not valid for collections.

How to eliminate wrong answers

Option A is wrong because `ansible-galaxy collection scaffold` is not a valid subcommand; `scaffold` is used for roles, not collections. Option B is wrong because `ansible-galaxy collection create` is not a valid subcommand; the correct verb is `init`. Option C is wrong because `ansible-galaxy collection new` is not a valid subcommand; `new` is used for roles, not collections.

Practice this question →
47
Multi-Selecteasy

Which TWO actions are required to use a private Automation Hub to share collections?

Select 2 answers
A.Configure the server in ansible.cfg under [galaxy] server_list.
B.Build a custom execution environment that includes the collections.
C.Run ansible-galaxy collection install --ignore-certs if using self-signed certs.
D.Use ansible-navigator with --pull-policy missing.
E.Create an API token and store it in ansible.cfg or environment variable.
AnswersA, E

Listing the private Automation Hub under `[galaxy] server_list` in `ansible.cfg` directs the `ansible-galaxy` client to resolve and download collections from that server rather than the public Galaxy endpoint, satisfying the stem's requirement to share collections through a private hub.

Why this answer

Option A is correct because to make the ansible-galaxy client talk to a private Automation Hub instead of the default galaxy.ansible.com, you must list that server under the [galaxy] server_list setting in ansible.cfg (or via the ANSIBLE_GALAXY_SERVER_LIST environment variable), which defines the server name and URL used for collection operations. Option E is correct because private Automation Hub requires authentication for publishing and often for downloading collections, so you must generate an API token in the Automation Hub UI and supply it via the token key under the server's section in ansible.cfg or through the corresponding environment variable (e.g., ANSIBLE_GALAXY_SERVER_<name>_TOKEN). Option B is not required because building a custom execution environment is an optional packaging/distribution approach, not a prerequisite for the client to share collections with a private hub.

Option C is not required because --ignore-certs is only a workaround for certificate validation failures with self-signed certificates and is not part of the standard configuration for using a private Automation Hub. Option D is not required because --pull-policy missing is an ansible-navigator execution-environment behavior and has nothing to do with configuring a private Automation Hub as a collection source.

Exam trap

The trap here is that candidates confuse optional steps (like building execution environments or ignoring certs) with required actions, or they overlook that both server configuration and API token authentication are mandatory for accessing a private Automation Hub.

Practice this question →
48
MCQhard

During a collection development, a developer wants to include a Python dependency that is not available in the base image of the execution environment. Where should this dependency be declared?

A.In the execution-environment.yml under 'dependencies' -> 'python'
B.In the collection's requirements.yml under 'python'
C.In the collection's galaxy.yml under 'dependencies'
D.In the collection's meta/runtime.yml under 'python_dependencies'
AnswerA

Declaring the dependency under `dependencies` → `python` in `execution-environment.yml` instructs ansible-builder to install it into the execution environment image via pip during the build, satisfying the stem's constraint that the package is absent from the base image.

Why this answer

In Ansible execution environments, Python dependencies that are not part of the base image must be declared in the `execution-environment.yml` file under the `dependencies` key, specifically within the `python` subkey. This file is used by `ansible-builder` to build a custom container image that includes those additional Python packages. The base image already contains a standard set of Python libraries, but any extra ones needed by a collection must be explicitly listed here to be installed during the build process.

Exam trap

Red Hat often tests the distinction between files used for building execution environments (`execution-environment.yml`) versus files used for publishing or runtime metadata (`galaxy.yml`, `meta/runtime.yml`), causing candidates to confuse where Python dependencies should be declared.

How to eliminate wrong answers

Option B is wrong because `requirements.yml` is used for Ansible collections or roles, not for Python dependencies; it does not support a `python` key for pip packages. Option C is wrong because `galaxy.yml` is a metadata file for publishing collections to Ansible Galaxy, not for declaring runtime dependencies for execution environments. Option D is wrong because `meta/runtime.yml` defines Ansible runtime behavior like action groups or module deprecations, not Python package dependencies.

Practice this question →
49
MCQeasy

A user wants to build an execution environment from a definition file. Which command is used?

A.ansible-playbook build -i ee.yml
B.ansible-builder build -f execution-environment.yml
C.ansible-execution-environment build -f ee.yml
D.ansible-galaxy build execution-environment.yml
AnswerB

The ansible-builder CLI is the supported tool for turning an execution-environment definition file into a container image. The build subcommand reads the YAML definition via -f, resolving collections and Python dependencies, then produces the image Ansible Automation Platform uses to run playbooks.

Why this answer

The `ansible-builder build` command is the correct tool for building an Ansible execution environment from a a definition file. The `-f` flag specifies the path to the `execution-environment.yml` file, which defines the base image, required collections, and system dependencies for the containerized environment.

Exam trap

The trap here is that candidates confuse `ansible-builder` with `ansible-galaxy` or `ansible-playbook`, mistakenly thinking that building an execution environment uses the same command as building a collection or running a playbook.

How to eliminate wrong answers

Option A is wrong because `ansible-playbook` is used to run playbooks, not to build execution environments; there is no `build` subcommand for `ansible-playbook`. Option C is wrong because `ansible-execution-environment` is not a valid Ansible command; the correct command is `ansible-builder`. Option D is wrong because `ansible-galaxy build` is used to build a collection from a `galaxy.yml` file, not an execution environment from an `execution-environment.yml` file.

Practice this question →
50
MCQmedium

Your organization is migrating from manually maintained control nodes to using execution environments. You have created an execution environment that includes all necessary collections and Python dependencies. You want to ensure that developers use this execution environment when running playbooks. You have configured ansible-navigator on their workstations. However, some developers report that when they run a playbook, it uses the local installation of Ansible instead of the execution environment. What should you check first?

A.Confirm that the developers have installed ansible-builder locally.
B.Ensure that the developers are using the 'ansible-navigator run' command instead of 'ansible-playbook'.
C.Verify that the ansible-navigator configuration file points to the correct execution environment image.
D.Check that the execution environment container is running on the developers' machines.
AnswerB

ansible-navigator run executes playbooks inside the configured execution environment, whereas ansible-playbook uses the locally installed Ansible. Verifying the command used directly addresses the reported behaviour of falling back to local Ansible despite correct navigator configuration.

Why this answer

`ansible-navigator` is the CLI tool designed to run Ansible inside an execution environment. If developers run `ansible-playbook` directly, it uses the locally installed Ansible, bypassing the execution environment entirely. The question states that `ansible-navigator` is configured on their workstations, but the developers must use the `ansible-navigator run` subcommand to invoke playbooks within the containerized environment.

Exam trap

The trap here is that candidates often focus on configuration details (like the image path in the config file) or container status, missing the fundamental point that the command itself (`ansible-playbook` vs `ansible-navigator run`) determines whether the execution environment is used.

How to eliminate wrong answers

Option A is wrong because `ansible-builder` is used to build execution environment images, not to run playbooks; its absence does not affect whether a playbook runs locally or in an execution environment. Option C is wrong because while the configuration file pointing to the correct image is important, the primary issue is that developers are using the wrong command (`ansible-playbook`), which ignores the execution environment entirely regardless of the configuration. Option D is wrong because the execution environment container does not need to be running continuously; `ansible-navigator run` pulls and starts the container on demand, so checking if it is running is irrelevant to the reported problem.

Practice this question →
51
MCQhard

Your team maintains a collection that depends on a module requiring the Python library netaddr. You are building an execution environment with ansible-builder and need that library available inside the image at run time. The collection itself is installed from a private Automation Hub. Which approach ensures the Python dependency is present in the execution environment?

A.Add netaddr to the requirements.txt referenced by the dependencies.python section of execution-environment.yml.
B.List netaddr under dependencies.galaxy in execution-environment.yml so ansible-galaxy installs it with the collection.
C.Install netaddr on the control node and rely on the module using the control node's Python environment.
D.Add netaddr to the collection's runtime.yml under the requires_ansible key.
AnswerA

The dependencies.python section of execution-environment.yml points to a requirements.txt that ansible-builder installs into the image. Listing netaddr there ensures the Python library is present for the module at run time. This is the supported way to add Python packages to an execution environment and works regardless of where the collection itself is hosted.

Why this answer

Python libraries needed by modules must be installed into the execution environment image during the build. The dependencies.python section of execution-environment.yml references a pip requirements file, and listing netaddr there causes ansible-builder to install it into the image. Collection metadata and Galaxy dependency lists do not install Python packages, and installing on the control node has no effect inside the container.

Exam trap

The trap here is confusing collection dependencies with Python dependencies, leading to placing a pip package in the Galaxy requirements list.

Practice this question →
52
MCQeasy

A developer wants to create a new Ansible collection from a skeleton template. Which command should be used?

A.`ansible-galaxy collection generate my_namespace.my_collection`
B.`ansible-galaxy collection create my_namespace.my_collection`
C.`ansible-galaxy collection start my_namespace.my_collection`
D.`ansible-galaxy collection init my_namespace.my_collection`
AnswerD

`ansible-galaxy collection init` scaffolds the namespace.collection skeleton, generating galaxy.yml, plugins, roles and docs directories. The stem requires creating a new collection from a template, and this subcommand is the only one that produces that structure rather than installing or building an existing collection.

Why this answer

The correct command is `ansible-galaxy collection init my_namespace.my_collection`, which creates a new collection skeleton with the required directory structure and metadata files. This is the official Ansible command for bootstrapping a collection from a template.

Exam trap

The trap here is that candidates often confuse the `ansible-galaxy` subcommands for roles (`init` for roles) with those for collections, or they misremember the verb as `create` or `generate`, which are not valid for collection initialization.

How to eliminate wrong answers

Option A is wrong because `ansible-galaxy collection generate` is not a valid subcommand; the correct verb is `init`. Option B is wrong because `ansible-galaxy collection create` does not exist; `create` is used for roles, not collections. Option C is wrong because `ansible-galaxy collection start` is not a valid Ansible command; `start` is not a recognized subcommand for collections.

Practice this question →
53
MCQmedium

Refer to the exhibit. A user runs ansible-runner with --container-image localhost/ee-30:latest and receives the error shown. What is the most likely cause?

A.The container image tag is incorrect.
B.The ansible-runner process does not have network access.
C.The execution environment is not listed in the project's execution-environment.yml.
D.The container image has not been pulled or built locally.
AnswerD

ansible-runner does not pull images automatically. With --container-image localhost/ee-30:latest, the image must already exist in the local container storage; if it was never pulled or built, the runtime cannot resolve the reference and fails immediately.

Why this answer

The error indicates that the container image `localhost/ee-30:latest` is not available locally. The `--container-image` flag tells ansible-runner to use a specific execution environment image, but if that image has not been pulled from a registry or built locally, the container runtime (e.g., Podman or Docker) cannot find it. Option D is correct because the image must exist in the local container storage before ansible-runner can launch it.

Exam trap

Red Hat often tests the distinction between local image availability and network access, leading candidates to incorrectly assume that ansible-runner automatically pulls missing images when it does not by default.

How to eliminate wrong answers

Option A is wrong because the tag `latest` is valid and the error does not mention an invalid tag format; a missing image error would occur regardless of tag correctness if the image is not present. Option B is wrong because the error message indicates the image is not found locally, not that network access is blocked; ansible-runner does not attempt to pull the image when `--container-image` is used unless `--container-option` or `--container-pull` is explicitly set. Option C is wrong because the execution-environment.yml file is used by Automation Controller (formerly Ansible Tower) to define execution environments for job templates, not by the `ansible-runner` command-line tool; ansible-runner directly uses the image specified via `--container-image`.

Practice this question →
54
MCQeasy

A developer is creating a new content collection named acme.tools to distribute internal modules and roles. Which command initializes the collection with the standard directory skeleton, including the galaxy.yml metadata file?

A.ansible-galaxy collection init acme.tools
B.ansible-galaxy collection create acme.tools
C.ansible-builder create acme.tools
D.ansible-galaxy init acme.tools --type collection
AnswerA

The ansible-galaxy collection init command creates the collection directory structure and a galaxy.yml metadata file, which is the starting point for a new collection. It scaffolds the standard layout with roles, plugins, and other directories so the developer can begin adding content and later build and publish the collection.

Why this answer

To scaffold a new collection, use ansible-galaxy collection init followed by the namespace and collection name. This generates the standard directory layout and the galaxy.yml metadata file that describes the collection. Other ansible-galaxy subcommands such as build and publish operate on an existing collection, and ansible-builder is unrelated to collection initialization.

Exam trap

The trap here is using the role-oriented ansible-galaxy init form instead of the collection-specific subcommand.

Practice this question →
55
Multi-Selectmedium

Which TWO statements about execution environments are true?

Select 2 answers
A.Execution environments can include both Ansible and system dependencies.
B.Execution environments cannot be used with ansible-playbook directly.
C.Execution environments must be built using ansible-builder.
D.Ansible Navigator is required to use execution environments.
E.Execution environments are OCI containers.
AnswersA, E

Execution environments are container images bundling both the Ansible runtime (ansible-core, collections) and the system-level dependencies those modules require, such as Python libraries, RPMs and binaries. This dual inclusion is what makes them portable and reproducible across control nodes.

Why this answer

Option A is correct because an execution environment is an OCI container image that bundles the Ansible Core/ansible-runner runtime together with collections, Python libraries, and system-level dependencies (RPMs, etc.), so it can carry both Ansible and system dependencies. Option E is correct because execution environments are distributed and consumed as OCI container images (e.g., via podman or docker registries), which is the packaging format that makes them portable and reproducible. Option B is wrong because ansible-playbook can be run inside an execution environment (for example, via ansible-navigator or by invoking the container directly), so they are not incompatible.

Option C is wrong because ansible-builder is only one tool for creating execution environments; they can also be built with a Containerfile/Dockerfile or other tooling. Option D is wrong because Ansible Navigator is a convenience CLI for running and inspecting execution environments, but it is not required — podman/docker or ansible-runner can use them directly.

Exam trap

Red Hat often tests the misconception that `ansible-builder` is the only way to build execution environments, but candidates must remember that any OCI-compliant container build tool (e.g., Dockerfile) can be used, and pre-built images can be pulled from a registry.

Practice this question →
56
MCQeasy

Which key in the galaxy.yml file defines the collection's namespace?

A.collection
B.authors
C.name
D.namespace
AnswerD

The namespace key in galaxy.yml declares the collection's namespace, which forms the first part of the fully qualified collection name used for installation and referencing. It must match the Automation Hub namespace the collection is published under.

Why this answer

The `namespace` key in the `galaxy.yml` file explicitly defines the collection's namespace, which is the first part of the fully qualified collection name (FQCN) and is used to organize collections under a specific publisher or organization on Ansible Galaxy. This is a required field in the `galaxy.yml` metadata file, as per the Ansible Collection structure.

Exam trap

Red Hat often tests the distinction between `namespace` and `name` in `galaxy.yml`, knowing candidates may confuse the two or think `namespace` is implied by the directory structure rather than explicitly defined in the file.

How to eliminate wrong answers

Option A is wrong because `collection` is not a valid key in `galaxy.yml`; the file itself describes a collection, but no such key exists. Option B is wrong because `authors` is a metadata field listing the collection's authors, not the namespace. Option C is wrong because `name` defines the collection's short name (the second part of the FQCN), not the namespace.

Practice this question →
57
MCQeasy

An admin wants to build an execution environment using ansible-builder. Which file is required to define the base image and additional Python dependencies?

A.execution-environment.yml
B.requirements.yml
C.galaxy.yml
D.Dockerfile
AnswerA

The execution-environment.yml file is the definition file ansible-builder consumes, specifying the base image and Python dependencies under its build and dependencies keys. Without it, ansible-builder has no blueprint to construct the execution environment, so it satisfies the requirement to declare both the base image and additional Python packages.

Why this answer

`execution-environment.yml` is the required file for `ansible-builder` to define the base image (via the `base_image` field) and additional Python dependencies (via the `python` section under `dependencies`). This YAML file serves as the build definition that `ansible-builder` reads to construct the container image, making it essential for creating custom execution environments.

Exam trap

Red Hat often tests the distinction between files used by different Ansible tools—candidates confuse `requirements.yml` (for collections/roles) or `galaxy.yml` (for collection metadata) with the `execution-environment.yml` file that is specifically required by `ansible-builder`.

How to eliminate wrong answers

Option B is wrong because `requirements.yml` is used by `ansible-galaxy` to install Ansible collections or roles, not by `ansible-builder` to define the base image or Python dependencies. Option C is wrong because `galaxy.yml` is a metadata file for Ansible collections (e.g., defining namespace, version, and dependencies), not for building execution environments. Option D is wrong because while `ansible-builder` internally generates a Dockerfile, the user does not provide it directly; the required input file is `execution-environment.yml`, which `ansible-builder` processes to produce the Dockerfile and build context.

Practice this question →
58
MCQmedium

A team wants to use a certified collection from Red Hat Automation Hub but cannot access it directly due to firewall restrictions. What is the best practice?

A.Download the collection manually and install from a tarball.
B.Set up a private Automation Hub and sync the collection.
C.Copy the collection from another team's workspace.
D.Use ansible-galaxy collection install with --offline flag.
AnswerB

A private Automation Hub mirrors certified collections internally, so the firewall-restricted team syncs content from an on-premises repository rather than reaching Red Hat Automation Hub directly. This preserves certified content while satisfying network isolation requirements.

Why this answer

Setting up a private Automation Hub and syncing the certified collection is the best practice for environments with firewall restrictions. This approach ensures that the collection remains in a trusted, curated state, is automatically updated, and can be consumed by all team members via `ansible-galaxy` without manual intervention, maintaining compliance with Red Hat's support policies.

Exam trap

The trap here is that candidates often assume manual download (Option A) is acceptable for firewall restrictions, but Red Hat's best practice emphasizes using a private Automation Hub to maintain supportability and consistency across the enterprise.

How to eliminate wrong answers

Option A is wrong because manually downloading and installing from a tarball bypasses the dependency resolution and version tracking provided by Automation Hub, leading to potential inconsistencies and unsupported configurations. Option C is wrong because copying a collection from another team's workspace introduces risks of untracked modifications, missing dependencies, and violates Red Hat's best practices for centralized, version-controlled content management. Option D is wrong because the `--offline` flag does not exist in `ansible-galaxy collection install`; the correct flag is `--no-deps` for offline scenarios, but this still requires the collection to be available locally and does not address the firewall restriction for initial access.

Practice this question →
59
MCQeasy

A system administrator wants to build an Ansible execution environment using ansible-builder. Which file format is required to define the base image, dependencies, and additional Python packages for the build?

A.execution-environment.yml
B.ansible-navigator.yml
C.Containerfile
D.requirements.yml
AnswerA

The `execution-environment.yml` file is the definition file ansible-builder consumes, with its `dependencies` section specifying the base image, Galaxy collections, and Python packages. This directly satisfies the stem's requirement to define all three build inputs in one file, unlike an inventory or playbook.

Why this answer

`ansible-builder` requires an `execution-environment.yml` file to define the build context, including the base image (under `version: 1`), system-level dependencies (under `dependencies: system:`), and additional Python packages (under `dependencies: python:`). This file is the mandatory definition file for building an Ansible Execution Environment (EE) using `ansible-builder build`.

Exam trap

The trap here is that candidates confuse the build input file (`execution-environment.yml`) with the runtime configuration file (`ansible-navigator.yml`) or with the generated output (`Containerfile`), leading them to pick the wrong option.

How to eliminate wrong answers

Option B is wrong because `ansible-navigator.yml` is the configuration file for `ansible-navigator`, a tool used to run and inspect execution environments, not for building them with `ansible-builder`. Option C is wrong because a `Containerfile` (or `Dockerfile`) is a lower-level container build file that `ansible-builder` generates from `execution-environment.yml`; it is not the input file the administrator writes. Option D is wrong because `requirements.yml` is used by `ansible-galaxy` to install collections and roles, not by `ansible-builder` to define the base image or Python packages for an execution environment build.

Practice this question →
60
MCQhard

An execution environment fails to build because `pip install` fails when installing a Python package from a private repository that requires authentication. The build works when run locally by the developer. Which approach should be taken to securely provide credentials during the `ansible-builder build` process?

A.Store the credentials in the Automation Hub token and reference it.
B.Add the credentials directly to the `Containerfile` that `ansible-builder` generates.
C.Include the credentials in the `execution-environment.yml` under `dependencies: python:`.
D.Create a `pip.conf` file that uses environment variables or BuildKit secrets to inject credentials.
AnswerD

A pip.conf referencing environment variables or BuildKit secrets keeps credentials out of image layers and build context, satisfying the requirement to authenticate to the private repository securely during ansible-builder build without exposing secrets in the resulting image.

Why this answer

`ansible-builder` supports BuildKit secrets and environment variable injection via a `pip.conf` file, allowing credentials to be passed securely at build time without hardcoding them into the execution environment definition. This approach ensures that sensitive authentication tokens are not exposed in the `execution-environment.yml` or the generated `Containerfile`, and it mirrors the local developer workflow where environment variables or secret mounts are used.

Exam trap

The trap here is that candidates often assume credentials must be placed directly in the execution environment definition file or the generated Containerfile, overlooking the secure, build-time injection mechanisms provided by BuildKit secrets and environment variables.

How to eliminate wrong answers

Option A is wrong because Automation Hub tokens are used for authenticating to Automation Hub itself, not for private Python package repositories; they cannot be referenced in a `pip.conf` or passed to `pip install` for external registries. Option B is wrong because adding credentials directly to the `Containerfile` would hardcode secrets into the image layers, violating security best practices and making the credentials visible to anyone with access to the image. Option C is wrong because the `dependencies: python:` section in `execution-environment.yml` only lists package names and versions, not authentication credentials; it does not support inline credentials or secret injection.

Practice this question →
61
MCQmedium

A platform team maintains an execution environment definition where `requirements.yml` lists several collections. They need to pin `community.general` to a specific version range so that only releases from 7.0.0 up to but not including 8.0.0 are installed during the build. Which syntax inside `requirements.yml` accomplishes this?

A.- name: community.general version: "^7.0.0"
B.- name: community.general version_range: ">=7.0.0 <8.0.0"
C.- name: community.general version: ">=7.0.0,<8.0.0"
D.- name: community.general version: "7.x"
AnswerC

Collection requirements in `requirements.yml` accept a `version` field using standard version specifiers. The comma-separated range `>=7.0.0,<8.0.0` tells the resolver to install any 7.x release but nothing from 8.0.0 onward. This is the documented way to constrain a collection to a major version line when building an execution environment.

Why this answer

Ansible collection requirements use the `version` key with Python-style comparison operators. Combining a lower bound and an exclusive upper bound in a single quoted string yields the desired 7.x-only range, which is the only syntax among the choices that the resolver actually understands when building the execution environment.

Exam trap

The trap here is assuming npm or wildcard version syntax works in Ansible requirements files; only Python-style specifier strings are honored by the collection resolver.

Practice this question →
62
MCQeasy

A system administrator wants to publish a custom Ansible collection to a private Automation Hub. What is the correct command to build the collection before publishing?

A.ansible-galaxy collection init mycollection
B.ansible-galaxy collection publish ./mycollection-1.0.0.tar.gz
C.ansible-galaxy collection install .
D.ansible-galaxy collection build
AnswerD

The ansible-galaxy collection build command packages the collection directory into a tarball artefact containing the galaxy.yml manifest, roles, plugins and modules. This tarball is the required input for ansible-galaxy collection publish, so building must precede uploading to the private Automation Hub.

Why this answer

`ansible-galaxy collection build` is the command that compiles the collection directory into a distributable tarball (e.g., `mycollection-1.0.0.tar.gz`), which is the required artifact for publishing to a private Automation Hub. Without this build step, there is no archive to upload.

Exam trap

The trap here is that candidates confuse the `publish` command (which uploads an existing tarball) with the `build` command (which creates the tarball), leading them to select option B instead of D.

How to eliminate wrong answers

Option A is wrong because `ansible-galaxy collection init` creates the skeleton directory structure for a new collection, not the build artifact needed for publishing. Option B is wrong because `ansible-galaxy collection publish` uploads an already-built tarball to Automation Hub, but the question asks for the command to build the collection before publishing. Option C is wrong because `ansible-galaxy collection install` downloads and installs a collection from a source (like a galaxy server or a tarball), not builds one for distribution.

Practice this question →
63
MCQhard

You are building an execution environment using ansible-builder with a definition that includes a base image and a list of collections. During the build, you need to run a custom shell command to install an additional system package that is not available via the standard package manager configuration. Which section of the execution-environment.yml file should you use to add this custom build step?

A.options
B.dependencies
C.additional_build_steps
D.build_arg_defaults
AnswerC

The additional_build_steps section in execution-environment.yml allows you to insert custom commands at various stages of the build process, such as before or after specific steps. You can define commands to run before assembling the final image, enabling installation of system packages or other customizations that are not covered by the standard dependencies.

Why this answer

The additional_build_steps section is designed to inject custom commands into the execution environment build process. It supports stages like prepend_base, append_base, prepend_galaxy, etc., allowing you to run shell commands before or after key build phases. This is the correct way to install system packages or perform other customizations that are not handled by the standard dependencies section.

Exam trap

The trap here is assuming that the dependencies section can handle arbitrary system package installation, when in fact it only supports package lists from repositories and cannot run custom commands.

Practice this question →
64
MCQhard

An admin attempts to build an execution environment using the exhibited files. The build fails with an error about incompatible Python dependency. What is the most likely cause?

A.The Python requirements.txt tries to install a version of Ansible that conflicts with the version in the base image.
B.The execution-environment.yml file uses incorrect syntax for the 'dependencies' section.
C.The collections in requirements.yml are not fully qualified.
D.The base image 'ee-minimal-rhel8' is not a valid execution environment base image.
AnswerA

The base execution environment image already ships a pinned ansible-core version; requirements.txt requesting a different version forces pip to resolve an incompatible set, so the build aborts with a dependency conflict rather than installing cleanly.

Why this answer

The build fails because the Python `requirements.txt` file attempts to install a version of Ansible that conflicts with the version already present in the base image `ee-minimal-rhel8`. Execution environments are designed to include a specific Ansible version in the base image; adding a different version via pip creates a dependency conflict that breaks the build.

Exam trap

The trap here is that candidates often assume the error is due to syntax or invalid base images, but the question specifically mentions 'incompatible Python dependency,' which directly points to a version conflict in the pip requirements.

How to eliminate wrong answers

Option B is wrong because the `execution-environment.yml` file syntax for the 'dependencies' section is correct as shown in the exhibit (it uses a list of file references). Option C is wrong because collections in `requirements.yml` do not need to be fully qualified; they can be specified with just the collection name, and the build would still succeed. Option D is wrong because `ee-minimal-rhel8` is a valid Red Hat-provided execution environment base image, and the error message specifically points to a Python dependency conflict, not an invalid base image.

Practice this question →

Ready to test yourself?

Try a timed practice session using only Create content collections and execution environments questions.

Start 20-question session