This is a follow up to my previous post Mastering Dynamic Task Includes in Ansible. Because include_tasks evaluates variables at runtime (right when the play reaches that specific step), Ansible has no idea whether the target file actually exists when the playbook first starts. If a user passes a typo like action=instal instead of install, Ansible will execute every task right up to your include step, and then crash with a fatal “file not found” error. To prevent this, we use the with_first_found lookup plugin. It scans a list of files sequentially and includes the first one it actually finds on disk. By designing a deliberate fallback strategy, default_action.yml can…

One of the best ways (and easy) to keep your Ansible playbooks clean, modular, and DRY (Don’t Repeat Yourself) is by using dynamic task includes. Instead of writing massive, conditional playbooks with dozens of when statements, you can let your data drive your execution. The core idea is beautifully simple: Depending on the value of the action variable (e.g., install, configure, or backup), Ansible will look for and execute install.yml, configure.yml, or backup.yml on the fly. Why Use This Pattern? ⚠️ The Gotchas (What to Watch Out For) While highly effective, include_tasks is evaluated at runtime, which introduces a couple of architectural quirks you need to design around. 1. The…