Orthevs Orthevs Fathom new horizons
Μενού

Wiki workshop · Αγγλικά

Curriculum: Ansible

This curriculum structures the Ansible workshop from entry level to advanced operations and security review. It is designed for multi-day trainings, internal enablement tracks, and self-study.

Γλώσσα περιεχομένου · ΑγγλικάΜέγεθος · 146.1 KBdocs/curriculum-ansible-EN.md
Παραδείγματα workshop σε ZIP
Πρόοδος μάθησης στη web app

Σημειώστε κεφάλαια ως αναγνωσμένα, δείτε την πρόοδο ανάγνωσης και ολοκληρώστε πρακτικές ενότητες αφού ενεργοποιήσετε την προαιρετική web app. Η πρόοδος του workshop υπολογίζεται από τα κεφάλαια όλων των σελίδων τεκμηρίωσης. Οι επιλογές μένουν σε αυτή τη συσκευή· δεν υπάρχει λογαριασμός ή συγχρονισμός με server. Δεν απαιτείται εγκατάσταση. Η ανάκληση στις Ρυθμίσεις απορρήτου διαγράφει την πρόοδο.

Πρόοδος ανάγνωσης0%
0%
0 / 23 κεφάλαια που διαβάστηκαν

Δεν υπάρχει ακόμη ελληνική έκδοση αυτού του εγγράφου. Το περιεχόμενο εμφανίζεται στα αγγλικά.

Άλλη γλωσσική έκδοσηΓερμανικά ↗Ελληνικά ↗

Curriculum: Ansible

Stand: July 15, 2026

This curriculum structures the Ansible workshop from entry level to advanced operations and security review. It is designed for multi-day trainings, internal enablement tracks, and self-study.

1. Curriculum Goal

Deep Dive and Submission Example for Curriculum Goal

A complete treatment of Curriculum Goal contains both a technical artifact and a short domain explanation. The artifact can be an inventory, a playbook, a role, a template, a Vault file with dummy values, a CI configuration, or an evidence file. The explanation states why this path was chosen and which alternative was deliberately not used.

Submission Part Content Minimum Quality
target description what should be true after the run measurable and without hidden assumptions
scope evidence which hosts are affected output from --list-hosts or inventory graph
implementation which files were changed small reviewable YAML files
validation how it was checked syntax check, check mode, diff, real run, second run
risk decision what can go wrong privileges, secrets, external dependencies, and rollback considered

Minimal Artifacts for Curriculum Goal

text
submission/
  inventory/hosts.yml
  playbooks/site.yml
  evidence.md
  cleanup.md

For roles or collections, the structure expands:

text
submission/
  ansible.cfg
  collections/requirements.yml
  inventory/hosts.yml
  roles/<role>/defaults/main.yml
  roles/<role>/tasks/main.yml
  roles/<role>/handlers/main.yml
  playbooks/site.yml
  evidence.md

Grading Expectation for Curriculum Goal

A reviewable solution must be understandable to people who did not run it themselves. Screenshots or uncommented terminal output are not enough. Good evidence states context, command, relevant output, and assessment. If a module behaves differently in check mode, that limitation is explicitly documented.

Transfer to Real Teams

In a team context, Curriculum Goal is connected to code review, branch rules, CI, role ownership, release notes, and operational approval. Production-like usage also documents ownership, maintenance window, monitoring, alerting, and rollback criteria.

Practical Relevance of Curriculum Goal

This section is not just a definition. In the workshop, Curriculum Goal is always validated through a concrete flow: inspect inventory, prove target hosts, check the playbook, simulate the change, run the change, evaluate a second run, and document cleanup. This shows whether Ansible really models desired state or merely executes a command successfully once.

Review Question Expected Answer
Which hosts are affected? Pattern, group, --limit, and inventory output are documented.
Which data sources apply? group_vars, host_vars, defaults, extra vars, and facts are known.
Which privileges are required? become is close to the task and justified.
How is success proven? Syntax check, check mode, diff, play recap, and second run are present.

Example Flow for Curriculum Goal

bash
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --list-hosts
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff
ansible-playbook -i inventory/hosts.yml playbooks/site.yml
ansible-playbook -i inventory/hosts.yml playbooks/site.yml

The flow is intentionally complete. In real teams, some steps are automated but not skipped. CI can run syntax checks and linting; the domain review of scope, privileges, secret flows, and rollout risk remains a human engineering task.

Review Criteria for Curriculum Goal

  • Inventory and patterns are narrower than all unless a reason is documented.
  • Modules from ansible.builtin or reviewed collections are preferred.
  • Shell or command tasks include changed_when, failed_when, or a clear reason.
  • Variables are placed predictably and do not override each other surprisingly.
  • Secrets do not appear in plaintext, diffs, debug tasks, or CI logs.
  • The playbook can run repeatedly without unnecessary changes.
  • Cleanup, fix-forward, or controlled acceptance of the target state is documented.

Common Failure Modes for Curriculum Goal

Failure Cause Diagnosis
wrong hosts targeted pattern or inventory misunderstood --list-hosts, ansible-inventory --host
unreachable SSH, user, Python, or network issue -vvvv, SSH test, inventory variables
unexpected change module not idempotent or wrong data source second run, diff, variable inspection
secret leak debug, diff, or log not scoped check no_log, Vault, CI artifacts
handler does not run no changed result or wrong handler name inspect task result and handler name

Operations Note for Curriculum Goal

For production-like usage, the lab must become a runbook. The runbook states target systems, owners, prerequisites, stop criteria, expected duration, validation, monitoring, and cleanup. Without those details, a playbook is executable but not operationally mature.

Curriculum Goal is a practical building block of the Ansible workshop. The desired state must be described, executed against a controlled scope, and validated before and after the run. A solid Ansible workflow answers four questions: which hosts are targeted, which change is performed, which privileges are required, and how success is measured.

Aspect Workshop Meaning Check
Scope Inventory, pattern, --limit, tags, and environment select target systems. ansible-inventory --graph, ansible-playbook --list-hosts
State Modules should model desired state and produce repeatable results. second run without unnecessary changes
Privilege become is used close to the task and justified. no broad global privilege without review
Evidence Output, diffs, and summaries are documented. play recap, diff, evidence file

Typical commands:

bash
ansible --version
ansible-config dump --only-changed
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff

For reviews, a playbook is ready only when it proves its target scope, exposes its data sources, protects sensitive values, describes failure paths, and remains stable after a second run. If a module does not fully support check mode or diff mode, that limitation belongs in the runbook.

Common mistakes are broad patterns such as all, unclear variable sources, shell workarounds without idempotence, secrets in debug output, missing rollback notes, and missing separation between lab and production inventory.

01 / 23

2. Didactic Model

Deep Dive and Submission Example for Didactic Model

A complete treatment of Didactic Model contains both a technical artifact and a short domain explanation. The artifact can be an inventory, a playbook, a role, a template, a Vault file with dummy values, a CI configuration, or an evidence file. The explanation states why this path was chosen and which alternative was deliberately not used.

Submission Part Content Minimum Quality
target description what should be true after the run measurable and without hidden assumptions
scope evidence which hosts are affected output from --list-hosts or inventory graph
implementation which files were changed small reviewable YAML files
validation how it was checked syntax check, check mode, diff, real run, second run
risk decision what can go wrong privileges, secrets, external dependencies, and rollback considered

Minimal Artifacts for Didactic Model

text
submission/
  inventory/hosts.yml
  playbooks/site.yml
  evidence.md
  cleanup.md

For roles or collections, the structure expands:

text
submission/
  ansible.cfg
  collections/requirements.yml
  inventory/hosts.yml
  roles/<role>/defaults/main.yml
  roles/<role>/tasks/main.yml
  roles/<role>/handlers/main.yml
  playbooks/site.yml
  evidence.md

Grading Expectation for Didactic Model

A reviewable solution must be understandable to people who did not run it themselves. Screenshots or uncommented terminal output are not enough. Good evidence states context, command, relevant output, and assessment. If a module behaves differently in check mode, that limitation is explicitly documented.

Transfer to Real Teams

In a team context, Didactic Model is connected to code review, branch rules, CI, role ownership, release notes, and operational approval. Production-like usage also documents ownership, maintenance window, monitoring, alerting, and rollback criteria.

Practical Relevance of Didactic Model

This section is not just a definition. In the workshop, Didactic Model is always validated through a concrete flow: inspect inventory, prove target hosts, check the playbook, simulate the change, run the change, evaluate a second run, and document cleanup. This shows whether Ansible really models desired state or merely executes a command successfully once.

Review Question Expected Answer
Which hosts are affected? Pattern, group, --limit, and inventory output are documented.
Which data sources apply? group_vars, host_vars, defaults, extra vars, and facts are known.
Which privileges are required? become is close to the task and justified.
How is success proven? Syntax check, check mode, diff, play recap, and second run are present.

Example Flow for Didactic Model

bash
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --list-hosts
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff
ansible-playbook -i inventory/hosts.yml playbooks/site.yml
ansible-playbook -i inventory/hosts.yml playbooks/site.yml

The flow is intentionally complete. In real teams, some steps are automated but not skipped. CI can run syntax checks and linting; the domain review of scope, privileges, secret flows, and rollout risk remains a human engineering task.

Review Criteria for Didactic Model

  • Inventory and patterns are narrower than all unless a reason is documented.
  • Modules from ansible.builtin or reviewed collections are preferred.
  • Shell or command tasks include changed_when, failed_when, or a clear reason.
  • Variables are placed predictably and do not override each other surprisingly.
  • Secrets do not appear in plaintext, diffs, debug tasks, or CI logs.
  • The playbook can run repeatedly without unnecessary changes.
  • Cleanup, fix-forward, or controlled acceptance of the target state is documented.

Common Failure Modes for Didactic Model

Failure Cause Diagnosis
wrong hosts targeted pattern or inventory misunderstood --list-hosts, ansible-inventory --host
unreachable SSH, user, Python, or network issue -vvvv, SSH test, inventory variables
unexpected change module not idempotent or wrong data source second run, diff, variable inspection
secret leak debug, diff, or log not scoped check no_log, Vault, CI artifacts
handler does not run no changed result or wrong handler name inspect task result and handler name

Operations Note for Didactic Model

For production-like usage, the lab must become a runbook. The runbook states target systems, owners, prerequisites, stop criteria, expected duration, validation, monitoring, and cleanup. Without those details, a playbook is executable but not operationally mature.

Didactic Model is a practical building block of the Ansible workshop. The desired state must be described, executed against a controlled scope, and validated before and after the run. A solid Ansible workflow answers four questions: which hosts are targeted, which change is performed, which privileges are required, and how success is measured.

Aspect Workshop Meaning Check
Scope Inventory, pattern, --limit, tags, and environment select target systems. ansible-inventory --graph, ansible-playbook --list-hosts
State Modules should model desired state and produce repeatable results. second run without unnecessary changes
Privilege become is used close to the task and justified. no broad global privilege without review
Evidence Output, diffs, and summaries are documented. play recap, diff, evidence file

Typical commands:

bash
ansible --version
ansible-config dump --only-changed
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff

For reviews, a playbook is ready only when it proves its target scope, exposes its data sources, protects sensitive values, describes failure paths, and remains stable after a second run. If a module does not fully support check mode or diff mode, that limitation belongs in the runbook.

Common mistakes are broad patterns such as all, unclear variable sources, shell workarounds without idempotence, secrets in debug output, missing rollback notes, and missing separation between lab and production inventory.

02 / 23

3. Audiences and Roles

Deep Dive and Submission Example for Audiences and Roles

A complete treatment of Audiences and Roles contains both a technical artifact and a short domain explanation. The artifact can be an inventory, a playbook, a role, a template, a Vault file with dummy values, a CI configuration, or an evidence file. The explanation states why this path was chosen and which alternative was deliberately not used.

Submission Part Content Minimum Quality
target description what should be true after the run measurable and without hidden assumptions
scope evidence which hosts are affected output from --list-hosts or inventory graph
implementation which files were changed small reviewable YAML files
validation how it was checked syntax check, check mode, diff, real run, second run
risk decision what can go wrong privileges, secrets, external dependencies, and rollback considered

Minimal Artifacts for Audiences and Roles

text
submission/
  inventory/hosts.yml
  playbooks/site.yml
  evidence.md
  cleanup.md

For roles or collections, the structure expands:

text
submission/
  ansible.cfg
  collections/requirements.yml
  inventory/hosts.yml
  roles/<role>/defaults/main.yml
  roles/<role>/tasks/main.yml
  roles/<role>/handlers/main.yml
  playbooks/site.yml
  evidence.md

Grading Expectation for Audiences and Roles

A reviewable solution must be understandable to people who did not run it themselves. Screenshots or uncommented terminal output are not enough. Good evidence states context, command, relevant output, and assessment. If a module behaves differently in check mode, that limitation is explicitly documented.

Transfer to Real Teams

In a team context, Audiences and Roles is connected to code review, branch rules, CI, role ownership, release notes, and operational approval. Production-like usage also documents ownership, maintenance window, monitoring, alerting, and rollback criteria.

Practical Relevance of Audiences and Roles

This section is not just a definition. In the workshop, Audiences and Roles is always validated through a concrete flow: inspect inventory, prove target hosts, check the playbook, simulate the change, run the change, evaluate a second run, and document cleanup. This shows whether Ansible really models desired state or merely executes a command successfully once.

Review Question Expected Answer
Which hosts are affected? Pattern, group, --limit, and inventory output are documented.
Which data sources apply? group_vars, host_vars, defaults, extra vars, and facts are known.
Which privileges are required? become is close to the task and justified.
How is success proven? Syntax check, check mode, diff, play recap, and second run are present.

Example Flow for Audiences and Roles

bash
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --list-hosts
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff
ansible-playbook -i inventory/hosts.yml playbooks/site.yml
ansible-playbook -i inventory/hosts.yml playbooks/site.yml

The flow is intentionally complete. In real teams, some steps are automated but not skipped. CI can run syntax checks and linting; the domain review of scope, privileges, secret flows, and rollout risk remains a human engineering task.

Review Criteria for Audiences and Roles

  • Inventory and patterns are narrower than all unless a reason is documented.
  • Modules from ansible.builtin or reviewed collections are preferred.
  • Shell or command tasks include changed_when, failed_when, or a clear reason.
  • Variables are placed predictably and do not override each other surprisingly.
  • Secrets do not appear in plaintext, diffs, debug tasks, or CI logs.
  • The playbook can run repeatedly without unnecessary changes.
  • Cleanup, fix-forward, or controlled acceptance of the target state is documented.

Common Failure Modes for Audiences and Roles

Failure Cause Diagnosis
wrong hosts targeted pattern or inventory misunderstood --list-hosts, ansible-inventory --host
unreachable SSH, user, Python, or network issue -vvvv, SSH test, inventory variables
unexpected change module not idempotent or wrong data source second run, diff, variable inspection
secret leak debug, diff, or log not scoped check no_log, Vault, CI artifacts
handler does not run no changed result or wrong handler name inspect task result and handler name

Operations Note for Audiences and Roles

For production-like usage, the lab must become a runbook. The runbook states target systems, owners, prerequisites, stop criteria, expected duration, validation, monitoring, and cleanup. Without those details, a playbook is executable but not operationally mature.

Audiences and Roles is a practical building block of the Ansible workshop. The desired state must be described, executed against a controlled scope, and validated before and after the run. A solid Ansible workflow answers four questions: which hosts are targeted, which change is performed, which privileges are required, and how success is measured.

Aspect Workshop Meaning Check
Scope Inventory, pattern, --limit, tags, and environment select target systems. ansible-inventory --graph, ansible-playbook --list-hosts
State Modules should model desired state and produce repeatable results. second run without unnecessary changes
Privilege become is used close to the task and justified. no broad global privilege without review
Evidence Output, diffs, and summaries are documented. play recap, diff, evidence file

Typical commands:

bash
ansible --version
ansible-config dump --only-changed
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff

For reviews, a playbook is ready only when it proves its target scope, exposes its data sources, protects sensitive values, describes failure paths, and remains stable after a second run. If a module does not fully support check mode or diff mode, that limitation belongs in the runbook.

Common mistakes are broad patterns such as all, unclear variable sources, shell workarounds without idempotence, secrets in debug output, missing rollback notes, and missing separation between lab and production inventory.

03 / 23

4. Prerequisites

Deep Dive and Submission Example for Prerequisites

A complete treatment of Prerequisites contains both a technical artifact and a short domain explanation. The artifact can be an inventory, a playbook, a role, a template, a Vault file with dummy values, a CI configuration, or an evidence file. The explanation states why this path was chosen and which alternative was deliberately not used.

Submission Part Content Minimum Quality
target description what should be true after the run measurable and without hidden assumptions
scope evidence which hosts are affected output from --list-hosts or inventory graph
implementation which files were changed small reviewable YAML files
validation how it was checked syntax check, check mode, diff, real run, second run
risk decision what can go wrong privileges, secrets, external dependencies, and rollback considered

Minimal Artifacts for Prerequisites

text
submission/
  inventory/hosts.yml
  playbooks/site.yml
  evidence.md
  cleanup.md

For roles or collections, the structure expands:

text
submission/
  ansible.cfg
  collections/requirements.yml
  inventory/hosts.yml
  roles/<role>/defaults/main.yml
  roles/<role>/tasks/main.yml
  roles/<role>/handlers/main.yml
  playbooks/site.yml
  evidence.md

Grading Expectation for Prerequisites

A reviewable solution must be understandable to people who did not run it themselves. Screenshots or uncommented terminal output are not enough. Good evidence states context, command, relevant output, and assessment. If a module behaves differently in check mode, that limitation is explicitly documented.

Transfer to Real Teams

In a team context, Prerequisites is connected to code review, branch rules, CI, role ownership, release notes, and operational approval. Production-like usage also documents ownership, maintenance window, monitoring, alerting, and rollback criteria.

Practical Relevance of Prerequisites

This section is not just a definition. In the workshop, Prerequisites is always validated through a concrete flow: inspect inventory, prove target hosts, check the playbook, simulate the change, run the change, evaluate a second run, and document cleanup. This shows whether Ansible really models desired state or merely executes a command successfully once.

Review Question Expected Answer
Which hosts are affected? Pattern, group, --limit, and inventory output are documented.
Which data sources apply? group_vars, host_vars, defaults, extra vars, and facts are known.
Which privileges are required? become is close to the task and justified.
How is success proven? Syntax check, check mode, diff, play recap, and second run are present.

Example Flow for Prerequisites

bash
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --list-hosts
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff
ansible-playbook -i inventory/hosts.yml playbooks/site.yml
ansible-playbook -i inventory/hosts.yml playbooks/site.yml

The flow is intentionally complete. In real teams, some steps are automated but not skipped. CI can run syntax checks and linting; the domain review of scope, privileges, secret flows, and rollout risk remains a human engineering task.

Review Criteria for Prerequisites

  • Inventory and patterns are narrower than all unless a reason is documented.
  • Modules from ansible.builtin or reviewed collections are preferred.
  • Shell or command tasks include changed_when, failed_when, or a clear reason.
  • Variables are placed predictably and do not override each other surprisingly.
  • Secrets do not appear in plaintext, diffs, debug tasks, or CI logs.
  • The playbook can run repeatedly without unnecessary changes.
  • Cleanup, fix-forward, or controlled acceptance of the target state is documented.

Common Failure Modes for Prerequisites

Failure Cause Diagnosis
wrong hosts targeted pattern or inventory misunderstood --list-hosts, ansible-inventory --host
unreachable SSH, user, Python, or network issue -vvvv, SSH test, inventory variables
unexpected change module not idempotent or wrong data source second run, diff, variable inspection
secret leak debug, diff, or log not scoped check no_log, Vault, CI artifacts
handler does not run no changed result or wrong handler name inspect task result and handler name

Operations Note for Prerequisites

For production-like usage, the lab must become a runbook. The runbook states target systems, owners, prerequisites, stop criteria, expected duration, validation, monitoring, and cleanup. Without those details, a playbook is executable but not operationally mature.

Prerequisites is a practical building block of the Ansible workshop. The desired state must be described, executed against a controlled scope, and validated before and after the run. A solid Ansible workflow answers four questions: which hosts are targeted, which change is performed, which privileges are required, and how success is measured.

Aspect Workshop Meaning Check
Scope Inventory, pattern, --limit, tags, and environment select target systems. ansible-inventory --graph, ansible-playbook --list-hosts
State Modules should model desired state and produce repeatable results. second run without unnecessary changes
Privilege become is used close to the task and justified. no broad global privilege without review
Evidence Output, diffs, and summaries are documented. play recap, diff, evidence file

Typical commands:

bash
ansible --version
ansible-config dump --only-changed
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff

For reviews, a playbook is ready only when it proves its target scope, exposes its data sources, protects sensitive values, describes failure paths, and remains stable after a second run. If a module does not fully support check mode or diff mode, that limitation belongs in the runbook.

Common mistakes are broad patterns such as all, unclear variable sources, shell workarounds without idempotence, secrets in debug output, missing rollback notes, and missing separation between lab and production inventory.

04 / 23

5. Learning Paths

Deep Dive and Submission Example for Learning Paths

A complete treatment of Learning Paths contains both a technical artifact and a short domain explanation. The artifact can be an inventory, a playbook, a role, a template, a Vault file with dummy values, a CI configuration, or an evidence file. The explanation states why this path was chosen and which alternative was deliberately not used.

Submission Part Content Minimum Quality
target description what should be true after the run measurable and without hidden assumptions
scope evidence which hosts are affected output from --list-hosts or inventory graph
implementation which files were changed small reviewable YAML files
validation how it was checked syntax check, check mode, diff, real run, second run
risk decision what can go wrong privileges, secrets, external dependencies, and rollback considered

Minimal Artifacts for Learning Paths

text
submission/
  inventory/hosts.yml
  playbooks/site.yml
  evidence.md
  cleanup.md

For roles or collections, the structure expands:

text
submission/
  ansible.cfg
  collections/requirements.yml
  inventory/hosts.yml
  roles/<role>/defaults/main.yml
  roles/<role>/tasks/main.yml
  roles/<role>/handlers/main.yml
  playbooks/site.yml
  evidence.md

Grading Expectation for Learning Paths

A reviewable solution must be understandable to people who did not run it themselves. Screenshots or uncommented terminal output are not enough. Good evidence states context, command, relevant output, and assessment. If a module behaves differently in check mode, that limitation is explicitly documented.

Transfer to Real Teams

In a team context, Learning Paths is connected to code review, branch rules, CI, role ownership, release notes, and operational approval. Production-like usage also documents ownership, maintenance window, monitoring, alerting, and rollback criteria.

Practical Relevance of Learning Paths

This section is not just a definition. In the workshop, Learning Paths is always validated through a concrete flow: inspect inventory, prove target hosts, check the playbook, simulate the change, run the change, evaluate a second run, and document cleanup. This shows whether Ansible really models desired state or merely executes a command successfully once.

Review Question Expected Answer
Which hosts are affected? Pattern, group, --limit, and inventory output are documented.
Which data sources apply? group_vars, host_vars, defaults, extra vars, and facts are known.
Which privileges are required? become is close to the task and justified.
How is success proven? Syntax check, check mode, diff, play recap, and second run are present.

Example Flow for Learning Paths

bash
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --list-hosts
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff
ansible-playbook -i inventory/hosts.yml playbooks/site.yml
ansible-playbook -i inventory/hosts.yml playbooks/site.yml

The flow is intentionally complete. In real teams, some steps are automated but not skipped. CI can run syntax checks and linting; the domain review of scope, privileges, secret flows, and rollout risk remains a human engineering task.

Review Criteria for Learning Paths

  • Inventory and patterns are narrower than all unless a reason is documented.
  • Modules from ansible.builtin or reviewed collections are preferred.
  • Shell or command tasks include changed_when, failed_when, or a clear reason.
  • Variables are placed predictably and do not override each other surprisingly.
  • Secrets do not appear in plaintext, diffs, debug tasks, or CI logs.
  • The playbook can run repeatedly without unnecessary changes.
  • Cleanup, fix-forward, or controlled acceptance of the target state is documented.

Common Failure Modes for Learning Paths

Failure Cause Diagnosis
wrong hosts targeted pattern or inventory misunderstood --list-hosts, ansible-inventory --host
unreachable SSH, user, Python, or network issue -vvvv, SSH test, inventory variables
unexpected change module not idempotent or wrong data source second run, diff, variable inspection
secret leak debug, diff, or log not scoped check no_log, Vault, CI artifacts
handler does not run no changed result or wrong handler name inspect task result and handler name

Operations Note for Learning Paths

For production-like usage, the lab must become a runbook. The runbook states target systems, owners, prerequisites, stop criteria, expected duration, validation, monitoring, and cleanup. Without those details, a playbook is executable but not operationally mature.

Learning Paths is a practical building block of the Ansible workshop. The desired state must be described, executed against a controlled scope, and validated before and after the run. A solid Ansible workflow answers four questions: which hosts are targeted, which change is performed, which privileges are required, and how success is measured.

Aspect Workshop Meaning Check
Scope Inventory, pattern, --limit, tags, and environment select target systems. ansible-inventory --graph, ansible-playbook --list-hosts
State Modules should model desired state and produce repeatable results. second run without unnecessary changes
Privilege become is used close to the task and justified. no broad global privilege without review
Evidence Output, diffs, and summaries are documented. play recap, diff, evidence file

Typical commands:

bash
ansible --version
ansible-config dump --only-changed
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff

For reviews, a playbook is ready only when it proves its target scope, exposes its data sources, protects sensitive values, describes failure paths, and remains stable after a second run. If a module does not fully support check mode or diff mode, that limitation belongs in the runbook.

Common mistakes are broad patterns such as all, unclear variable sources, shell workarounds without idempotence, secrets in debug output, missing rollback notes, and missing separation between lab and production inventory.

05 / 23

6. Competency Levels

Deep Dive and Submission Example for Competency Levels

A complete treatment of Competency Levels contains both a technical artifact and a short domain explanation. The artifact can be an inventory, a playbook, a role, a template, a Vault file with dummy values, a CI configuration, or an evidence file. The explanation states why this path was chosen and which alternative was deliberately not used.

Submission Part Content Minimum Quality
target description what should be true after the run measurable and without hidden assumptions
scope evidence which hosts are affected output from --list-hosts or inventory graph
implementation which files were changed small reviewable YAML files
validation how it was checked syntax check, check mode, diff, real run, second run
risk decision what can go wrong privileges, secrets, external dependencies, and rollback considered

Minimal Artifacts for Competency Levels

text
submission/
  inventory/hosts.yml
  playbooks/site.yml
  evidence.md
  cleanup.md

For roles or collections, the structure expands:

text
submission/
  ansible.cfg
  collections/requirements.yml
  inventory/hosts.yml
  roles/<role>/defaults/main.yml
  roles/<role>/tasks/main.yml
  roles/<role>/handlers/main.yml
  playbooks/site.yml
  evidence.md

Grading Expectation for Competency Levels

A reviewable solution must be understandable to people who did not run it themselves. Screenshots or uncommented terminal output are not enough. Good evidence states context, command, relevant output, and assessment. If a module behaves differently in check mode, that limitation is explicitly documented.

Transfer to Real Teams

In a team context, Competency Levels is connected to code review, branch rules, CI, role ownership, release notes, and operational approval. Production-like usage also documents ownership, maintenance window, monitoring, alerting, and rollback criteria.

Practical Relevance of Competency Levels

This section is not just a definition. In the workshop, Competency Levels is always validated through a concrete flow: inspect inventory, prove target hosts, check the playbook, simulate the change, run the change, evaluate a second run, and document cleanup. This shows whether Ansible really models desired state or merely executes a command successfully once.

Review Question Expected Answer
Which hosts are affected? Pattern, group, --limit, and inventory output are documented.
Which data sources apply? group_vars, host_vars, defaults, extra vars, and facts are known.
Which privileges are required? become is close to the task and justified.
How is success proven? Syntax check, check mode, diff, play recap, and second run are present.

Example Flow for Competency Levels

bash
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --list-hosts
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff
ansible-playbook -i inventory/hosts.yml playbooks/site.yml
ansible-playbook -i inventory/hosts.yml playbooks/site.yml

The flow is intentionally complete. In real teams, some steps are automated but not skipped. CI can run syntax checks and linting; the domain review of scope, privileges, secret flows, and rollout risk remains a human engineering task.

Review Criteria for Competency Levels

  • Inventory and patterns are narrower than all unless a reason is documented.
  • Modules from ansible.builtin or reviewed collections are preferred.
  • Shell or command tasks include changed_when, failed_when, or a clear reason.
  • Variables are placed predictably and do not override each other surprisingly.
  • Secrets do not appear in plaintext, diffs, debug tasks, or CI logs.
  • The playbook can run repeatedly without unnecessary changes.
  • Cleanup, fix-forward, or controlled acceptance of the target state is documented.

Common Failure Modes for Competency Levels

Failure Cause Diagnosis
wrong hosts targeted pattern or inventory misunderstood --list-hosts, ansible-inventory --host
unreachable SSH, user, Python, or network issue -vvvv, SSH test, inventory variables
unexpected change module not idempotent or wrong data source second run, diff, variable inspection
secret leak debug, diff, or log not scoped check no_log, Vault, CI artifacts
handler does not run no changed result or wrong handler name inspect task result and handler name

Operations Note for Competency Levels

For production-like usage, the lab must become a runbook. The runbook states target systems, owners, prerequisites, stop criteria, expected duration, validation, monitoring, and cleanup. Without those details, a playbook is executable but not operationally mature.

Competency Levels is a practical building block of the Ansible workshop. The desired state must be described, executed against a controlled scope, and validated before and after the run. A solid Ansible workflow answers four questions: which hosts are targeted, which change is performed, which privileges are required, and how success is measured.

Aspect Workshop Meaning Check
Scope Inventory, pattern, --limit, tags, and environment select target systems. ansible-inventory --graph, ansible-playbook --list-hosts
State Modules should model desired state and produce repeatable results. second run without unnecessary changes
Privilege become is used close to the task and justified. no broad global privilege without review
Evidence Output, diffs, and summaries are documented. play recap, diff, evidence file

Typical commands:

bash
ansible --version
ansible-config dump --only-changed
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff

For reviews, a playbook is ready only when it proves its target scope, exposes its data sources, protects sensitive values, describes failure paths, and remains stable after a second run. If a module does not fully support check mode or diff mode, that limitation belongs in the runbook.

Common mistakes are broad patterns such as all, unclear variable sources, shell workarounds without idempotence, secrets in debug output, missing rollback notes, and missing separation between lab and production inventory.

06 / 23

7. Overall Structure

Deep Dive and Submission Example for Overall Structure

A complete treatment of Overall Structure contains both a technical artifact and a short domain explanation. The artifact can be an inventory, a playbook, a role, a template, a Vault file with dummy values, a CI configuration, or an evidence file. The explanation states why this path was chosen and which alternative was deliberately not used.

Submission Part Content Minimum Quality
target description what should be true after the run measurable and without hidden assumptions
scope evidence which hosts are affected output from --list-hosts or inventory graph
implementation which files were changed small reviewable YAML files
validation how it was checked syntax check, check mode, diff, real run, second run
risk decision what can go wrong privileges, secrets, external dependencies, and rollback considered

Minimal Artifacts for Overall Structure

text
submission/
  inventory/hosts.yml
  playbooks/site.yml
  evidence.md
  cleanup.md

For roles or collections, the structure expands:

text
submission/
  ansible.cfg
  collections/requirements.yml
  inventory/hosts.yml
  roles/<role>/defaults/main.yml
  roles/<role>/tasks/main.yml
  roles/<role>/handlers/main.yml
  playbooks/site.yml
  evidence.md

Grading Expectation for Overall Structure

A reviewable solution must be understandable to people who did not run it themselves. Screenshots or uncommented terminal output are not enough. Good evidence states context, command, relevant output, and assessment. If a module behaves differently in check mode, that limitation is explicitly documented.

Transfer to Real Teams

In a team context, Overall Structure is connected to code review, branch rules, CI, role ownership, release notes, and operational approval. Production-like usage also documents ownership, maintenance window, monitoring, alerting, and rollback criteria.

Practical Relevance of Overall Structure

This section is not just a definition. In the workshop, Overall Structure is always validated through a concrete flow: inspect inventory, prove target hosts, check the playbook, simulate the change, run the change, evaluate a second run, and document cleanup. This shows whether Ansible really models desired state or merely executes a command successfully once.

Review Question Expected Answer
Which hosts are affected? Pattern, group, --limit, and inventory output are documented.
Which data sources apply? group_vars, host_vars, defaults, extra vars, and facts are known.
Which privileges are required? become is close to the task and justified.
How is success proven? Syntax check, check mode, diff, play recap, and second run are present.

Example Flow for Overall Structure

bash
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --list-hosts
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff
ansible-playbook -i inventory/hosts.yml playbooks/site.yml
ansible-playbook -i inventory/hosts.yml playbooks/site.yml

The flow is intentionally complete. In real teams, some steps are automated but not skipped. CI can run syntax checks and linting; the domain review of scope, privileges, secret flows, and rollout risk remains a human engineering task.

Review Criteria for Overall Structure

  • Inventory and patterns are narrower than all unless a reason is documented.
  • Modules from ansible.builtin or reviewed collections are preferred.
  • Shell or command tasks include changed_when, failed_when, or a clear reason.
  • Variables are placed predictably and do not override each other surprisingly.
  • Secrets do not appear in plaintext, diffs, debug tasks, or CI logs.
  • The playbook can run repeatedly without unnecessary changes.
  • Cleanup, fix-forward, or controlled acceptance of the target state is documented.

Common Failure Modes for Overall Structure

Failure Cause Diagnosis
wrong hosts targeted pattern or inventory misunderstood --list-hosts, ansible-inventory --host
unreachable SSH, user, Python, or network issue -vvvv, SSH test, inventory variables
unexpected change module not idempotent or wrong data source second run, diff, variable inspection
secret leak debug, diff, or log not scoped check no_log, Vault, CI artifacts
handler does not run no changed result or wrong handler name inspect task result and handler name

Operations Note for Overall Structure

For production-like usage, the lab must become a runbook. The runbook states target systems, owners, prerequisites, stop criteria, expected duration, validation, monitoring, and cleanup. Without those details, a playbook is executable but not operationally mature.

Overall Structure is a practical building block of the Ansible workshop. The desired state must be described, executed against a controlled scope, and validated before and after the run. A solid Ansible workflow answers four questions: which hosts are targeted, which change is performed, which privileges are required, and how success is measured.

Aspect Workshop Meaning Check
Scope Inventory, pattern, --limit, tags, and environment select target systems. ansible-inventory --graph, ansible-playbook --list-hosts
State Modules should model desired state and produce repeatable results. second run without unnecessary changes
Privilege become is used close to the task and justified. no broad global privilege without review
Evidence Output, diffs, and summaries are documented. play recap, diff, evidence file

Typical commands:

bash
ansible --version
ansible-config dump --only-changed
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff

For reviews, a playbook is ready only when it proves its target scope, exposes its data sources, protects sensitive values, describes failure paths, and remains stable after a second run. If a module does not fully support check mode or diff mode, that limitation belongs in the runbook.

Common mistakes are broad patterns such as all, unclear variable sources, shell workarounds without idempotence, secrets in debug output, missing rollback notes, and missing separation between lab and production inventory.

07 / 23

8. Level 1 Fundamentals

Deep Dive and Submission Example for Level 1 Fundamentals

A complete treatment of Level 1 Fundamentals contains both a technical artifact and a short domain explanation. The artifact can be an inventory, a playbook, a role, a template, a Vault file with dummy values, a CI configuration, or an evidence file. The explanation states why this path was chosen and which alternative was deliberately not used.

Submission Part Content Minimum Quality
target description what should be true after the run measurable and without hidden assumptions
scope evidence which hosts are affected output from --list-hosts or inventory graph
implementation which files were changed small reviewable YAML files
validation how it was checked syntax check, check mode, diff, real run, second run
risk decision what can go wrong privileges, secrets, external dependencies, and rollback considered

Minimal Artifacts for Level 1 Fundamentals

text
submission/
  inventory/hosts.yml
  playbooks/site.yml
  evidence.md
  cleanup.md

For roles or collections, the structure expands:

text
submission/
  ansible.cfg
  collections/requirements.yml
  inventory/hosts.yml
  roles/<role>/defaults/main.yml
  roles/<role>/tasks/main.yml
  roles/<role>/handlers/main.yml
  playbooks/site.yml
  evidence.md

Grading Expectation for Level 1 Fundamentals

A reviewable solution must be understandable to people who did not run it themselves. Screenshots or uncommented terminal output are not enough. Good evidence states context, command, relevant output, and assessment. If a module behaves differently in check mode, that limitation is explicitly documented.

Transfer to Real Teams

In a team context, Level 1 Fundamentals is connected to code review, branch rules, CI, role ownership, release notes, and operational approval. Production-like usage also documents ownership, maintenance window, monitoring, alerting, and rollback criteria.

Practical Relevance of Level 1 Fundamentals

This section is not just a definition. In the workshop, Level 1 Fundamentals is always validated through a concrete flow: inspect inventory, prove target hosts, check the playbook, simulate the change, run the change, evaluate a second run, and document cleanup. This shows whether Ansible really models desired state or merely executes a command successfully once.

Review Question Expected Answer
Which hosts are affected? Pattern, group, --limit, and inventory output are documented.
Which data sources apply? group_vars, host_vars, defaults, extra vars, and facts are known.
Which privileges are required? become is close to the task and justified.
How is success proven? Syntax check, check mode, diff, play recap, and second run are present.

Example Flow for Level 1 Fundamentals

bash
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --list-hosts
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff
ansible-playbook -i inventory/hosts.yml playbooks/site.yml
ansible-playbook -i inventory/hosts.yml playbooks/site.yml

The flow is intentionally complete. In real teams, some steps are automated but not skipped. CI can run syntax checks and linting; the domain review of scope, privileges, secret flows, and rollout risk remains a human engineering task.

Review Criteria for Level 1 Fundamentals

  • Inventory and patterns are narrower than all unless a reason is documented.
  • Modules from ansible.builtin or reviewed collections are preferred.
  • Shell or command tasks include changed_when, failed_when, or a clear reason.
  • Variables are placed predictably and do not override each other surprisingly.
  • Secrets do not appear in plaintext, diffs, debug tasks, or CI logs.
  • The playbook can run repeatedly without unnecessary changes.
  • Cleanup, fix-forward, or controlled acceptance of the target state is documented.

Common Failure Modes for Level 1 Fundamentals

Failure Cause Diagnosis
wrong hosts targeted pattern or inventory misunderstood --list-hosts, ansible-inventory --host
unreachable SSH, user, Python, or network issue -vvvv, SSH test, inventory variables
unexpected change module not idempotent or wrong data source second run, diff, variable inspection
secret leak debug, diff, or log not scoped check no_log, Vault, CI artifacts
handler does not run no changed result or wrong handler name inspect task result and handler name

Operations Note for Level 1 Fundamentals

For production-like usage, the lab must become a runbook. The runbook states target systems, owners, prerequisites, stop criteria, expected duration, validation, monitoring, and cleanup. Without those details, a playbook is executable but not operationally mature.

Level 1 Fundamentals is a practical building block of the Ansible workshop. The desired state must be described, executed against a controlled scope, and validated before and after the run. A solid Ansible workflow answers four questions: which hosts are targeted, which change is performed, which privileges are required, and how success is measured.

Aspect Workshop Meaning Check
Scope Inventory, pattern, --limit, tags, and environment select target systems. ansible-inventory --graph, ansible-playbook --list-hosts
State Modules should model desired state and produce repeatable results. second run without unnecessary changes
Privilege become is used close to the task and justified. no broad global privilege without review
Evidence Output, diffs, and summaries are documented. play recap, diff, evidence file

Typical commands:

bash
ansible --version
ansible-config dump --only-changed
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff

For reviews, a playbook is ready only when it proves its target scope, exposes its data sources, protects sensitive values, describes failure paths, and remains stable after a second run. If a module does not fully support check mode or diff mode, that limitation belongs in the runbook.

Common mistakes are broad patterns such as all, unclear variable sources, shell workarounds without idempotence, secrets in debug output, missing rollback notes, and missing separation between lab and production inventory.

08 / 23

9. Level 2 Intermediate

Deep Dive and Submission Example for Level 2 Intermediate

A complete treatment of Level 2 Intermediate contains both a technical artifact and a short domain explanation. The artifact can be an inventory, a playbook, a role, a template, a Vault file with dummy values, a CI configuration, or an evidence file. The explanation states why this path was chosen and which alternative was deliberately not used.

Submission Part Content Minimum Quality
target description what should be true after the run measurable and without hidden assumptions
scope evidence which hosts are affected output from --list-hosts or inventory graph
implementation which files were changed small reviewable YAML files
validation how it was checked syntax check, check mode, diff, real run, second run
risk decision what can go wrong privileges, secrets, external dependencies, and rollback considered

Minimal Artifacts for Level 2 Intermediate

text
submission/
  inventory/hosts.yml
  playbooks/site.yml
  evidence.md
  cleanup.md

For roles or collections, the structure expands:

text
submission/
  ansible.cfg
  collections/requirements.yml
  inventory/hosts.yml
  roles/<role>/defaults/main.yml
  roles/<role>/tasks/main.yml
  roles/<role>/handlers/main.yml
  playbooks/site.yml
  evidence.md

Grading Expectation for Level 2 Intermediate

A reviewable solution must be understandable to people who did not run it themselves. Screenshots or uncommented terminal output are not enough. Good evidence states context, command, relevant output, and assessment. If a module behaves differently in check mode, that limitation is explicitly documented.

Transfer to Real Teams

In a team context, Level 2 Intermediate is connected to code review, branch rules, CI, role ownership, release notes, and operational approval. Production-like usage also documents ownership, maintenance window, monitoring, alerting, and rollback criteria.

Practical Relevance of Level 2 Intermediate

This section is not just a definition. In the workshop, Level 2 Intermediate is always validated through a concrete flow: inspect inventory, prove target hosts, check the playbook, simulate the change, run the change, evaluate a second run, and document cleanup. This shows whether Ansible really models desired state or merely executes a command successfully once.

Review Question Expected Answer
Which hosts are affected? Pattern, group, --limit, and inventory output are documented.
Which data sources apply? group_vars, host_vars, defaults, extra vars, and facts are known.
Which privileges are required? become is close to the task and justified.
How is success proven? Syntax check, check mode, diff, play recap, and second run are present.

Example Flow for Level 2 Intermediate

bash
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --list-hosts
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff
ansible-playbook -i inventory/hosts.yml playbooks/site.yml
ansible-playbook -i inventory/hosts.yml playbooks/site.yml

The flow is intentionally complete. In real teams, some steps are automated but not skipped. CI can run syntax checks and linting; the domain review of scope, privileges, secret flows, and rollout risk remains a human engineering task.

Review Criteria for Level 2 Intermediate

  • Inventory and patterns are narrower than all unless a reason is documented.
  • Modules from ansible.builtin or reviewed collections are preferred.
  • Shell or command tasks include changed_when, failed_when, or a clear reason.
  • Variables are placed predictably and do not override each other surprisingly.
  • Secrets do not appear in plaintext, diffs, debug tasks, or CI logs.
  • The playbook can run repeatedly without unnecessary changes.
  • Cleanup, fix-forward, or controlled acceptance of the target state is documented.

Common Failure Modes for Level 2 Intermediate

Failure Cause Diagnosis
wrong hosts targeted pattern or inventory misunderstood --list-hosts, ansible-inventory --host
unreachable SSH, user, Python, or network issue -vvvv, SSH test, inventory variables
unexpected change module not idempotent or wrong data source second run, diff, variable inspection
secret leak debug, diff, or log not scoped check no_log, Vault, CI artifacts
handler does not run no changed result or wrong handler name inspect task result and handler name

Operations Note for Level 2 Intermediate

For production-like usage, the lab must become a runbook. The runbook states target systems, owners, prerequisites, stop criteria, expected duration, validation, monitoring, and cleanup. Without those details, a playbook is executable but not operationally mature.

Level 2 Intermediate is a practical building block of the Ansible workshop. The desired state must be described, executed against a controlled scope, and validated before and after the run. A solid Ansible workflow answers four questions: which hosts are targeted, which change is performed, which privileges are required, and how success is measured.

Aspect Workshop Meaning Check
Scope Inventory, pattern, --limit, tags, and environment select target systems. ansible-inventory --graph, ansible-playbook --list-hosts
State Modules should model desired state and produce repeatable results. second run without unnecessary changes
Privilege become is used close to the task and justified. no broad global privilege without review
Evidence Output, diffs, and summaries are documented. play recap, diff, evidence file

Typical commands:

bash
ansible --version
ansible-config dump --only-changed
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff

For reviews, a playbook is ready only when it proves its target scope, exposes its data sources, protects sensitive values, describes failure paths, and remains stable after a second run. If a module does not fully support check mode or diff mode, that limitation belongs in the runbook.

Common mistakes are broad patterns such as all, unclear variable sources, shell workarounds without idempotence, secrets in debug output, missing rollback notes, and missing separation between lab and production inventory.

09 / 23

10. Level 3 Professional

Deep Dive and Submission Example for Level 3 Professional

A complete treatment of Level 3 Professional contains both a technical artifact and a short domain explanation. The artifact can be an inventory, a playbook, a role, a template, a Vault file with dummy values, a CI configuration, or an evidence file. The explanation states why this path was chosen and which alternative was deliberately not used.

Submission Part Content Minimum Quality
target description what should be true after the run measurable and without hidden assumptions
scope evidence which hosts are affected output from --list-hosts or inventory graph
implementation which files were changed small reviewable YAML files
validation how it was checked syntax check, check mode, diff, real run, second run
risk decision what can go wrong privileges, secrets, external dependencies, and rollback considered

Minimal Artifacts for Level 3 Professional

text
submission/
  inventory/hosts.yml
  playbooks/site.yml
  evidence.md
  cleanup.md

For roles or collections, the structure expands:

text
submission/
  ansible.cfg
  collections/requirements.yml
  inventory/hosts.yml
  roles/<role>/defaults/main.yml
  roles/<role>/tasks/main.yml
  roles/<role>/handlers/main.yml
  playbooks/site.yml
  evidence.md

Grading Expectation for Level 3 Professional

A reviewable solution must be understandable to people who did not run it themselves. Screenshots or uncommented terminal output are not enough. Good evidence states context, command, relevant output, and assessment. If a module behaves differently in check mode, that limitation is explicitly documented.

Transfer to Real Teams

In a team context, Level 3 Professional is connected to code review, branch rules, CI, role ownership, release notes, and operational approval. Production-like usage also documents ownership, maintenance window, monitoring, alerting, and rollback criteria.

Practical Relevance of Level 3 Professional

This section is not just a definition. In the workshop, Level 3 Professional is always validated through a concrete flow: inspect inventory, prove target hosts, check the playbook, simulate the change, run the change, evaluate a second run, and document cleanup. This shows whether Ansible really models desired state or merely executes a command successfully once.

Review Question Expected Answer
Which hosts are affected? Pattern, group, --limit, and inventory output are documented.
Which data sources apply? group_vars, host_vars, defaults, extra vars, and facts are known.
Which privileges are required? become is close to the task and justified.
How is success proven? Syntax check, check mode, diff, play recap, and second run are present.

Example Flow for Level 3 Professional

bash
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --list-hosts
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff
ansible-playbook -i inventory/hosts.yml playbooks/site.yml
ansible-playbook -i inventory/hosts.yml playbooks/site.yml

The flow is intentionally complete. In real teams, some steps are automated but not skipped. CI can run syntax checks and linting; the domain review of scope, privileges, secret flows, and rollout risk remains a human engineering task.

Review Criteria for Level 3 Professional

  • Inventory and patterns are narrower than all unless a reason is documented.
  • Modules from ansible.builtin or reviewed collections are preferred.
  • Shell or command tasks include changed_when, failed_when, or a clear reason.
  • Variables are placed predictably and do not override each other surprisingly.
  • Secrets do not appear in plaintext, diffs, debug tasks, or CI logs.
  • The playbook can run repeatedly without unnecessary changes.
  • Cleanup, fix-forward, or controlled acceptance of the target state is documented.

Common Failure Modes for Level 3 Professional

Failure Cause Diagnosis
wrong hosts targeted pattern or inventory misunderstood --list-hosts, ansible-inventory --host
unreachable SSH, user, Python, or network issue -vvvv, SSH test, inventory variables
unexpected change module not idempotent or wrong data source second run, diff, variable inspection
secret leak debug, diff, or log not scoped check no_log, Vault, CI artifacts
handler does not run no changed result or wrong handler name inspect task result and handler name

Operations Note for Level 3 Professional

For production-like usage, the lab must become a runbook. The runbook states target systems, owners, prerequisites, stop criteria, expected duration, validation, monitoring, and cleanup. Without those details, a playbook is executable but not operationally mature.

Level 3 Professional is a practical building block of the Ansible workshop. The desired state must be described, executed against a controlled scope, and validated before and after the run. A solid Ansible workflow answers four questions: which hosts are targeted, which change is performed, which privileges are required, and how success is measured.

Aspect Workshop Meaning Check
Scope Inventory, pattern, --limit, tags, and environment select target systems. ansible-inventory --graph, ansible-playbook --list-hosts
State Modules should model desired state and produce repeatable results. second run without unnecessary changes
Privilege become is used close to the task and justified. no broad global privilege without review
Evidence Output, diffs, and summaries are documented. play recap, diff, evidence file

Typical commands:

bash
ansible --version
ansible-config dump --only-changed
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff

For reviews, a playbook is ready only when it proves its target scope, exposes its data sources, protects sensitive values, describes failure paths, and remains stable after a second run. If a module does not fully support check mode or diff mode, that limitation belongs in the runbook.

Common mistakes are broad patterns such as all, unclear variable sources, shell workarounds without idempotence, secrets in debug output, missing rollback notes, and missing separation between lab and production inventory.

10 / 23

11. Level 4 Advanced and Security

Deep Dive and Submission Example for Level 4 Advanced and Security

A complete treatment of Level 4 Advanced and Security contains both a technical artifact and a short domain explanation. The artifact can be an inventory, a playbook, a role, a template, a Vault file with dummy values, a CI configuration, or an evidence file. The explanation states why this path was chosen and which alternative was deliberately not used.

Submission Part Content Minimum Quality
target description what should be true after the run measurable and without hidden assumptions
scope evidence which hosts are affected output from --list-hosts or inventory graph
implementation which files were changed small reviewable YAML files
validation how it was checked syntax check, check mode, diff, real run, second run
risk decision what can go wrong privileges, secrets, external dependencies, and rollback considered

Minimal Artifacts for Level 4 Advanced and Security

text
submission/
  inventory/hosts.yml
  playbooks/site.yml
  evidence.md
  cleanup.md

For roles or collections, the structure expands:

text
submission/
  ansible.cfg
  collections/requirements.yml
  inventory/hosts.yml
  roles/<role>/defaults/main.yml
  roles/<role>/tasks/main.yml
  roles/<role>/handlers/main.yml
  playbooks/site.yml
  evidence.md

Grading Expectation for Level 4 Advanced and Security

A reviewable solution must be understandable to people who did not run it themselves. Screenshots or uncommented terminal output are not enough. Good evidence states context, command, relevant output, and assessment. If a module behaves differently in check mode, that limitation is explicitly documented.

Transfer to Real Teams

In a team context, Level 4 Advanced and Security is connected to code review, branch rules, CI, role ownership, release notes, and operational approval. Production-like usage also documents ownership, maintenance window, monitoring, alerting, and rollback criteria.

Practical Relevance of Level 4 Advanced and Security

This section is not just a definition. In the workshop, Level 4 Advanced and Security is always validated through a concrete flow: inspect inventory, prove target hosts, check the playbook, simulate the change, run the change, evaluate a second run, and document cleanup. This shows whether Ansible really models desired state or merely executes a command successfully once.

Review Question Expected Answer
Which hosts are affected? Pattern, group, --limit, and inventory output are documented.
Which data sources apply? group_vars, host_vars, defaults, extra vars, and facts are known.
Which privileges are required? become is close to the task and justified.
How is success proven? Syntax check, check mode, diff, play recap, and second run are present.

Example Flow for Level 4 Advanced and Security

bash
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --list-hosts
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff
ansible-playbook -i inventory/hosts.yml playbooks/site.yml
ansible-playbook -i inventory/hosts.yml playbooks/site.yml

The flow is intentionally complete. In real teams, some steps are automated but not skipped. CI can run syntax checks and linting; the domain review of scope, privileges, secret flows, and rollout risk remains a human engineering task.

Review Criteria for Level 4 Advanced and Security

  • Inventory and patterns are narrower than all unless a reason is documented.
  • Modules from ansible.builtin or reviewed collections are preferred.
  • Shell or command tasks include changed_when, failed_when, or a clear reason.
  • Variables are placed predictably and do not override each other surprisingly.
  • Secrets do not appear in plaintext, diffs, debug tasks, or CI logs.
  • The playbook can run repeatedly without unnecessary changes.
  • Cleanup, fix-forward, or controlled acceptance of the target state is documented.

Common Failure Modes for Level 4 Advanced and Security

Failure Cause Diagnosis
wrong hosts targeted pattern or inventory misunderstood --list-hosts, ansible-inventory --host
unreachable SSH, user, Python, or network issue -vvvv, SSH test, inventory variables
unexpected change module not idempotent or wrong data source second run, diff, variable inspection
secret leak debug, diff, or log not scoped check no_log, Vault, CI artifacts
handler does not run no changed result or wrong handler name inspect task result and handler name

Operations Note for Level 4 Advanced and Security

For production-like usage, the lab must become a runbook. The runbook states target systems, owners, prerequisites, stop criteria, expected duration, validation, monitoring, and cleanup. Without those details, a playbook is executable but not operationally mature.

Level 4 Advanced and Security is a practical building block of the Ansible workshop. The desired state must be described, executed against a controlled scope, and validated before and after the run. A solid Ansible workflow answers four questions: which hosts are targeted, which change is performed, which privileges are required, and how success is measured.

Aspect Workshop Meaning Check
Scope Inventory, pattern, --limit, tags, and environment select target systems. ansible-inventory --graph, ansible-playbook --list-hosts
State Modules should model desired state and produce repeatable results. second run without unnecessary changes
Privilege become is used close to the task and justified. no broad global privilege without review
Evidence Output, diffs, and summaries are documented. play recap, diff, evidence file

Typical commands:

bash
ansible --version
ansible-config dump --only-changed
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff

For reviews, a playbook is ready only when it proves its target scope, exposes its data sources, protects sensitive values, describes failure paths, and remains stable after a second run. If a module does not fully support check mode or diff mode, that limitation belongs in the runbook.

Common mistakes are broad patterns such as all, unclear variable sources, shell workarounds without idempotence, secrets in debug output, missing rollback notes, and missing separation between lab and production inventory.

11 / 23

12. Practice Environment

Deep Dive and Submission Example for Practice Environment

A complete treatment of Practice Environment contains both a technical artifact and a short domain explanation. The artifact can be an inventory, a playbook, a role, a template, a Vault file with dummy values, a CI configuration, or an evidence file. The explanation states why this path was chosen and which alternative was deliberately not used.

Submission Part Content Minimum Quality
target description what should be true after the run measurable and without hidden assumptions
scope evidence which hosts are affected output from --list-hosts or inventory graph
implementation which files were changed small reviewable YAML files
validation how it was checked syntax check, check mode, diff, real run, second run
risk decision what can go wrong privileges, secrets, external dependencies, and rollback considered

Minimal Artifacts for Practice Environment

text
submission/
  inventory/hosts.yml
  playbooks/site.yml
  evidence.md
  cleanup.md

For roles or collections, the structure expands:

text
submission/
  ansible.cfg
  collections/requirements.yml
  inventory/hosts.yml
  roles/<role>/defaults/main.yml
  roles/<role>/tasks/main.yml
  roles/<role>/handlers/main.yml
  playbooks/site.yml
  evidence.md

Grading Expectation for Practice Environment

A reviewable solution must be understandable to people who did not run it themselves. Screenshots or uncommented terminal output are not enough. Good evidence states context, command, relevant output, and assessment. If a module behaves differently in check mode, that limitation is explicitly documented.

Transfer to Real Teams

In a team context, Practice Environment is connected to code review, branch rules, CI, role ownership, release notes, and operational approval. Production-like usage also documents ownership, maintenance window, monitoring, alerting, and rollback criteria.

Practical Relevance of Practice Environment

This section is not just a definition. In the workshop, Practice Environment is always validated through a concrete flow: inspect inventory, prove target hosts, check the playbook, simulate the change, run the change, evaluate a second run, and document cleanup. This shows whether Ansible really models desired state or merely executes a command successfully once.

Review Question Expected Answer
Which hosts are affected? Pattern, group, --limit, and inventory output are documented.
Which data sources apply? group_vars, host_vars, defaults, extra vars, and facts are known.
Which privileges are required? become is close to the task and justified.
How is success proven? Syntax check, check mode, diff, play recap, and second run are present.

Example Flow for Practice Environment

bash
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --list-hosts
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff
ansible-playbook -i inventory/hosts.yml playbooks/site.yml
ansible-playbook -i inventory/hosts.yml playbooks/site.yml

The flow is intentionally complete. In real teams, some steps are automated but not skipped. CI can run syntax checks and linting; the domain review of scope, privileges, secret flows, and rollout risk remains a human engineering task.

Review Criteria for Practice Environment

  • Inventory and patterns are narrower than all unless a reason is documented.
  • Modules from ansible.builtin or reviewed collections are preferred.
  • Shell or command tasks include changed_when, failed_when, or a clear reason.
  • Variables are placed predictably and do not override each other surprisingly.
  • Secrets do not appear in plaintext, diffs, debug tasks, or CI logs.
  • The playbook can run repeatedly without unnecessary changes.
  • Cleanup, fix-forward, or controlled acceptance of the target state is documented.

Common Failure Modes for Practice Environment

Failure Cause Diagnosis
wrong hosts targeted pattern or inventory misunderstood --list-hosts, ansible-inventory --host
unreachable SSH, user, Python, or network issue -vvvv, SSH test, inventory variables
unexpected change module not idempotent or wrong data source second run, diff, variable inspection
secret leak debug, diff, or log not scoped check no_log, Vault, CI artifacts
handler does not run no changed result or wrong handler name inspect task result and handler name

Operations Note for Practice Environment

For production-like usage, the lab must become a runbook. The runbook states target systems, owners, prerequisites, stop criteria, expected duration, validation, monitoring, and cleanup. Without those details, a playbook is executable but not operationally mature.

Practice Environment is a practical building block of the Ansible workshop. The desired state must be described, executed against a controlled scope, and validated before and after the run. A solid Ansible workflow answers four questions: which hosts are targeted, which change is performed, which privileges are required, and how success is measured.

Aspect Workshop Meaning Check
Scope Inventory, pattern, --limit, tags, and environment select target systems. ansible-inventory --graph, ansible-playbook --list-hosts
State Modules should model desired state and produce repeatable results. second run without unnecessary changes
Privilege become is used close to the task and justified. no broad global privilege without review
Evidence Output, diffs, and summaries are documented. play recap, diff, evidence file

Typical commands:

bash
ansible --version
ansible-config dump --only-changed
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff

For reviews, a playbook is ready only when it proves its target scope, exposes its data sources, protects sensitive values, describes failure paths, and remains stable after a second run. If a module does not fully support check mode or diff mode, that limitation belongs in the runbook.

Common mistakes are broad patterns such as all, unclear variable sources, shell workarounds without idempotence, secrets in debug output, missing rollback notes, and missing separation between lab and production inventory.

12 / 23

13. Workshop Labs

Deep Dive and Submission Example for Workshop Labs

A complete treatment of Workshop Labs contains both a technical artifact and a short domain explanation. The artifact can be an inventory, a playbook, a role, a template, a Vault file with dummy values, a CI configuration, or an evidence file. The explanation states why this path was chosen and which alternative was deliberately not used.

Submission Part Content Minimum Quality
target description what should be true after the run measurable and without hidden assumptions
scope evidence which hosts are affected output from --list-hosts or inventory graph
implementation which files were changed small reviewable YAML files
validation how it was checked syntax check, check mode, diff, real run, second run
risk decision what can go wrong privileges, secrets, external dependencies, and rollback considered

Minimal Artifacts for Workshop Labs

text
submission/
  inventory/hosts.yml
  playbooks/site.yml
  evidence.md
  cleanup.md

For roles or collections, the structure expands:

text
submission/
  ansible.cfg
  collections/requirements.yml
  inventory/hosts.yml
  roles/<role>/defaults/main.yml
  roles/<role>/tasks/main.yml
  roles/<role>/handlers/main.yml
  playbooks/site.yml
  evidence.md

Grading Expectation for Workshop Labs

A reviewable solution must be understandable to people who did not run it themselves. Screenshots or uncommented terminal output are not enough. Good evidence states context, command, relevant output, and assessment. If a module behaves differently in check mode, that limitation is explicitly documented.

Transfer to Real Teams

In a team context, Workshop Labs is connected to code review, branch rules, CI, role ownership, release notes, and operational approval. Production-like usage also documents ownership, maintenance window, monitoring, alerting, and rollback criteria.

Practical Relevance of Workshop Labs

This section is not just a definition. In the workshop, Workshop Labs is always validated through a concrete flow: inspect inventory, prove target hosts, check the playbook, simulate the change, run the change, evaluate a second run, and document cleanup. This shows whether Ansible really models desired state or merely executes a command successfully once.

Review Question Expected Answer
Which hosts are affected? Pattern, group, --limit, and inventory output are documented.
Which data sources apply? group_vars, host_vars, defaults, extra vars, and facts are known.
Which privileges are required? become is close to the task and justified.
How is success proven? Syntax check, check mode, diff, play recap, and second run are present.

Example Flow for Workshop Labs

bash
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --list-hosts
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff
ansible-playbook -i inventory/hosts.yml playbooks/site.yml
ansible-playbook -i inventory/hosts.yml playbooks/site.yml

The flow is intentionally complete. In real teams, some steps are automated but not skipped. CI can run syntax checks and linting; the domain review of scope, privileges, secret flows, and rollout risk remains a human engineering task.

Review Criteria for Workshop Labs

  • Inventory and patterns are narrower than all unless a reason is documented.
  • Modules from ansible.builtin or reviewed collections are preferred.
  • Shell or command tasks include changed_when, failed_when, or a clear reason.
  • Variables are placed predictably and do not override each other surprisingly.
  • Secrets do not appear in plaintext, diffs, debug tasks, or CI logs.
  • The playbook can run repeatedly without unnecessary changes.
  • Cleanup, fix-forward, or controlled acceptance of the target state is documented.

Common Failure Modes for Workshop Labs

Failure Cause Diagnosis
wrong hosts targeted pattern or inventory misunderstood --list-hosts, ansible-inventory --host
unreachable SSH, user, Python, or network issue -vvvv, SSH test, inventory variables
unexpected change module not idempotent or wrong data source second run, diff, variable inspection
secret leak debug, diff, or log not scoped check no_log, Vault, CI artifacts
handler does not run no changed result or wrong handler name inspect task result and handler name

Operations Note for Workshop Labs

For production-like usage, the lab must become a runbook. The runbook states target systems, owners, prerequisites, stop criteria, expected duration, validation, monitoring, and cleanup. Without those details, a playbook is executable but not operationally mature.

Workshop Labs is a practical building block of the Ansible workshop. The desired state must be described, executed against a controlled scope, and validated before and after the run. A solid Ansible workflow answers four questions: which hosts are targeted, which change is performed, which privileges are required, and how success is measured.

Aspect Workshop Meaning Check
Scope Inventory, pattern, --limit, tags, and environment select target systems. ansible-inventory --graph, ansible-playbook --list-hosts
State Modules should model desired state and produce repeatable results. second run without unnecessary changes
Privilege become is used close to the task and justified. no broad global privilege without review
Evidence Output, diffs, and summaries are documented. play recap, diff, evidence file

Typical commands:

bash
ansible --version
ansible-config dump --only-changed
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff

For reviews, a playbook is ready only when it proves its target scope, exposes its data sources, protects sensitive values, describes failure paths, and remains stable after a second run. If a module does not fully support check mode or diff mode, that limitation belongs in the runbook.

Common mistakes are broad patterns such as all, unclear variable sources, shell workarounds without idempotence, secrets in debug output, missing rollback notes, and missing separation between lab and production inventory.

13 / 23

14. Final Projects

Deep Dive and Submission Example for Final Projects

A complete treatment of Final Projects contains both a technical artifact and a short domain explanation. The artifact can be an inventory, a playbook, a role, a template, a Vault file with dummy values, a CI configuration, or an evidence file. The explanation states why this path was chosen and which alternative was deliberately not used.

Submission Part Content Minimum Quality
target description what should be true after the run measurable and without hidden assumptions
scope evidence which hosts are affected output from --list-hosts or inventory graph
implementation which files were changed small reviewable YAML files
validation how it was checked syntax check, check mode, diff, real run, second run
risk decision what can go wrong privileges, secrets, external dependencies, and rollback considered

Minimal Artifacts for Final Projects

text
submission/
  inventory/hosts.yml
  playbooks/site.yml
  evidence.md
  cleanup.md

For roles or collections, the structure expands:

text
submission/
  ansible.cfg
  collections/requirements.yml
  inventory/hosts.yml
  roles/<role>/defaults/main.yml
  roles/<role>/tasks/main.yml
  roles/<role>/handlers/main.yml
  playbooks/site.yml
  evidence.md

Grading Expectation for Final Projects

A reviewable solution must be understandable to people who did not run it themselves. Screenshots or uncommented terminal output are not enough. Good evidence states context, command, relevant output, and assessment. If a module behaves differently in check mode, that limitation is explicitly documented.

Transfer to Real Teams

In a team context, Final Projects is connected to code review, branch rules, CI, role ownership, release notes, and operational approval. Production-like usage also documents ownership, maintenance window, monitoring, alerting, and rollback criteria.

Practical Relevance of Final Projects

This section is not just a definition. In the workshop, Final Projects is always validated through a concrete flow: inspect inventory, prove target hosts, check the playbook, simulate the change, run the change, evaluate a second run, and document cleanup. This shows whether Ansible really models desired state or merely executes a command successfully once.

Review Question Expected Answer
Which hosts are affected? Pattern, group, --limit, and inventory output are documented.
Which data sources apply? group_vars, host_vars, defaults, extra vars, and facts are known.
Which privileges are required? become is close to the task and justified.
How is success proven? Syntax check, check mode, diff, play recap, and second run are present.

Example Flow for Final Projects

bash
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --list-hosts
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff
ansible-playbook -i inventory/hosts.yml playbooks/site.yml
ansible-playbook -i inventory/hosts.yml playbooks/site.yml

The flow is intentionally complete. In real teams, some steps are automated but not skipped. CI can run syntax checks and linting; the domain review of scope, privileges, secret flows, and rollout risk remains a human engineering task.

Review Criteria for Final Projects

  • Inventory and patterns are narrower than all unless a reason is documented.
  • Modules from ansible.builtin or reviewed collections are preferred.
  • Shell or command tasks include changed_when, failed_when, or a clear reason.
  • Variables are placed predictably and do not override each other surprisingly.
  • Secrets do not appear in plaintext, diffs, debug tasks, or CI logs.
  • The playbook can run repeatedly without unnecessary changes.
  • Cleanup, fix-forward, or controlled acceptance of the target state is documented.

Common Failure Modes for Final Projects

Failure Cause Diagnosis
wrong hosts targeted pattern or inventory misunderstood --list-hosts, ansible-inventory --host
unreachable SSH, user, Python, or network issue -vvvv, SSH test, inventory variables
unexpected change module not idempotent or wrong data source second run, diff, variable inspection
secret leak debug, diff, or log not scoped check no_log, Vault, CI artifacts
handler does not run no changed result or wrong handler name inspect task result and handler name

Operations Note for Final Projects

For production-like usage, the lab must become a runbook. The runbook states target systems, owners, prerequisites, stop criteria, expected duration, validation, monitoring, and cleanup. Without those details, a playbook is executable but not operationally mature.

Final Projects is a practical building block of the Ansible workshop. The desired state must be described, executed against a controlled scope, and validated before and after the run. A solid Ansible workflow answers four questions: which hosts are targeted, which change is performed, which privileges are required, and how success is measured.

Aspect Workshop Meaning Check
Scope Inventory, pattern, --limit, tags, and environment select target systems. ansible-inventory --graph, ansible-playbook --list-hosts
State Modules should model desired state and produce repeatable results. second run without unnecessary changes
Privilege become is used close to the task and justified. no broad global privilege without review
Evidence Output, diffs, and summaries are documented. play recap, diff, evidence file

Typical commands:

bash
ansible --version
ansible-config dump --only-changed
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff

For reviews, a playbook is ready only when it proves its target scope, exposes its data sources, protects sensitive values, describes failure paths, and remains stable after a second run. If a module does not fully support check mode or diff mode, that limitation belongs in the runbook.

Common mistakes are broad patterns such as all, unclear variable sources, shell workarounds without idempotence, secrets in debug output, missing rollback notes, and missing separation between lab and production inventory.

14 / 23

15. Assessment Rubric

Deep Dive and Submission Example for Assessment Rubric

A complete treatment of Assessment Rubric contains both a technical artifact and a short domain explanation. The artifact can be an inventory, a playbook, a role, a template, a Vault file with dummy values, a CI configuration, or an evidence file. The explanation states why this path was chosen and which alternative was deliberately not used.

Submission Part Content Minimum Quality
target description what should be true after the run measurable and without hidden assumptions
scope evidence which hosts are affected output from --list-hosts or inventory graph
implementation which files were changed small reviewable YAML files
validation how it was checked syntax check, check mode, diff, real run, second run
risk decision what can go wrong privileges, secrets, external dependencies, and rollback considered

Minimal Artifacts for Assessment Rubric

text
submission/
  inventory/hosts.yml
  playbooks/site.yml
  evidence.md
  cleanup.md

For roles or collections, the structure expands:

text
submission/
  ansible.cfg
  collections/requirements.yml
  inventory/hosts.yml
  roles/<role>/defaults/main.yml
  roles/<role>/tasks/main.yml
  roles/<role>/handlers/main.yml
  playbooks/site.yml
  evidence.md

Grading Expectation for Assessment Rubric

A reviewable solution must be understandable to people who did not run it themselves. Screenshots or uncommented terminal output are not enough. Good evidence states context, command, relevant output, and assessment. If a module behaves differently in check mode, that limitation is explicitly documented.

Transfer to Real Teams

In a team context, Assessment Rubric is connected to code review, branch rules, CI, role ownership, release notes, and operational approval. Production-like usage also documents ownership, maintenance window, monitoring, alerting, and rollback criteria.

Practical Relevance of Assessment Rubric

This section is not just a definition. In the workshop, Assessment Rubric is always validated through a concrete flow: inspect inventory, prove target hosts, check the playbook, simulate the change, run the change, evaluate a second run, and document cleanup. This shows whether Ansible really models desired state or merely executes a command successfully once.

Review Question Expected Answer
Which hosts are affected? Pattern, group, --limit, and inventory output are documented.
Which data sources apply? group_vars, host_vars, defaults, extra vars, and facts are known.
Which privileges are required? become is close to the task and justified.
How is success proven? Syntax check, check mode, diff, play recap, and second run are present.

Example Flow for Assessment Rubric

bash
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --list-hosts
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff
ansible-playbook -i inventory/hosts.yml playbooks/site.yml
ansible-playbook -i inventory/hosts.yml playbooks/site.yml

The flow is intentionally complete. In real teams, some steps are automated but not skipped. CI can run syntax checks and linting; the domain review of scope, privileges, secret flows, and rollout risk remains a human engineering task.

Review Criteria for Assessment Rubric

  • Inventory and patterns are narrower than all unless a reason is documented.
  • Modules from ansible.builtin or reviewed collections are preferred.
  • Shell or command tasks include changed_when, failed_when, or a clear reason.
  • Variables are placed predictably and do not override each other surprisingly.
  • Secrets do not appear in plaintext, diffs, debug tasks, or CI logs.
  • The playbook can run repeatedly without unnecessary changes.
  • Cleanup, fix-forward, or controlled acceptance of the target state is documented.

Common Failure Modes for Assessment Rubric

Failure Cause Diagnosis
wrong hosts targeted pattern or inventory misunderstood --list-hosts, ansible-inventory --host
unreachable SSH, user, Python, or network issue -vvvv, SSH test, inventory variables
unexpected change module not idempotent or wrong data source second run, diff, variable inspection
secret leak debug, diff, or log not scoped check no_log, Vault, CI artifacts
handler does not run no changed result or wrong handler name inspect task result and handler name

Operations Note for Assessment Rubric

For production-like usage, the lab must become a runbook. The runbook states target systems, owners, prerequisites, stop criteria, expected duration, validation, monitoring, and cleanup. Without those details, a playbook is executable but not operationally mature.

Assessment Rubric is a practical building block of the Ansible workshop. The desired state must be described, executed against a controlled scope, and validated before and after the run. A solid Ansible workflow answers four questions: which hosts are targeted, which change is performed, which privileges are required, and how success is measured.

Aspect Workshop Meaning Check
Scope Inventory, pattern, --limit, tags, and environment select target systems. ansible-inventory --graph, ansible-playbook --list-hosts
State Modules should model desired state and produce repeatable results. second run without unnecessary changes
Privilege become is used close to the task and justified. no broad global privilege without review
Evidence Output, diffs, and summaries are documented. play recap, diff, evidence file

Typical commands:

bash
ansible --version
ansible-config dump --only-changed
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff

For reviews, a playbook is ready only when it proves its target scope, exposes its data sources, protects sensitive values, describes failure paths, and remains stable after a second run. If a module does not fully support check mode or diff mode, that limitation belongs in the runbook.

Common mistakes are broad patterns such as all, unclear variable sources, shell workarounds without idempotence, secrets in debug output, missing rollback notes, and missing separation between lab and production inventory.

15 / 23

16. Agenda Variants

Deep Dive and Submission Example for Agenda Variants

A complete treatment of Agenda Variants contains both a technical artifact and a short domain explanation. The artifact can be an inventory, a playbook, a role, a template, a Vault file with dummy values, a CI configuration, or an evidence file. The explanation states why this path was chosen and which alternative was deliberately not used.

Submission Part Content Minimum Quality
target description what should be true after the run measurable and without hidden assumptions
scope evidence which hosts are affected output from --list-hosts or inventory graph
implementation which files were changed small reviewable YAML files
validation how it was checked syntax check, check mode, diff, real run, second run
risk decision what can go wrong privileges, secrets, external dependencies, and rollback considered

Minimal Artifacts for Agenda Variants

text
submission/
  inventory/hosts.yml
  playbooks/site.yml
  evidence.md
  cleanup.md

For roles or collections, the structure expands:

text
submission/
  ansible.cfg
  collections/requirements.yml
  inventory/hosts.yml
  roles/<role>/defaults/main.yml
  roles/<role>/tasks/main.yml
  roles/<role>/handlers/main.yml
  playbooks/site.yml
  evidence.md

Grading Expectation for Agenda Variants

A reviewable solution must be understandable to people who did not run it themselves. Screenshots or uncommented terminal output are not enough. Good evidence states context, command, relevant output, and assessment. If a module behaves differently in check mode, that limitation is explicitly documented.

Transfer to Real Teams

In a team context, Agenda Variants is connected to code review, branch rules, CI, role ownership, release notes, and operational approval. Production-like usage also documents ownership, maintenance window, monitoring, alerting, and rollback criteria.

Practical Relevance of Agenda Variants

This section is not just a definition. In the workshop, Agenda Variants is always validated through a concrete flow: inspect inventory, prove target hosts, check the playbook, simulate the change, run the change, evaluate a second run, and document cleanup. This shows whether Ansible really models desired state or merely executes a command successfully once.

Review Question Expected Answer
Which hosts are affected? Pattern, group, --limit, and inventory output are documented.
Which data sources apply? group_vars, host_vars, defaults, extra vars, and facts are known.
Which privileges are required? become is close to the task and justified.
How is success proven? Syntax check, check mode, diff, play recap, and second run are present.

Example Flow for Agenda Variants

bash
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --list-hosts
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff
ansible-playbook -i inventory/hosts.yml playbooks/site.yml
ansible-playbook -i inventory/hosts.yml playbooks/site.yml

The flow is intentionally complete. In real teams, some steps are automated but not skipped. CI can run syntax checks and linting; the domain review of scope, privileges, secret flows, and rollout risk remains a human engineering task.

Review Criteria for Agenda Variants

  • Inventory and patterns are narrower than all unless a reason is documented.
  • Modules from ansible.builtin or reviewed collections are preferred.
  • Shell or command tasks include changed_when, failed_when, or a clear reason.
  • Variables are placed predictably and do not override each other surprisingly.
  • Secrets do not appear in plaintext, diffs, debug tasks, or CI logs.
  • The playbook can run repeatedly without unnecessary changes.
  • Cleanup, fix-forward, or controlled acceptance of the target state is documented.

Common Failure Modes for Agenda Variants

Failure Cause Diagnosis
wrong hosts targeted pattern or inventory misunderstood --list-hosts, ansible-inventory --host
unreachable SSH, user, Python, or network issue -vvvv, SSH test, inventory variables
unexpected change module not idempotent or wrong data source second run, diff, variable inspection
secret leak debug, diff, or log not scoped check no_log, Vault, CI artifacts
handler does not run no changed result or wrong handler name inspect task result and handler name

Operations Note for Agenda Variants

For production-like usage, the lab must become a runbook. The runbook states target systems, owners, prerequisites, stop criteria, expected duration, validation, monitoring, and cleanup. Without those details, a playbook is executable but not operationally mature.

Agenda Variants is a practical building block of the Ansible workshop. The desired state must be described, executed against a controlled scope, and validated before and after the run. A solid Ansible workflow answers four questions: which hosts are targeted, which change is performed, which privileges are required, and how success is measured.

Aspect Workshop Meaning Check
Scope Inventory, pattern, --limit, tags, and environment select target systems. ansible-inventory --graph, ansible-playbook --list-hosts
State Modules should model desired state and produce repeatable results. second run without unnecessary changes
Privilege become is used close to the task and justified. no broad global privilege without review
Evidence Output, diffs, and summaries are documented. play recap, diff, evidence file

Typical commands:

bash
ansible --version
ansible-config dump --only-changed
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff

For reviews, a playbook is ready only when it proves its target scope, exposes its data sources, protects sensitive values, describes failure paths, and remains stable after a second run. If a module does not fully support check mode or diff mode, that limitation belongs in the runbook.

Common mistakes are broad patterns such as all, unclear variable sources, shell workarounds without idempotence, secrets in debug output, missing rollback notes, and missing separation between lab and production inventory.

16 / 23

17. Trainer Guide

Deep Dive and Submission Example for Trainer Guide

A complete treatment of Trainer Guide contains both a technical artifact and a short domain explanation. The artifact can be an inventory, a playbook, a role, a template, a Vault file with dummy values, a CI configuration, or an evidence file. The explanation states why this path was chosen and which alternative was deliberately not used.

Submission Part Content Minimum Quality
target description what should be true after the run measurable and without hidden assumptions
scope evidence which hosts are affected output from --list-hosts or inventory graph
implementation which files were changed small reviewable YAML files
validation how it was checked syntax check, check mode, diff, real run, second run
risk decision what can go wrong privileges, secrets, external dependencies, and rollback considered

Minimal Artifacts for Trainer Guide

text
submission/
  inventory/hosts.yml
  playbooks/site.yml
  evidence.md
  cleanup.md

For roles or collections, the structure expands:

text
submission/
  ansible.cfg
  collections/requirements.yml
  inventory/hosts.yml
  roles/<role>/defaults/main.yml
  roles/<role>/tasks/main.yml
  roles/<role>/handlers/main.yml
  playbooks/site.yml
  evidence.md

Grading Expectation for Trainer Guide

A reviewable solution must be understandable to people who did not run it themselves. Screenshots or uncommented terminal output are not enough. Good evidence states context, command, relevant output, and assessment. If a module behaves differently in check mode, that limitation is explicitly documented.

Transfer to Real Teams

In a team context, Trainer Guide is connected to code review, branch rules, CI, role ownership, release notes, and operational approval. Production-like usage also documents ownership, maintenance window, monitoring, alerting, and rollback criteria.

Practical Relevance of Trainer Guide

This section is not just a definition. In the workshop, Trainer Guide is always validated through a concrete flow: inspect inventory, prove target hosts, check the playbook, simulate the change, run the change, evaluate a second run, and document cleanup. This shows whether Ansible really models desired state or merely executes a command successfully once.

Review Question Expected Answer
Which hosts are affected? Pattern, group, --limit, and inventory output are documented.
Which data sources apply? group_vars, host_vars, defaults, extra vars, and facts are known.
Which privileges are required? become is close to the task and justified.
How is success proven? Syntax check, check mode, diff, play recap, and second run are present.

Example Flow for Trainer Guide

bash
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --list-hosts
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff
ansible-playbook -i inventory/hosts.yml playbooks/site.yml
ansible-playbook -i inventory/hosts.yml playbooks/site.yml

The flow is intentionally complete. In real teams, some steps are automated but not skipped. CI can run syntax checks and linting; the domain review of scope, privileges, secret flows, and rollout risk remains a human engineering task.

Review Criteria for Trainer Guide

  • Inventory and patterns are narrower than all unless a reason is documented.
  • Modules from ansible.builtin or reviewed collections are preferred.
  • Shell or command tasks include changed_when, failed_when, or a clear reason.
  • Variables are placed predictably and do not override each other surprisingly.
  • Secrets do not appear in plaintext, diffs, debug tasks, or CI logs.
  • The playbook can run repeatedly without unnecessary changes.
  • Cleanup, fix-forward, or controlled acceptance of the target state is documented.

Common Failure Modes for Trainer Guide

Failure Cause Diagnosis
wrong hosts targeted pattern or inventory misunderstood --list-hosts, ansible-inventory --host
unreachable SSH, user, Python, or network issue -vvvv, SSH test, inventory variables
unexpected change module not idempotent or wrong data source second run, diff, variable inspection
secret leak debug, diff, or log not scoped check no_log, Vault, CI artifacts
handler does not run no changed result or wrong handler name inspect task result and handler name

Operations Note for Trainer Guide

For production-like usage, the lab must become a runbook. The runbook states target systems, owners, prerequisites, stop criteria, expected duration, validation, monitoring, and cleanup. Without those details, a playbook is executable but not operationally mature.

Trainer Guide is a practical building block of the Ansible workshop. The desired state must be described, executed against a controlled scope, and validated before and after the run. A solid Ansible workflow answers four questions: which hosts are targeted, which change is performed, which privileges are required, and how success is measured.

Aspect Workshop Meaning Check
Scope Inventory, pattern, --limit, tags, and environment select target systems. ansible-inventory --graph, ansible-playbook --list-hosts
State Modules should model desired state and produce repeatable results. second run without unnecessary changes
Privilege become is used close to the task and justified. no broad global privilege without review
Evidence Output, diffs, and summaries are documented. play recap, diff, evidence file

Typical commands:

bash
ansible --version
ansible-config dump --only-changed
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff

For reviews, a playbook is ready only when it proves its target scope, exposes its data sources, protects sensitive values, describes failure paths, and remains stable after a second run. If a module does not fully support check mode or diff mode, that limitation belongs in the runbook.

Common mistakes are broad patterns such as all, unclear variable sources, shell workarounds without idempotence, secrets in debug output, missing rollback notes, and missing separation between lab and production inventory.

17 / 23

18. Knowledge Checks

Deep Dive and Submission Example for Knowledge Checks

A complete treatment of Knowledge Checks contains both a technical artifact and a short domain explanation. The artifact can be an inventory, a playbook, a role, a template, a Vault file with dummy values, a CI configuration, or an evidence file. The explanation states why this path was chosen and which alternative was deliberately not used.

Submission Part Content Minimum Quality
target description what should be true after the run measurable and without hidden assumptions
scope evidence which hosts are affected output from --list-hosts or inventory graph
implementation which files were changed small reviewable YAML files
validation how it was checked syntax check, check mode, diff, real run, second run
risk decision what can go wrong privileges, secrets, external dependencies, and rollback considered

Minimal Artifacts for Knowledge Checks

text
submission/
  inventory/hosts.yml
  playbooks/site.yml
  evidence.md
  cleanup.md

For roles or collections, the structure expands:

text
submission/
  ansible.cfg
  collections/requirements.yml
  inventory/hosts.yml
  roles/<role>/defaults/main.yml
  roles/<role>/tasks/main.yml
  roles/<role>/handlers/main.yml
  playbooks/site.yml
  evidence.md

Grading Expectation for Knowledge Checks

A reviewable solution must be understandable to people who did not run it themselves. Screenshots or uncommented terminal output are not enough. Good evidence states context, command, relevant output, and assessment. If a module behaves differently in check mode, that limitation is explicitly documented.

Transfer to Real Teams

In a team context, Knowledge Checks is connected to code review, branch rules, CI, role ownership, release notes, and operational approval. Production-like usage also documents ownership, maintenance window, monitoring, alerting, and rollback criteria.

Practical Relevance of Knowledge Checks

This section is not just a definition. In the workshop, Knowledge Checks is always validated through a concrete flow: inspect inventory, prove target hosts, check the playbook, simulate the change, run the change, evaluate a second run, and document cleanup. This shows whether Ansible really models desired state or merely executes a command successfully once.

Review Question Expected Answer
Which hosts are affected? Pattern, group, --limit, and inventory output are documented.
Which data sources apply? group_vars, host_vars, defaults, extra vars, and facts are known.
Which privileges are required? become is close to the task and justified.
How is success proven? Syntax check, check mode, diff, play recap, and second run are present.

Example Flow for Knowledge Checks

bash
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --list-hosts
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff
ansible-playbook -i inventory/hosts.yml playbooks/site.yml
ansible-playbook -i inventory/hosts.yml playbooks/site.yml

The flow is intentionally complete. In real teams, some steps are automated but not skipped. CI can run syntax checks and linting; the domain review of scope, privileges, secret flows, and rollout risk remains a human engineering task.

Review Criteria for Knowledge Checks

  • Inventory and patterns are narrower than all unless a reason is documented.
  • Modules from ansible.builtin or reviewed collections are preferred.
  • Shell or command tasks include changed_when, failed_when, or a clear reason.
  • Variables are placed predictably and do not override each other surprisingly.
  • Secrets do not appear in plaintext, diffs, debug tasks, or CI logs.
  • The playbook can run repeatedly without unnecessary changes.
  • Cleanup, fix-forward, or controlled acceptance of the target state is documented.

Common Failure Modes for Knowledge Checks

Failure Cause Diagnosis
wrong hosts targeted pattern or inventory misunderstood --list-hosts, ansible-inventory --host
unreachable SSH, user, Python, or network issue -vvvv, SSH test, inventory variables
unexpected change module not idempotent or wrong data source second run, diff, variable inspection
secret leak debug, diff, or log not scoped check no_log, Vault, CI artifacts
handler does not run no changed result or wrong handler name inspect task result and handler name

Operations Note for Knowledge Checks

For production-like usage, the lab must become a runbook. The runbook states target systems, owners, prerequisites, stop criteria, expected duration, validation, monitoring, and cleanup. Without those details, a playbook is executable but not operationally mature.

Knowledge Checks is a practical building block of the Ansible workshop. The desired state must be described, executed against a controlled scope, and validated before and after the run. A solid Ansible workflow answers four questions: which hosts are targeted, which change is performed, which privileges are required, and how success is measured.

Aspect Workshop Meaning Check
Scope Inventory, pattern, --limit, tags, and environment select target systems. ansible-inventory --graph, ansible-playbook --list-hosts
State Modules should model desired state and produce repeatable results. second run without unnecessary changes
Privilege become is used close to the task and justified. no broad global privilege without review
Evidence Output, diffs, and summaries are documented. play recap, diff, evidence file

Typical commands:

bash
ansible --version
ansible-config dump --only-changed
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff

For reviews, a playbook is ready only when it proves its target scope, exposes its data sources, protects sensitive values, describes failure paths, and remains stable after a second run. If a module does not fully support check mode or diff mode, that limitation belongs in the runbook.

Common mistakes are broad patterns such as all, unclear variable sources, shell workarounds without idempotence, secrets in debug output, missing rollback notes, and missing separation between lab and production inventory.

18 / 23

19. Common Misconceptions

Deep Dive and Submission Example for Common Misconceptions

A complete treatment of Common Misconceptions contains both a technical artifact and a short domain explanation. The artifact can be an inventory, a playbook, a role, a template, a Vault file with dummy values, a CI configuration, or an evidence file. The explanation states why this path was chosen and which alternative was deliberately not used.

Submission Part Content Minimum Quality
target description what should be true after the run measurable and without hidden assumptions
scope evidence which hosts are affected output from --list-hosts or inventory graph
implementation which files were changed small reviewable YAML files
validation how it was checked syntax check, check mode, diff, real run, second run
risk decision what can go wrong privileges, secrets, external dependencies, and rollback considered

Minimal Artifacts for Common Misconceptions

text
submission/
  inventory/hosts.yml
  playbooks/site.yml
  evidence.md
  cleanup.md

For roles or collections, the structure expands:

text
submission/
  ansible.cfg
  collections/requirements.yml
  inventory/hosts.yml
  roles/<role>/defaults/main.yml
  roles/<role>/tasks/main.yml
  roles/<role>/handlers/main.yml
  playbooks/site.yml
  evidence.md

Grading Expectation for Common Misconceptions

A reviewable solution must be understandable to people who did not run it themselves. Screenshots or uncommented terminal output are not enough. Good evidence states context, command, relevant output, and assessment. If a module behaves differently in check mode, that limitation is explicitly documented.

Transfer to Real Teams

In a team context, Common Misconceptions is connected to code review, branch rules, CI, role ownership, release notes, and operational approval. Production-like usage also documents ownership, maintenance window, monitoring, alerting, and rollback criteria.

Practical Relevance of Common Misconceptions

This section is not just a definition. In the workshop, Common Misconceptions is always validated through a concrete flow: inspect inventory, prove target hosts, check the playbook, simulate the change, run the change, evaluate a second run, and document cleanup. This shows whether Ansible really models desired state or merely executes a command successfully once.

Review Question Expected Answer
Which hosts are affected? Pattern, group, --limit, and inventory output are documented.
Which data sources apply? group_vars, host_vars, defaults, extra vars, and facts are known.
Which privileges are required? become is close to the task and justified.
How is success proven? Syntax check, check mode, diff, play recap, and second run are present.

Example Flow for Common Misconceptions

bash
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --list-hosts
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff
ansible-playbook -i inventory/hosts.yml playbooks/site.yml
ansible-playbook -i inventory/hosts.yml playbooks/site.yml

The flow is intentionally complete. In real teams, some steps are automated but not skipped. CI can run syntax checks and linting; the domain review of scope, privileges, secret flows, and rollout risk remains a human engineering task.

Review Criteria for Common Misconceptions

  • Inventory and patterns are narrower than all unless a reason is documented.
  • Modules from ansible.builtin or reviewed collections are preferred.
  • Shell or command tasks include changed_when, failed_when, or a clear reason.
  • Variables are placed predictably and do not override each other surprisingly.
  • Secrets do not appear in plaintext, diffs, debug tasks, or CI logs.
  • The playbook can run repeatedly without unnecessary changes.
  • Cleanup, fix-forward, or controlled acceptance of the target state is documented.

Common Failure Modes for Common Misconceptions

Failure Cause Diagnosis
wrong hosts targeted pattern or inventory misunderstood --list-hosts, ansible-inventory --host
unreachable SSH, user, Python, or network issue -vvvv, SSH test, inventory variables
unexpected change module not idempotent or wrong data source second run, diff, variable inspection
secret leak debug, diff, or log not scoped check no_log, Vault, CI artifacts
handler does not run no changed result or wrong handler name inspect task result and handler name

Operations Note for Common Misconceptions

For production-like usage, the lab must become a runbook. The runbook states target systems, owners, prerequisites, stop criteria, expected duration, validation, monitoring, and cleanup. Without those details, a playbook is executable but not operationally mature.

Common Misconceptions is a practical building block of the Ansible workshop. The desired state must be described, executed against a controlled scope, and validated before and after the run. A solid Ansible workflow answers four questions: which hosts are targeted, which change is performed, which privileges are required, and how success is measured.

Aspect Workshop Meaning Check
Scope Inventory, pattern, --limit, tags, and environment select target systems. ansible-inventory --graph, ansible-playbook --list-hosts
State Modules should model desired state and produce repeatable results. second run without unnecessary changes
Privilege become is used close to the task and justified. no broad global privilege without review
Evidence Output, diffs, and summaries are documented. play recap, diff, evidence file

Typical commands:

bash
ansible --version
ansible-config dump --only-changed
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff

For reviews, a playbook is ready only when it proves its target scope, exposes its data sources, protects sensitive values, describes failure paths, and remains stable after a second run. If a module does not fully support check mode or diff mode, that limitation belongs in the runbook.

Common mistakes are broad patterns such as all, unclear variable sources, shell workarounds without idempotence, secrets in debug output, missing rollback notes, and missing separation between lab and production inventory.

19 / 23

A complete treatment of Recommended Duration contains both a technical artifact and a short domain explanation. The artifact can be an inventory, a playbook, a role, a template, a Vault file with dummy values, a CI configuration, or an evidence file. The explanation states why this path was chosen and which alternative was deliberately not used.

Submission Part Content Minimum Quality
target description what should be true after the run measurable and without hidden assumptions
scope evidence which hosts are affected output from --list-hosts or inventory graph
implementation which files were changed small reviewable YAML files
validation how it was checked syntax check, check mode, diff, real run, second run
risk decision what can go wrong privileges, secrets, external dependencies, and rollback considered
text
submission/
  inventory/hosts.yml
  playbooks/site.yml
  evidence.md
  cleanup.md

For roles or collections, the structure expands:

text
submission/
  ansible.cfg
  collections/requirements.yml
  inventory/hosts.yml
  roles/<role>/defaults/main.yml
  roles/<role>/tasks/main.yml
  roles/<role>/handlers/main.yml
  playbooks/site.yml
  evidence.md

A reviewable solution must be understandable to people who did not run it themselves. Screenshots or uncommented terminal output are not enough. Good evidence states context, command, relevant output, and assessment. If a module behaves differently in check mode, that limitation is explicitly documented.

Transfer to Real Teams

In a team context, Recommended Duration is connected to code review, branch rules, CI, role ownership, release notes, and operational approval. Production-like usage also documents ownership, maintenance window, monitoring, alerting, and rollback criteria.

This section is not just a definition. In the workshop, Recommended Duration is always validated through a concrete flow: inspect inventory, prove target hosts, check the playbook, simulate the change, run the change, evaluate a second run, and document cleanup. This shows whether Ansible really models desired state or merely executes a command successfully once.

Review Question Expected Answer
Which hosts are affected? Pattern, group, --limit, and inventory output are documented.
Which data sources apply? group_vars, host_vars, defaults, extra vars, and facts are known.
Which privileges are required? become is close to the task and justified.
How is success proven? Syntax check, check mode, diff, play recap, and second run are present.
bash
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --list-hosts
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff
ansible-playbook -i inventory/hosts.yml playbooks/site.yml
ansible-playbook -i inventory/hosts.yml playbooks/site.yml

The flow is intentionally complete. In real teams, some steps are automated but not skipped. CI can run syntax checks and linting; the domain review of scope, privileges, secret flows, and rollout risk remains a human engineering task.

  • Inventory and patterns are narrower than all unless a reason is documented.
  • Modules from ansible.builtin or reviewed collections are preferred.
  • Shell or command tasks include changed_when, failed_when, or a clear reason.
  • Variables are placed predictably and do not override each other surprisingly.
  • Secrets do not appear in plaintext, diffs, debug tasks, or CI logs.
  • The playbook can run repeatedly without unnecessary changes.
  • Cleanup, fix-forward, or controlled acceptance of the target state is documented.
Failure Cause Diagnosis
wrong hosts targeted pattern or inventory misunderstood --list-hosts, ansible-inventory --host
unreachable SSH, user, Python, or network issue -vvvv, SSH test, inventory variables
unexpected change module not idempotent or wrong data source second run, diff, variable inspection
secret leak debug, diff, or log not scoped check no_log, Vault, CI artifacts
handler does not run no changed result or wrong handler name inspect task result and handler name

For production-like usage, the lab must become a runbook. The runbook states target systems, owners, prerequisites, stop criteria, expected duration, validation, monitoring, and cleanup. Without those details, a playbook is executable but not operationally mature.

Recommended Duration is a practical building block of the Ansible workshop. The desired state must be described, executed against a controlled scope, and validated before and after the run. A solid Ansible workflow answers four questions: which hosts are targeted, which change is performed, which privileges are required, and how success is measured.

Aspect Workshop Meaning Check
Scope Inventory, pattern, --limit, tags, and environment select target systems. ansible-inventory --graph, ansible-playbook --list-hosts
State Modules should model desired state and produce repeatable results. second run without unnecessary changes
Privilege become is used close to the task and justified. no broad global privilege without review
Evidence Output, diffs, and summaries are documented. play recap, diff, evidence file

Typical commands:

bash
ansible --version
ansible-config dump --only-changed
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff

For reviews, a playbook is ready only when it proves its target scope, exposes its data sources, protects sensitive values, describes failure paths, and remains stable after a second run. If a module does not fully support check mode or diff mode, that limitation belongs in the runbook.

Common mistakes are broad patterns such as all, unclear variable sources, shell workarounds without idempotence, secrets in debug output, missing rollback notes, and missing separation between lab and production inventory.

20 / 23

21. Mapping to Roles

Deep Dive and Submission Example for Mapping to Roles

A complete treatment of Mapping to Roles contains both a technical artifact and a short domain explanation. The artifact can be an inventory, a playbook, a role, a template, a Vault file with dummy values, a CI configuration, or an evidence file. The explanation states why this path was chosen and which alternative was deliberately not used.

Submission Part Content Minimum Quality
target description what should be true after the run measurable and without hidden assumptions
scope evidence which hosts are affected output from --list-hosts or inventory graph
implementation which files were changed small reviewable YAML files
validation how it was checked syntax check, check mode, diff, real run, second run
risk decision what can go wrong privileges, secrets, external dependencies, and rollback considered

Minimal Artifacts for Mapping to Roles

text
submission/
  inventory/hosts.yml
  playbooks/site.yml
  evidence.md
  cleanup.md

For roles or collections, the structure expands:

text
submission/
  ansible.cfg
  collections/requirements.yml
  inventory/hosts.yml
  roles/<role>/defaults/main.yml
  roles/<role>/tasks/main.yml
  roles/<role>/handlers/main.yml
  playbooks/site.yml
  evidence.md

Grading Expectation for Mapping to Roles

A reviewable solution must be understandable to people who did not run it themselves. Screenshots or uncommented terminal output are not enough. Good evidence states context, command, relevant output, and assessment. If a module behaves differently in check mode, that limitation is explicitly documented.

Transfer to Real Teams

In a team context, Mapping to Roles is connected to code review, branch rules, CI, role ownership, release notes, and operational approval. Production-like usage also documents ownership, maintenance window, monitoring, alerting, and rollback criteria.

Practical Relevance of Mapping to Roles

This section is not just a definition. In the workshop, Mapping to Roles is always validated through a concrete flow: inspect inventory, prove target hosts, check the playbook, simulate the change, run the change, evaluate a second run, and document cleanup. This shows whether Ansible really models desired state or merely executes a command successfully once.

Review Question Expected Answer
Which hosts are affected? Pattern, group, --limit, and inventory output are documented.
Which data sources apply? group_vars, host_vars, defaults, extra vars, and facts are known.
Which privileges are required? become is close to the task and justified.
How is success proven? Syntax check, check mode, diff, play recap, and second run are present.

Example Flow for Mapping to Roles

bash
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --list-hosts
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff
ansible-playbook -i inventory/hosts.yml playbooks/site.yml
ansible-playbook -i inventory/hosts.yml playbooks/site.yml

The flow is intentionally complete. In real teams, some steps are automated but not skipped. CI can run syntax checks and linting; the domain review of scope, privileges, secret flows, and rollout risk remains a human engineering task.

Review Criteria for Mapping to Roles

  • Inventory and patterns are narrower than all unless a reason is documented.
  • Modules from ansible.builtin or reviewed collections are preferred.
  • Shell or command tasks include changed_when, failed_when, or a clear reason.
  • Variables are placed predictably and do not override each other surprisingly.
  • Secrets do not appear in plaintext, diffs, debug tasks, or CI logs.
  • The playbook can run repeatedly without unnecessary changes.
  • Cleanup, fix-forward, or controlled acceptance of the target state is documented.

Common Failure Modes for Mapping to Roles

Failure Cause Diagnosis
wrong hosts targeted pattern or inventory misunderstood --list-hosts, ansible-inventory --host
unreachable SSH, user, Python, or network issue -vvvv, SSH test, inventory variables
unexpected change module not idempotent or wrong data source second run, diff, variable inspection
secret leak debug, diff, or log not scoped check no_log, Vault, CI artifacts
handler does not run no changed result or wrong handler name inspect task result and handler name

Operations Note for Mapping to Roles

For production-like usage, the lab must become a runbook. The runbook states target systems, owners, prerequisites, stop criteria, expected duration, validation, monitoring, and cleanup. Without those details, a playbook is executable but not operationally mature.

Mapping to Roles is a practical building block of the Ansible workshop. The desired state must be described, executed against a controlled scope, and validated before and after the run. A solid Ansible workflow answers four questions: which hosts are targeted, which change is performed, which privileges are required, and how success is measured.

Aspect Workshop Meaning Check
Scope Inventory, pattern, --limit, tags, and environment select target systems. ansible-inventory --graph, ansible-playbook --list-hosts
State Modules should model desired state and produce repeatable results. second run without unnecessary changes
Privilege become is used close to the task and justified. no broad global privilege without review
Evidence Output, diffs, and summaries are documented. play recap, diff, evidence file

Typical commands:

bash
ansible --version
ansible-config dump --only-changed
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff

For reviews, a playbook is ready only when it proves its target scope, exposes its data sources, protects sensitive values, describes failure paths, and remains stable after a second run. If a module does not fully support check mode or diff mode, that limitation belongs in the runbook.

Common mistakes are broad patterns such as all, unclear variable sources, shell workarounds without idempotence, secrets in debug output, missing rollback notes, and missing separation between lab and production inventory.

21 / 23

22. Further Topics

Deep Dive and Submission Example for Further Topics

A complete treatment of Further Topics contains both a technical artifact and a short domain explanation. The artifact can be an inventory, a playbook, a role, a template, a Vault file with dummy values, a CI configuration, or an evidence file. The explanation states why this path was chosen and which alternative was deliberately not used.

Submission Part Content Minimum Quality
target description what should be true after the run measurable and without hidden assumptions
scope evidence which hosts are affected output from --list-hosts or inventory graph
implementation which files were changed small reviewable YAML files
validation how it was checked syntax check, check mode, diff, real run, second run
risk decision what can go wrong privileges, secrets, external dependencies, and rollback considered

Minimal Artifacts for Further Topics

text
submission/
  inventory/hosts.yml
  playbooks/site.yml
  evidence.md
  cleanup.md

For roles or collections, the structure expands:

text
submission/
  ansible.cfg
  collections/requirements.yml
  inventory/hosts.yml
  roles/<role>/defaults/main.yml
  roles/<role>/tasks/main.yml
  roles/<role>/handlers/main.yml
  playbooks/site.yml
  evidence.md

Grading Expectation for Further Topics

A reviewable solution must be understandable to people who did not run it themselves. Screenshots or uncommented terminal output are not enough. Good evidence states context, command, relevant output, and assessment. If a module behaves differently in check mode, that limitation is explicitly documented.

Transfer to Real Teams

In a team context, Further Topics is connected to code review, branch rules, CI, role ownership, release notes, and operational approval. Production-like usage also documents ownership, maintenance window, monitoring, alerting, and rollback criteria.

Practical Relevance of Further Topics

This section is not just a definition. In the workshop, Further Topics is always validated through a concrete flow: inspect inventory, prove target hosts, check the playbook, simulate the change, run the change, evaluate a second run, and document cleanup. This shows whether Ansible really models desired state or merely executes a command successfully once.

Review Question Expected Answer
Which hosts are affected? Pattern, group, --limit, and inventory output are documented.
Which data sources apply? group_vars, host_vars, defaults, extra vars, and facts are known.
Which privileges are required? become is close to the task and justified.
How is success proven? Syntax check, check mode, diff, play recap, and second run are present.

Example Flow for Further Topics

bash
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --list-hosts
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff
ansible-playbook -i inventory/hosts.yml playbooks/site.yml
ansible-playbook -i inventory/hosts.yml playbooks/site.yml

The flow is intentionally complete. In real teams, some steps are automated but not skipped. CI can run syntax checks and linting; the domain review of scope, privileges, secret flows, and rollout risk remains a human engineering task.

Review Criteria for Further Topics

  • Inventory and patterns are narrower than all unless a reason is documented.
  • Modules from ansible.builtin or reviewed collections are preferred.
  • Shell or command tasks include changed_when, failed_when, or a clear reason.
  • Variables are placed predictably and do not override each other surprisingly.
  • Secrets do not appear in plaintext, diffs, debug tasks, or CI logs.
  • The playbook can run repeatedly without unnecessary changes.
  • Cleanup, fix-forward, or controlled acceptance of the target state is documented.

Common Failure Modes for Further Topics

Failure Cause Diagnosis
wrong hosts targeted pattern or inventory misunderstood --list-hosts, ansible-inventory --host
unreachable SSH, user, Python, or network issue -vvvv, SSH test, inventory variables
unexpected change module not idempotent or wrong data source second run, diff, variable inspection
secret leak debug, diff, or log not scoped check no_log, Vault, CI artifacts
handler does not run no changed result or wrong handler name inspect task result and handler name

Operations Note for Further Topics

For production-like usage, the lab must become a runbook. The runbook states target systems, owners, prerequisites, stop criteria, expected duration, validation, monitoring, and cleanup. Without those details, a playbook is executable but not operationally mature.

Further Topics is a practical building block of the Ansible workshop. The desired state must be described, executed against a controlled scope, and validated before and after the run. A solid Ansible workflow answers four questions: which hosts are targeted, which change is performed, which privileges are required, and how success is measured.

Aspect Workshop Meaning Check
Scope Inventory, pattern, --limit, tags, and environment select target systems. ansible-inventory --graph, ansible-playbook --list-hosts
State Modules should model desired state and produce repeatable results. second run without unnecessary changes
Privilege become is used close to the task and justified. no broad global privilege without review
Evidence Output, diffs, and summaries are documented. play recap, diff, evidence file

Typical commands:

bash
ansible --version
ansible-config dump --only-changed
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff

For reviews, a playbook is ready only when it proves its target scope, exposes its data sources, protects sensitive values, describes failure paths, and remains stable after a second run. If a module does not fully support check mode or diff mode, that limitation belongs in the runbook.

Common mistakes are broad patterns such as all, unclear variable sources, shell workarounds without idempotence, secrets in debug output, missing rollback notes, and missing separation between lab and production inventory.

22 / 23

Sources and Further References

  • Official Ansible Community Documentation: https://docs.ansible.com/
  • Ansible Getting Started: https://docs.ansible.com/projects/ansible/latest/getting_started/index.html
  • Inventory Guide: https://docs.ansible.com/projects/ansible/latest/inventory_guide/index.html
  • Playbook Guide: https://docs.ansible.com/projects/ansible/latest/playbook_guide/index.html
  • Module Index: https://docs.ansible.com/ansible/latest/collections/ansible/builtin/index.html
  • Vault Guide: https://docs.ansible.com/projects/ansible/latest/vault_guide/index.html
  • Ansible Lint: https://ansible.readthedocs.io/projects/lint/
  • Molecule: https://ansible.readthedocs.io/projects/molecule/
  • AWX: https://github.com/ansible/awx
  • Red Hat Certifications: https://www.redhat.com/en/services/certifications
23 / 23

ANS · Orthevs Academy

31 modules ως ενιαία διαδρομή μάθησης.

Η σειρά παραμένει αμετάβλητη: από τη βασική δομή του lab μέσω τεχνικών θεμελίων και λειτουργικών μοντέλων έως το τελικό troubleshooting. Τα τεχνικά ονόματα καταλόγων διατηρούνται σκόπιμα.

Πρακτικά modules

Το Orthevs ως εφαρμογή

Εγκατάσταση του Orthevs

Η web app του Orthevs μπορεί να εγκατασταθεί σε υποστηριζόμενες κινητές συσκευές και browsers υπολογιστή.

iPhone και iPad

Ανοίξτε το Orthevs στο Safari. Πατήστε Κοινή χρήση και μετά Προσθήκη στην οθόνη αφετηρίας. Ενεργοποιήστε το Άνοιγμα ως web app, αν εμφανίζεται, και πατήστε Προσθήκη.

Android

Για τη web app, ανοίξτε το μενού του browser και επιλέξτε Εγκατάσταση εφαρμογής ή Προσθήκη στην αρχική οθόνη. Επιβεβαιώστε την εγκατάσταση.

Browser υπολογιστή

Ανοίξτε το μενού του browser ή το εικονίδιο εγκατάστασης στη γραμμή διευθύνσεων και επιλέξτε Εγκατάσταση εφαρμογής ή Προσθήκη στο Dock.

Η εγκατάσταση της web app εξαρτάται από τον browser. Αν δεν εμφανιστεί διάλογος εγκατάστασης, ακολουθήστε τα βήματα του browser που αναφέρονται παραπάνω.