Orthevs Orthevs Fathom new horizons
Μενού

Wiki workshop · Αγγλικά

Ansible Workshop: Intermediate – Exercises with Solutions

A complete treatment of 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. Th…

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

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

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

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

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

Ansible Workshop: Intermediate – Exercises with Solutions

1. Goal

Deep Dive and Submission Example for Goal

A complete treatment of 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 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 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, 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 Goal

This section is not just a definition. In the workshop, 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 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 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 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 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.

These exercises complement the Intermediate workshop. They move from explanation to implementation, validation, and model solution.

01 / 24

2. Scenario

Deep Dive and Submission Example for Scenario

A complete treatment of Scenario 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 Scenario

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 Scenario

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, Scenario 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 Scenario

This section is not just a definition. In the workshop, Scenario 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 Scenario

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 Scenario

  • 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 Scenario

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 Scenario

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.

You work in an isolated Ansible lab. Use localhost or dedicated lab VMs. Production hosts, real secrets, and customer data are excluded.

02 / 24

3. Working Rules

Deep Dive and Submission Example for Working Rules

A complete treatment of Working Rules 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 Working Rules

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 Working Rules

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, Working Rules 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 Working Rules

This section is not just a definition. In the workshop, Working Rules 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 Working Rules

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 Working Rules

  • 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 Working Rules

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 Working Rules

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.

  1. Verify inventory and scope before every change.
  2. Use syntax check, check mode, and diff mode.
  3. Justify become.
  4. Document play recap and a second run.
  5. Clean up lab artifacts.
03 / 24

4. Task Overview

Deep Dive and Submission Example for Task Overview

A complete treatment of Task Overview 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 Task Overview

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 Task Overview

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, Task Overview 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 Task Overview

This section is not just a definition. In the workshop, Task Overview 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 Task Overview

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 Task Overview

  • 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 Task Overview

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 Task Overview

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.

No. Topic Result
1 variable precedence lab file, validation, and short rationale
2 facts lab file, validation, and short rationale
3 templates lab file, validation, and short rationale
4 roles lab file, validation, and short rationale
5 includes lab file, validation, and short rationale
6 imports lab file, validation, and short rationale
7 blocks lab file, validation, and short rationale
8 rescue lab file, validation, and short rationale
04 / 24

5. Part A: Tasks

Deep Dive and Submission Example for Part A: Tasks

A complete treatment of Part A: Tasks 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 Part A: Tasks

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 Part A: Tasks

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, Part A: Tasks 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 Part A: Tasks

This section is not just a definition. In the workshop, Part A: Tasks 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 Part A: Tasks

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 Part A: Tasks

  • 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 Part A: Tasks

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 Part A: Tasks

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.

05 / 24

Exercise 1: variable precedence

Deep Dive and Submission Example for Exercise 1: variable precedence

A complete treatment of Exercise 1: variable precedence 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 Exercise 1: variable precedence

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 Exercise 1: variable precedence

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, Exercise 1: variable precedence 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 Exercise 1: variable precedence

This section is not just a definition. In the workshop, Exercise 1: variable precedence 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 Exercise 1: variable precedence

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 Exercise 1: variable precedence

  • 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 Exercise 1: variable precedence

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 Exercise 1: variable precedence

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.

Goal

Apply variable precedence in a small safe lab and document scope, implementation, result, and cleanup.

Task

  1. Create or inspect a suitable inventory.
  2. Prove target scope with --list-hosts.
  3. Create or adapt a playbook.
  4. Use a suitable ansible.builtin module.
  5. Run syntax check, check mode, real run, and a second run.
  6. Document play recap, relevant output, and a short assessment.

Expected Result

  • The playbook is syntactically valid.
  • Target hosts are clear.
  • The second run reports no unnecessary changes.
  • Risks and limits are documented.
06 / 24

Exercise 2: facts

Deep Dive and Submission Example for Exercise 2: facts

A complete treatment of Exercise 2: facts 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 Exercise 2: facts

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 Exercise 2: facts

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, Exercise 2: facts 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 Exercise 2: facts

This section is not just a definition. In the workshop, Exercise 2: facts 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 Exercise 2: facts

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 Exercise 2: facts

  • 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 Exercise 2: facts

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 Exercise 2: facts

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.

Goal

Apply facts in a small safe lab and document scope, implementation, result, and cleanup.

Task

  1. Create or inspect a suitable inventory.
  2. Prove target scope with --list-hosts.
  3. Create or adapt a playbook.
  4. Use a suitable ansible.builtin module.
  5. Run syntax check, check mode, real run, and a second run.
  6. Document play recap, relevant output, and a short assessment.

Expected Result

  • The playbook is syntactically valid.
  • Target hosts are clear.
  • The second run reports no unnecessary changes.
  • Risks and limits are documented.
07 / 24

Exercise 3: templates

Deep Dive and Submission Example for Exercise 3: templates

A complete treatment of Exercise 3: templates 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 Exercise 3: templates

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 Exercise 3: templates

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, Exercise 3: templates 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 Exercise 3: templates

This section is not just a definition. In the workshop, Exercise 3: templates 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 Exercise 3: templates

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 Exercise 3: templates

  • 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 Exercise 3: templates

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 Exercise 3: templates

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.

Goal

Apply templates in a small safe lab and document scope, implementation, result, and cleanup.

Task

  1. Create or inspect a suitable inventory.
  2. Prove target scope with --list-hosts.
  3. Create or adapt a playbook.
  4. Use a suitable ansible.builtin module.
  5. Run syntax check, check mode, real run, and a second run.
  6. Document play recap, relevant output, and a short assessment.

Expected Result

  • The playbook is syntactically valid.
  • Target hosts are clear.
  • The second run reports no unnecessary changes.
  • Risks and limits are documented.
08 / 24

Exercise 4: roles

Deep Dive and Submission Example for Exercise 4: roles

A complete treatment of Exercise 4: 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 Exercise 4: 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 Exercise 4: 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, Exercise 4: 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 Exercise 4: roles

This section is not just a definition. In the workshop, Exercise 4: 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 Exercise 4: 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 Exercise 4: 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 Exercise 4: 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 Exercise 4: 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.

Goal

Apply roles in a small safe lab and document scope, implementation, result, and cleanup.

Task

  1. Create or inspect a suitable inventory.
  2. Prove target scope with --list-hosts.
  3. Create or adapt a playbook.
  4. Use a suitable ansible.builtin module.
  5. Run syntax check, check mode, real run, and a second run.
  6. Document play recap, relevant output, and a short assessment.

Expected Result

  • The playbook is syntactically valid.
  • Target hosts are clear.
  • The second run reports no unnecessary changes.
  • Risks and limits are documented.
09 / 24

Exercise 5: includes

Deep Dive and Submission Example for Exercise 5: includes

A complete treatment of Exercise 5: includes 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 Exercise 5: includes

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 Exercise 5: includes

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, Exercise 5: includes 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 Exercise 5: includes

This section is not just a definition. In the workshop, Exercise 5: includes 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 Exercise 5: includes

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 Exercise 5: includes

  • 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 Exercise 5: includes

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 Exercise 5: includes

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.

Goal

Apply includes in a small safe lab and document scope, implementation, result, and cleanup.

Task

  1. Create or inspect a suitable inventory.
  2. Prove target scope with --list-hosts.
  3. Create or adapt a playbook.
  4. Use a suitable ansible.builtin module.
  5. Run syntax check, check mode, real run, and a second run.
  6. Document play recap, relevant output, and a short assessment.

Expected Result

  • The playbook is syntactically valid.
  • Target hosts are clear.
  • The second run reports no unnecessary changes.
  • Risks and limits are documented.
10 / 24

Exercise 6: imports

Deep Dive and Submission Example for Exercise 6: imports

A complete treatment of Exercise 6: imports 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 Exercise 6: imports

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 Exercise 6: imports

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, Exercise 6: imports 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 Exercise 6: imports

This section is not just a definition. In the workshop, Exercise 6: imports 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 Exercise 6: imports

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 Exercise 6: imports

  • 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 Exercise 6: imports

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 Exercise 6: imports

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.

Goal

Apply imports in a small safe lab and document scope, implementation, result, and cleanup.

Task

  1. Create or inspect a suitable inventory.
  2. Prove target scope with --list-hosts.
  3. Create or adapt a playbook.
  4. Use a suitable ansible.builtin module.
  5. Run syntax check, check mode, real run, and a second run.
  6. Document play recap, relevant output, and a short assessment.

Expected Result

  • The playbook is syntactically valid.
  • Target hosts are clear.
  • The second run reports no unnecessary changes.
  • Risks and limits are documented.
11 / 24

Exercise 7: blocks

Deep Dive and Submission Example for Exercise 7: blocks

A complete treatment of Exercise 7: blocks 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 Exercise 7: blocks

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 Exercise 7: blocks

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, Exercise 7: blocks 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 Exercise 7: blocks

This section is not just a definition. In the workshop, Exercise 7: blocks 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 Exercise 7: blocks

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 Exercise 7: blocks

  • 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 Exercise 7: blocks

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 Exercise 7: blocks

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.

Goal

Apply blocks in a small safe lab and document scope, implementation, result, and cleanup.

Task

  1. Create or inspect a suitable inventory.
  2. Prove target scope with --list-hosts.
  3. Create or adapt a playbook.
  4. Use a suitable ansible.builtin module.
  5. Run syntax check, check mode, real run, and a second run.
  6. Document play recap, relevant output, and a short assessment.

Expected Result

  • The playbook is syntactically valid.
  • Target hosts are clear.
  • The second run reports no unnecessary changes.
  • Risks and limits are documented.
12 / 24

Exercise 8: rescue

Deep Dive and Submission Example for Exercise 8: rescue

A complete treatment of Exercise 8: rescue 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 Exercise 8: rescue

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 Exercise 8: rescue

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, Exercise 8: rescue 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 Exercise 8: rescue

This section is not just a definition. In the workshop, Exercise 8: rescue 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 Exercise 8: rescue

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 Exercise 8: rescue

  • 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 Exercise 8: rescue

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 Exercise 8: rescue

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.

Goal

Apply rescue in a small safe lab and document scope, implementation, result, and cleanup.

Task

  1. Create or inspect a suitable inventory.
  2. Prove target scope with --list-hosts.
  3. Create or adapt a playbook.
  4. Use a suitable ansible.builtin module.
  5. Run syntax check, check mode, real run, and a second run.
  6. Document play recap, relevant output, and a short assessment.

Expected Result

  • The playbook is syntactically valid.
  • Target hosts are clear.
  • The second run reports no unnecessary changes.
  • Risks and limits are documented.
13 / 24

6. Part B: Model Solutions

Deep Dive and Submission Example for Part B: Model Solutions

A complete treatment of Part B: Model Solutions 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 Part B: Model Solutions

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 Part B: Model Solutions

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, Part B: Model Solutions 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 Part B: Model Solutions

This section is not just a definition. In the workshop, Part B: Model Solutions 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 Part B: Model Solutions

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 Part B: Model Solutions

  • 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 Part B: Model Solutions

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 Part B: Model Solutions

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.

14 / 24

Model Solution 1: variable precedence

Deep Dive and Submission Example for Model Solution 1: variable precedence

A complete treatment of Model Solution 1: variable precedence 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 Model Solution 1: variable precedence

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 Model Solution 1: variable precedence

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, Model Solution 1: variable precedence 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 Model Solution 1: variable precedence

This section is not just a definition. In the workshop, Model Solution 1: variable precedence 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 Model Solution 1: variable precedence

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 Model Solution 1: variable precedence

  • 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 Model Solution 1: variable precedence

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 Model Solution 1: variable precedence

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.

A good solution proves scope first:

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

Then syntax and preview are checked:

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

The real run is compared with a second run. Deviations are acceptable only when technically explained. Secrets are not printed and not stored in Git.

15 / 24

Model Solution 2: facts

Deep Dive and Submission Example for Model Solution 2: facts

A complete treatment of Model Solution 2: facts 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 Model Solution 2: facts

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 Model Solution 2: facts

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, Model Solution 2: facts 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 Model Solution 2: facts

This section is not just a definition. In the workshop, Model Solution 2: facts 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 Model Solution 2: facts

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 Model Solution 2: facts

  • 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 Model Solution 2: facts

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 Model Solution 2: facts

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.

A good solution proves scope first:

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

Then syntax and preview are checked:

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

The real run is compared with a second run. Deviations are acceptable only when technically explained. Secrets are not printed and not stored in Git.

16 / 24

Model Solution 3: templates

Deep Dive and Submission Example for Model Solution 3: templates

A complete treatment of Model Solution 3: templates 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 Model Solution 3: templates

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 Model Solution 3: templates

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, Model Solution 3: templates 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 Model Solution 3: templates

This section is not just a definition. In the workshop, Model Solution 3: templates 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 Model Solution 3: templates

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 Model Solution 3: templates

  • 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 Model Solution 3: templates

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 Model Solution 3: templates

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.

A good solution proves scope first:

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

Then syntax and preview are checked:

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

The real run is compared with a second run. Deviations are acceptable only when technically explained. Secrets are not printed and not stored in Git.

17 / 24

Model Solution 4: roles

Deep Dive and Submission Example for Model Solution 4: roles

A complete treatment of Model Solution 4: 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 Model Solution 4: 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 Model Solution 4: 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, Model Solution 4: 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 Model Solution 4: roles

This section is not just a definition. In the workshop, Model Solution 4: 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 Model Solution 4: 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 Model Solution 4: 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 Model Solution 4: 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 Model Solution 4: 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.

A good solution proves scope first:

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

Then syntax and preview are checked:

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

The real run is compared with a second run. Deviations are acceptable only when technically explained. Secrets are not printed and not stored in Git.

18 / 24

Model Solution 5: includes

Deep Dive and Submission Example for Model Solution 5: includes

A complete treatment of Model Solution 5: includes 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 Model Solution 5: includes

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 Model Solution 5: includes

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, Model Solution 5: includes 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 Model Solution 5: includes

This section is not just a definition. In the workshop, Model Solution 5: includes 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 Model Solution 5: includes

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 Model Solution 5: includes

  • 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 Model Solution 5: includes

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 Model Solution 5: includes

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.

A good solution proves scope first:

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

Then syntax and preview are checked:

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

The real run is compared with a second run. Deviations are acceptable only when technically explained. Secrets are not printed and not stored in Git.

19 / 24

Model Solution 6: imports

Deep Dive and Submission Example for Model Solution 6: imports

A complete treatment of Model Solution 6: imports 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 Model Solution 6: imports

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 Model Solution 6: imports

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, Model Solution 6: imports 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 Model Solution 6: imports

This section is not just a definition. In the workshop, Model Solution 6: imports 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 Model Solution 6: imports

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 Model Solution 6: imports

  • 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 Model Solution 6: imports

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 Model Solution 6: imports

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.

A good solution proves scope first:

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

Then syntax and preview are checked:

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

The real run is compared with a second run. Deviations are acceptable only when technically explained. Secrets are not printed and not stored in Git.

20 / 24

Model Solution 7: blocks

Deep Dive and Submission Example for Model Solution 7: blocks

A complete treatment of Model Solution 7: blocks 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 Model Solution 7: blocks

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 Model Solution 7: blocks

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, Model Solution 7: blocks 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 Model Solution 7: blocks

This section is not just a definition. In the workshop, Model Solution 7: blocks 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 Model Solution 7: blocks

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 Model Solution 7: blocks

  • 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 Model Solution 7: blocks

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 Model Solution 7: blocks

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.

A good solution proves scope first:

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

Then syntax and preview are checked:

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

The real run is compared with a second run. Deviations are acceptable only when technically explained. Secrets are not printed and not stored in Git.

21 / 24

Model Solution 8: rescue

Deep Dive and Submission Example for Model Solution 8: rescue

A complete treatment of Model Solution 8: rescue 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 Model Solution 8: rescue

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 Model Solution 8: rescue

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, Model Solution 8: rescue 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 Model Solution 8: rescue

This section is not just a definition. In the workshop, Model Solution 8: rescue 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 Model Solution 8: rescue

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 Model Solution 8: rescue

  • 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 Model Solution 8: rescue

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 Model Solution 8: rescue

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.

A good solution proves scope first:

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

Then syntax and preview are checked:

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

The real run is compared with a second run. Deviations are acceptable only when technically explained. Secrets are not printed and not stored in Git.

22 / 24

7. Rubric

Deep Dive and Submission Example for Rubric

A complete treatment of 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 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 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, 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 Rubric

This section is not just a definition. In the workshop, 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 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 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 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 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.

Criterion Points
Scope verified 20
Module choice and idempotence 25
Check/diff/evidence 20
Security and secrets 20
Documentation and cleanup 15
23 / 24

8. Cleanup

Deep Dive and Submission Example for Cleanup

A complete treatment of Cleanup 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 Cleanup

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 Cleanup

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, Cleanup 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 Cleanup

This section is not just a definition. In the workshop, Cleanup 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 Cleanup

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 Cleanup

  • 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 Cleanup

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 Cleanup

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.

Marker files under /tmp, dummy inventories, and lab artifacts are removed or clearly marked as safe exercise artifacts.

24 / 24

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 που αναφέρονται παραπάνω.