Ansible Error: '... is not a valid attribute for a Task' — Cause, Fix, and Troubleshooting Guide
Fix Ansible's 'X is not a valid attribute for a Task/Play' error: misindented module args, misspelled keywords, or module params placed at the task level.
- #ansible
- #troubleshooting
- #automation
- #playbooks
Stuck on this Ansible error? Get the free incident triage checklist
A one-page PDF — the exact steps to isolate, fix, and verify a production error like this one. No spam, unsubscribe anytime.
Overview
Every task, play, and block accepts a fixed set of keywords (name, when, loop, become, register, etc.). If Ansible finds a key at that level that is not a recognized keyword — almost always because module parameters were indented one level too shallow, or a keyword is misspelled — it refuses to load the playbook:
ERROR! 'state' is not a valid attribute for a Task
The error appears to be in '/etc/ansible/playbooks/site.yml': line 12, column 7
The offending key (state, path, src, mode, etc.) is usually a module parameter that ended up as a task attribute.
Symptoms
- The play fails to parse; no host is contacted.
- The error points at a real line and a key that belongs to a module, not a task.
- It appeared right after editing indentation or adding a parameter.
ansible-playbook -i inventory.ini site.yml --syntax-check
ERROR! 'mode' is not a valid attribute for a Task
Common Root Causes
1. Module parameters indented at the task level
The module name and its parameters must be nested under the module key. Flattening them makes state:/path: look like task keywords.
2. Misspelled task keyword
whenn:, regsiter:, notifiy: — a typo Ansible does not recognize.
3. A module parameter used without the module
Writing path: and state: with no module key at all.
4. loop/with_* or become misplaced
Placing a valid keyword under the module dict, or a module arg above it.
How to diagnose
Run a syntax check to get the exact line and column:
ansible-playbook site.yml --syntax-check
Inspect the indentation of the flagged task — module args should sit two spaces deeper than the module name:
sed -n '8,16p' site.yml | cat -A | head
Fixes
Nest module parameters under the module
Wrong (parameters at task level):
- name: Create directory
ansible.builtin.file:
path: /opt/app # WRONG: indented at task level
state: directory
Right:
- name: Create directory
ansible.builtin.file:
path: /opt/app # nested under the module
state: directory
mode: "0755"
Fix a misspelled keyword
- name: Restart nginx
ansible.builtin.service:
name: nginx
state: restarted
when: reload_needed # not "whenn"
Keep task keywords at the task level
- name: Install packages
ansible.builtin.apt:
name: "{{ item }}"
state: present
loop: # loop is a task keyword, not a module arg
- nginx
- curl
What to watch out for
- YAML indentation is the usual culprit — two spaces per level, no tabs.
--syntax-checkcatches this before a real run. - The same error says
for a Playwhen a task-level keyword (liketasks:siblings) is misplaced at the play level. - Editors that mix tabs and spaces produce this constantly; enable “show whitespace” or run
yamllint.
Related
- Ansible Error: ‘Syntax Error while loading YAML’
- Ansible Error: ‘unsupported parameters for module’
- Ansible Error: ‘The conditional check failed’
Fixed it? Get 500 Ansible & DevOps AI prompts — free
500 battle-tested, copy-paste AI prompts engineered by a senior systems engineer — every one with fill-in placeholders and safety/back-out notes. Drop your email and it's yours.
- 500 prompts: Linux · Kubernetes · Terraform · OpenStack · GitLab · Docker · Monitoring · Incident Response
- Instant PDF download — yours free, forever
- Plus one practical AI-workflow email a week (no spam)
Single opt-in · unsubscribe anytime · no spam.
Stuck on this? Start guided troubleshooting
Open an interactive diagnostic session with this error already loaded. Work a step-by-step plan, record what each check returns, land on a root cause, and export a clean incident summary — no account needed to start.
Did this fix your issue?
Solved it a different way?
Share the fix that worked for you — reviewed, then published to help the next engineer.
That looks like it may contain a secret (key, token, password, or connection string). Please remove it — a note with a detected secret can’t be published.
Thanks — that helps. Published notes appear after a quick review.
More Ansible prompts & error guides
Every Ansible AI prompt and troubleshooting guide, in one place.
Trending errors this week
The error guides other engineers are actually reading right now.
- 1mount: wrong fs type, bad option, bad superblock
- 2Docker 'failed to set up container networking': Fix the Bridge and IP Pool
- 3Docker 'failed to create shim task': How to Fix the containerd Runtime Error
- 4Transport endpoint is not connected
- 5modprobe: FATAL: Module not found
- 6mount: wrong fs type, bad option, bad superblock
Get 500 Battle-Tested DevOps AI Prompts — Free
500 battle-tested, copy-paste AI prompts engineered by a senior systems engineer — every one with fill-in placeholders and safety/back-out notes. Drop your email and it's yours.
- 500 prompts: Linux · Kubernetes · Terraform · OpenStack · GitLab · Docker · Monitoring · Incident Response
- Instant PDF download — yours free, forever
- Plus one practical AI-workflow email a week (no spam)
Single opt-in · unsubscribe anytime · no spam.