Skip to main content
In this lesson we explore the Modules and Plugins Index — Ansible’s central directory for finding the exact module or plugin you need. When managing devices such as Cisco routers, you want a purpose-built module or collection you can rely on from a playbook. The index helps you find that content quickly and safely.
A web UI titled "Configure the Network Devices" showing a Routers panel with four device cards: edge-router-01, edge-router-02, core-router-01, and core-router-02 (cisco.ios). A search-style pill at the top right reads "A module built for this exact device."
Why use the index? With thousands of modules and plugins available, guessing doesn’t scale. The index provides search, filters, and links to authoritative documentation and examples so you can identify the correct collection or module and how to use it. Search by keyword or category (for example, network or cisco.ios), and the index returns matching entries. Each entry links to its documentation, usage examples, and version compatibility notes — everything you need to adopt it into a playbook.
A clean webpage UI with the heading "Filter on Cisco" and a single highlighted card reading "01 Cisco IOS Content" next to a blue stacked-layers icon. A small KodeKloud logo appears in the bottom-left corner.
A key concept in modern Ansible is collections. Vendor support (for example Cisco IOS) is shipped as collections rather than one monolithic module. That means you find the cisco.ios collection first, then pick the specific module inside it (for example ios_config or ios_facts).
A side-by-side diagram titled "A Detail That Changes How You Search" comparing the old Ansible model (one big module shown as cisco_ios) with Modern Ansible (a collection shown as cisco.ios).
Each module is referenced by a fully qualified collection name (FQCN): three dot-separated parts — namespace.collection.module. Using an FQCN in your playbook ensures Ansible runs the exact code you expect and avoids ambiguity.
A slide explaining the Ansible name "cisco.ios.ios_config" read left-to-right, with three numbered cards labeling "cisco" as the namespace, "ios" as the collection, and "ios_config" as the module. A "Find the collection first" button is shown below.
Always prefer the FQCN (for example cisco.ios.ios_config) in playbooks to avoid conflicts between similarly named modules from different collections.
Below is a simple playbook task using the cisco.ios.ios_config module to set a device hostname:
Install the collection from Ansible Galaxy before using it:
You can view module documentation locally with ansible-doc. Query a single module to see options and examples, or list everything a collection provides with -l:
Sample (condensed) output:
To list all modules and plugins in a collection:
Recent context for network gear: a change in Ansible Core 2.19 tightened templating and typing rules. That change temporarily broke some network collections and the shared ansible.netcommon content they depended on until follow-up fixes were released. Several vendor collections were affected, including cisco.ios, arista.eos, and junipernetworks.junos.
A slide titled "Recent Context for Network Gear" notes that a core release changed what network collections could rely on. To the right is a blue-bordered card with a stacked-layers icon labeled "ansible-core 2.19 · mid 2025."
When upgrading Ansible Core, upgrade your network collections at the same time and test together. Do not bump Core alone in production without validating collection compatibility.
There is a shared network layer (ansible.netcommon) used by multiple vendor collections. If a shared layer changes, multiple vendor collections can be affected at once.
A slide titled "One Shared Layer, Three Vendors" showing two connected boxes: the left box labeled "ansible.netcommon — Shared network content" and the right box labeled "Vendor Collections."
If you still see older community collections such as community.network, know that much of that content has been superseded by vendor-provided collections. Prefer vendor collections (for example, cisco.ios) when available — they tend to be better maintained and tested against the vendor’s platforms.
A two-column graphic titled "Prefer the Vendor Collection." The left card shows "community.network" marked Deprecated with "Avoid it for new work," and the right card shows "cisco.ios" marked Preferred.
Why the index matters — four core benefits:
A clean webpage graphic titled "Four Things the Index Gives You" showing four numbered cards: 01 Search and Filtering, 02 Detailed Documentation, 03 Version Compatibility, and 04 Community Contributions, each with brief explanatory text. The design uses large colored numbers and short descriptions in a boxed layout.
In short: use the Modules and Plugins Index as your searchable, community-maintained directory to move from “I hope something exists” to “I know exactly which collection and module to use.” Links and references

Watch Video

Practice Lab