Your Ansible runs target EC2 instances that scale up and down all day, and the checked-in static inventory is permanently out of date. How do you move to a dynamic inventory, and why prefer an inventory plugin over an inventory script?

## The problem with a static file An autoscaling fleet invalidates a checked-in host list continuously. Every scale event makes the file wrong in one of two directions: a new host that no play configures, or a terminated host that every play now fails to reach. Patching it by hand is toil, and the file's mistakes are discovered during a run rather than in review. Dynamic inventory removes the file: the cloud API is asked at run time who exists. ## What a plugin config looks like An inventory plugin is configured by a YAML file that you pass to `-i` like any other inventory source. For EC2 the plugin ships in the `amazon.aws` collection, and the file name must end with `aws_ec2.yml` or `aws_ec2.yaml` for the plugin to claim it: ```yaml # inventory.aws_ec2.yml plugin: amazon.aws.aws_ec2 regions: - eu-west-1 filters: instance-state-name: running tag:Environment: prod keyed_groups: - key: tags.Role prefix: role - key: tags.Environment prefix: env compose: ansible_host: private_ip_address cache: true cache_plugin: jsonfile cache_timeout: 3600 ``` The plugin must be enabled — `ansible.cfg` carries an `enable_plugins` list under `[inventory]`, and non-default plugins have to appear in it. Then `ansible-playbook -i inventory.aws_ec2.yml site.yml` targets whatever exists right now. The important options are the ones that make the result *usable*, not merely current: - **`filters`** narrows the query at the API, so you do not pull an entire account. - **`keyed_groups`** manufactures groups from instance attributes, most usefully tags. This is the piece that lets existing plays keep saying `hosts: role_web` after the static groups are gone. - **`compose`** sets host variables from instance attributes — typically `ansible_host` from a private or public address, since the default host name may not be reachable from where the run happens. - **`hostnames`** controls what each host is called in the inventory, which matters because `host_vars` files and `--limit` arguments key off that name. - **`cache`** with a cache plugin and timeout stops every play in a run from re-querying the API. ## Why plugins, not scripts Before plugins, dynamic inventory meant an executable that Ansible ran, implementing a protocol: `--list` prints all hosts, groups and (via `_meta.hostvars`) host variables as JSON, and `--host <name>` prints one host's variables. That still works and you will meet it in older repositories, but everything around it is homemade: - **Configuration.** A script takes environment variables or its own config file; a plugin is a YAML file that lives beside the playbooks and is reviewed like code. - **Caching.** A script has to build its own; plugins use Ansible's cache plugins with a shared timeout. - **Credentials.** A plugin runs in the Ansible process, so it uses the collection's SDK and can read variables from an encrypted file; a script tends to accumulate its own credential handling. - **Grouping.** `keyed_groups` and `compose` are declarative and diffable. In a script, group construction is imperative code nobody wants to own. - **Maintenance.** The plugin ships with the collection and is updated with it. The script is a bespoke program with its own bugs. For an interview, the short version is: a script is an opaque program that must reimplement configuration, caching and grouping; a plugin is declarative YAML that inherits all three from Ansible. ## Operating it Three habits matter in production. First, **verify before you run**: `ansible-inventory -i inventory.aws_ec2.yml --graph` shows the groups the plugin invented, and `--list --yaml` shows the host variables it composed. Second, **be deliberate about caching**: a cache makes big accounts fast but means a freshly launched instance may be invisible until the timeout expires — acceptable for a nightly patch run, dangerous for a run intended to configure the instance that just booted. Third, **combine sources when you need to**: pointing `-i` at a *directory* containing both a static file and a plugin config merges them, which is how a fleet of cloud instances and two hand-managed appliances live in one inventory. Authentication should come from the ambient role — an instance profile or a pipeline's federated credentials — rather than long-lived keys pasted into the config. The plugin config is a reviewed file in the repository; it is exactly the wrong place for a secret.