This guide demonstrates a practical workflow for diagnosing and fixing a broken Ansible playbook by running it, collecting real error output, and iterating with ChatGPT. The goal is to correct syntax, module usage, and variable issues while following Ansible best practices. What you’ll learn:Documentation Index
Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
Use this file to discover all available pages before exploring further.
- How to run a broken playbook and capture errors
- Which common mistakes cause playbooks to fail
- How to iterate with ChatGPT (or another LLM) to produce a corrected playbook
- Best practices: FQCNs, correct service names, and privilege escalation
Scenario
You joined a DevOps team that uses Ansible. Playbooks were written at different times by different people (and sometimes generated by AI). Many fail on first run or show syntax errors. Your task: take a broken playbook, run it, gather errors, and iterate with ChatGPT until the playbook runs successfully on the target hosts.Environment
I switched into a VM in the working directory namedbuggy. The inventory and Ansible config are already present.
site.yml (or site.yaml) and iterate until fixed.
Open the repository in an editor (VS Code) to inspect and edit site.yml.


Common issues found
ChatGPT identified the following key problems and recommended fixes. The table below summarizes each issue and what to change.| Problem | Why it fails | Recommended fix |
|---|---|---|
Nonexistent module name dnf_install | Not an Ansible module — causes module not found | Use ansible.builtin.dnf (FQCN preferred) or dnf |
Wrong service name apache2 on RHEL/CentOS | RHEL uses httpd service name | Use httpd for service operations |
Incorrect file path /var/www/html.index.html | Typo — invalid path | Correct to /var/www/html/index.html |
| Inconsistent become values | become: yes is okay, but use become: true consistently | Use become: true at play or task level |
| Linting/compliance | Not using FQCNs and missing file ownership/permissions | Use ansible.builtin.*, set owner, group, mode as needed |
| Handler notifications mismatch | notify name must match handler name exactly (case-sensitive) | Define handler matching notify string |
Fixed playbook
After iterating with ChatGPT, incorporating the correct context (RHEL target, need for privilege escalation, best practices), we consolidated a single corrected playbook. It uses FQCNs,become: true, correct service/module names, and properly configured handlers.
Always verify the environment (OS/distribution), service names, and file ownership before applying changes to production systems. Run playbooks against a non-production or test host first.
Run the corrected playbook
Save the fixed file assite.yml, then execute it with ansible-playbook:
Conclusion
Iteratively feeding real error output and context to ChatGPT can speed up diagnosing and fixing broken playbooks. Key takeaways:- Provide correct context up front (OS distribution, required privileges, intended service names).
- Prefer FQCNs (ansible.builtin.*) to satisfy linters and avoid ambiguity.
- Test playbooks on non-production hosts before rolling out changes.
- Human review remains essential: validate generated changes and verify ownership/permissions.
Links and References
Further reading:- Ansible module index and FQCN guidance in official docs
- Best practices for handlers and notifications