Orthevs Orthevs Fathom new horizons
Menü

Workshop-Wiki · Englisch

Ansible Workshop: Professional – 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…

Inhaltssprache · EnglischGröße · 129.2 KBexercises/03-professional-exercises-ansible-EN.md
Workshop-Beispiele als ZIP
Lernstand in der Web-App

Kapitel als gelesen markieren, Lesefortschritt sehen und Praxismodule abhaken: Diese Funktionen stehen nach Aktivierung der optionalen Web-App zur Verfügung. Der Workshop-Fortschritt ergibt sich automatisch aus den Kapiteln aller Dokumentseiten. Deine Auswahl bleibt auf diesem Gerät; es gibt kein Konto und keinen Serverabgleich. Eine Installation ist nicht erforderlich. Beim Widerruf in den Datenschutz-Einstellungen wird der Lernstand gelöscht.

Lesefortschritt0%
0%
0 / 24 Kapitel gelesen
Weitere SprachfassungDeutsch ↗Griechisch ↗

Ansible Workshop: Professional – 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 Professional 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 repository standards lab file, validation, and short rationale
2 collections lab file, validation, and short rationale
3 CI lab file, validation, and short rationale
4 ansible-lint lab file, validation, and short rationale
5 Molecule lab file, validation, and short rationale
6 dynamic inventory lab file, validation, and short rationale
7 orchestration lab file, validation, and short rationale
8 runbooks 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: repository standards

Deep Dive and Submission Example for Exercise 1: repository standards

A complete treatment of Exercise 1: repository standards 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: repository standards

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: repository standards

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: repository standards 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: repository standards

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

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: repository standards

  • 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: repository standards

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: repository standards

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 repository standards 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: collections

Deep Dive and Submission Example for Exercise 2: collections

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

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: collections

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: collections 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: collections

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

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: collections

  • 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: collections

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: collections

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 collections 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: CI

Deep Dive and Submission Example for Exercise 3: CI

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

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: CI

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: CI 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: CI

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

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: CI

  • 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: CI

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: CI

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 CI 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: ansible-lint

Deep Dive and Submission Example for Exercise 4: ansible-lint

A complete treatment of Exercise 4: ansible-lint 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: ansible-lint

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: ansible-lint

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: ansible-lint 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: ansible-lint

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

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: ansible-lint

  • 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: ansible-lint

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: ansible-lint

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 ansible-lint 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: Molecule

Deep Dive and Submission Example for Exercise 5: Molecule

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

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: Molecule

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: Molecule 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: Molecule

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

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: Molecule

  • 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: Molecule

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: Molecule

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 Molecule 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: dynamic inventory

Deep Dive and Submission Example for Exercise 6: dynamic inventory

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

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: dynamic inventory

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: dynamic inventory 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: dynamic inventory

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

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: dynamic inventory

  • 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: dynamic inventory

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: dynamic inventory

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 dynamic inventory 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: orchestration

Deep Dive and Submission Example for Exercise 7: orchestration

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

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: orchestration

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: orchestration 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: orchestration

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

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: orchestration

  • 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: orchestration

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: orchestration

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 orchestration 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: runbooks

Deep Dive and Submission Example for Exercise 8: runbooks

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

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: runbooks

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: runbooks 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: runbooks

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

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: runbooks

  • 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: runbooks

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: runbooks

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 runbooks 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: repository standards

Deep Dive and Submission Example for Model Solution 1: repository standards

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

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: repository standards

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: repository standards 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: repository standards

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

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: repository standards

  • 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: repository standards

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: repository standards

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: collections

Deep Dive and Submission Example for Model Solution 2: collections

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

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: collections

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: collections 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: collections

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

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: collections

  • 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: collections

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: collections

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: CI

Deep Dive and Submission Example for Model Solution 3: CI

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

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: CI

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: CI 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: CI

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

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: CI

  • 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: CI

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: CI

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: ansible-lint

Deep Dive and Submission Example for Model Solution 4: ansible-lint

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

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: ansible-lint

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: ansible-lint 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: ansible-lint

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

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: ansible-lint

  • 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: ansible-lint

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: ansible-lint

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: Molecule

Deep Dive and Submission Example for Model Solution 5: Molecule

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

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: Molecule

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: Molecule 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: Molecule

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

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: Molecule

  • 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: Molecule

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: Molecule

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: dynamic inventory

Deep Dive and Submission Example for Model Solution 6: dynamic inventory

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

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: dynamic inventory

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: dynamic inventory 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: dynamic inventory

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

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: dynamic inventory

  • 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: dynamic inventory

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: dynamic inventory

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: orchestration

Deep Dive and Submission Example for Model Solution 7: orchestration

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

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: orchestration

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: orchestration 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: orchestration

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

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: orchestration

  • 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: orchestration

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: orchestration

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: runbooks

Deep Dive and Submission Example for Model Solution 8: runbooks

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

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: runbooks

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: runbooks 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: runbooks

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

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: runbooks

  • 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: runbooks

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: runbooks

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 Module als durchgängiger Lernpfad.

Die Reihenfolge bleibt unverändert: von der Laborgrundstruktur über fachliche Grundlagen und Betriebsmodelle bis zum abschließenden Troubleshooting. Die technischen Verzeichnisnamen werden bewusst beibehalten.

Praxismodule

Orthevs als App

Orthevs installieren

Die Orthevs Web-App kann auf unterstützten Mobilgeräten und Desktop-Browsern installiert werden.

iPhone und iPad

Öffnen Sie Orthevs in Safari. Tippen Sie auf Teilen, dann auf ‚Zum Home-Bildschirm‘. Aktivieren Sie gegebenenfalls ‚Als Web-App öffnen‘ und tippen Sie auf ‚Hinzufügen‘.

Android

Für die Web-App öffnen Sie das Browsermenü und wählen ‚App installieren‘ oder ‚Zum Startbildschirm hinzufügen‘. Bestätigen Sie die Installation.

Desktop-Browser

Öffnen Sie das Browsermenü oder das Installationssymbol in der Adressleiste und wählen Sie ‚App installieren‘ beziehungsweise ‚Zum Dock hinzufügen‘.

Die Web-App-Installation hängt vom Browser ab. Falls kein Installationsdialog erscheint, nutzen Sie die angezeigten Schritte im Browser.