What is an Ansible collection, how does it relate to roles, and what does a fully qualified name such as community.general.timezone refer to?

## Why collections exist Up to Ansible 2.9 the project shipped as one enormous repository: thousands of modules for every cloud, network vendor and database, all released on the engine's schedule. A fix to a single cloud module waited for the next Ansible release. The 2.10 split separated the **engine** (`ansible-core`) from the **content** (collections), so each collection versions and releases independently. The `ansible` package on PyPI is a curated bundle of `ansible-core` plus a large set of collections; installing `ansible-core` alone gives you only `ansible.builtin`. ## What is in a collection A collection is a directory tree with a `galaxy.yml` manifest and roughly this shape: ``` my_namespace/my_collection/ galaxy.yml plugins/ modules/ lookup/ filter/ roles/ playbooks/ docs/ ``` So it can carry modules, any plugin type, complete roles, and even playbooks. `ansible-galaxy collection init my_namespace.my_collection` scaffolds it, `ansible-galaxy collection build` produces a tarball, and `ansible-galaxy collection publish` pushes it to Galaxy or a private hub. ## Roles versus collections They answer different questions. A **role** is a unit of *organisation* inside your automation - a directory layout for one coherent piece of configuration. A **collection** is a unit of *distribution* - a versioned, namespaced package. The relationship is containment: a collection may ship zero, one or many roles, addressed as `namespace.collection.rolename`: ```yaml - hosts: web tasks: - name: Apply a role that ships inside a collection ansible.builtin.import_role: name: my_namespace.my_collection.webserver ``` Standalone roles installed from Galaxy still work - `ansible-galaxy role install geerlingguy.nginx` - and remain common. But new shared content, especially anything that includes custom modules or plugins, is published as a collection, because a collection can version its plugins alongside its roles while a standalone role's `library/` directory cannot be depended on cleanly. ## Fully qualified collection names An FQCN has three dot-separated parts: namespace, collection, content name. - `ansible.builtin.copy` - the `copy` module built into `ansible-core`. - `community.general.timezone` - the `timezone` module from `community.general`. - `amazon.aws.ec2_instance` - the EC2 instance module from `amazon.aws`. Short names such as `copy:` still resolve, through a search path that prefers `ansible.builtin` and then any collections listed in the play's `collections:` keyword. The reason to write FQCNs anyway is determinism: a short name's meaning depends on what is installed and on the search order, so the same playbook can bind a different module on a different control node. Linting tools flag bare module names for exactly this reason, and FQCNs also make the dependency obvious to a reader - `amazon.aws.ec2_instance` tells you which collection must be installed, `ec2_instance` does not. ## Installing and declaring ```yaml # requirements.yml collections: - name: community.general version: "8.6.1" - name: amazon.aws version: "7.5.0" roles: - src: geerlingguy.nginx version: "3.1.4" ``` `ansible-galaxy collection install -r requirements.yml` installs the collections; `ansible-galaxy role install -r requirements.yml` installs the standalone roles. Collections resolve to a collections path (project-local with `-p`, otherwise a user or system path); roles resolve to `roles_path`. A collection may also declare its own dependencies on other collections in `galaxy.yml`, which `ansible-galaxy` resolves at install time. ## What interviewers are checking That you know the ecosystem you are working in is post-split: that a missing module is usually a missing *collection* rather than a broken Ansible, that `requirements.yml` is where dependencies are declared, and that FQCNs are not verbosity for its own sake. A candidate who still describes Ansible as "one big install with every module" is describing 2.9.