Orthevs Orthevs Fathom new horizons
Menu

Workshop wiki · English

Ansible Workshop: Advanced + Security – 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…

Content language · EnglishSize · 129.3 KBexercises/04-advanced-security-exercises-ansible-EN.md
Workshop examples as ZIP files
Learning progress in the web app

Mark chapters as read, view reading progress and check off practice modules after enabling the optional web app. Workshop progress is calculated from chapters across all document pages. Your choices stay on this device; there is no account or server sync. Installation is not required. Withdrawing your choice in Privacy settings deletes the progress.

Reading progress0%
0%
0 / 24 chapters read
Other language versionGerman ↗Greek ↗

Ansible Workshop: Advanced + Security – 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 Advanced + Security 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 threat modeling lab file, validation, and short rationale
2 least privilege lab file, validation, and short rationale
3 Vault IDs lab file, validation, and short rationale
4 secret flows lab file, validation, and short rationale
5 supply chain lab file, validation, and short rationale
6 no-log lab file, validation, and short rationale
7 execution environments lab file, validation, and short rationale
8 RBAC 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: threat modeling

Deep Dive and Submission Example for Exercise 1: threat modeling

A complete treatment of Exercise 1: threat modeling 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: threat modeling

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: threat modeling

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: threat modeling 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: threat modeling

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

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: threat modeling

  • 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: threat modeling

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: threat modeling

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 threat modeling 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: least privilege

Deep Dive and Submission Example for Exercise 2: least privilege

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

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: least privilege

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: least privilege 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: least privilege

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

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: least privilege

  • 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: least privilege

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: least privilege

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 least privilege 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: Vault IDs

Deep Dive and Submission Example for Exercise 3: Vault IDs

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

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: Vault IDs

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: Vault IDs 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: Vault IDs

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

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: Vault IDs

  • 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: Vault IDs

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: Vault IDs

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 Vault IDs 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: secret flows

Deep Dive and Submission Example for Exercise 4: secret flows

A complete treatment of Exercise 4: secret flows 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: secret flows

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: secret flows

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: secret flows 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: secret flows

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

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: secret flows

  • 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: secret flows

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: secret flows

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 secret flows 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: supply chain

Deep Dive and Submission Example for Exercise 5: supply chain

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

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: supply chain

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: supply chain 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: supply chain

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

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: supply chain

  • 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: supply chain

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: supply chain

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 supply chain 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: no-log

Deep Dive and Submission Example for Exercise 6: no-log

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

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: no-log

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: no-log 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: no-log

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

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: no-log

  • 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: no-log

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: no-log

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 no-log 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: execution environments

Deep Dive and Submission Example for Exercise 7: execution environments

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

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: execution environments

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: execution environments 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: execution environments

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

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: execution environments

  • 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: execution environments

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: execution environments

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 execution environments 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: RBAC

Deep Dive and Submission Example for Exercise 8: RBAC

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

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

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

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

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

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

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

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 RBAC 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: threat modeling

Deep Dive and Submission Example for Model Solution 1: threat modeling

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

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: threat modeling

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: threat modeling 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: threat modeling

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

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: threat modeling

  • 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: threat modeling

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: threat modeling

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: least privilege

Deep Dive and Submission Example for Model Solution 2: least privilege

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

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: least privilege

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: least privilege 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: least privilege

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

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: least privilege

  • 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: least privilege

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: least privilege

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: Vault IDs

Deep Dive and Submission Example for Model Solution 3: Vault IDs

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

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: Vault IDs

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: Vault IDs 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: Vault IDs

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

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: Vault IDs

  • 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: Vault IDs

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: Vault IDs

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: secret flows

Deep Dive and Submission Example for Model Solution 4: secret flows

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

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: secret flows

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: secret flows 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: secret flows

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

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: secret flows

  • 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: secret flows

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: secret flows

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: supply chain

Deep Dive and Submission Example for Model Solution 5: supply chain

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

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: supply chain

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: supply chain 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: supply chain

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

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: supply chain

  • 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: supply chain

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: supply chain

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: no-log

Deep Dive and Submission Example for Model Solution 6: no-log

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

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: no-log

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: no-log 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: no-log

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

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: no-log

  • 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: no-log

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: no-log

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: execution environments

Deep Dive and Submission Example for Model Solution 7: execution environments

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

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: execution environments

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: execution environments 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: execution environments

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

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: execution environments

  • 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: execution environments

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: execution environments

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

Deep Dive and Submission Example for Model Solution 8: RBAC

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

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

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

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

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

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

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

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

A good solution proves scope first:

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

Then syntax and preview are checked:

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

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

22 / 24

7. Rubric

Deep Dive and Submission Example for Rubric

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

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

Minimal Artifacts for Rubric

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

For roles or collections, the structure expands:

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

Grading Expectation for Rubric

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

Transfer to Real Teams

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

Practical Relevance of Rubric

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

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

Example Flow for Rubric

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

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

Review Criteria for Rubric

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

Common Failure Modes for Rubric

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

Operations Note for Rubric

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

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

8. Cleanup

Deep Dive and Submission Example for Cleanup

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

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

Minimal Artifacts for Cleanup

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

For roles or collections, the structure expands:

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

Grading Expectation for Cleanup

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

Transfer to Real Teams

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

Practical Relevance of Cleanup

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

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

Example Flow for Cleanup

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

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

Review Criteria for Cleanup

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

Common Failure Modes for Cleanup

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

Operations Note for Cleanup

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

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

24 / 24

ANS · Orthevs Academy

31 modules as one continuous learning path.

The sequence remains unchanged: from the lab skeleton through technical foundations and operating models to final troubleshooting. The technical directory names are deliberately preserved.

Practice modules

Orthevs as an app

Install Orthevs

The Orthevs web app can be installed on supported mobile devices and desktop browsers.

iPhone and iPad

Open Orthevs in Safari. Tap Share, then Add to Home Screen. Enable Open as Web App if offered, then tap Add.

Android

For the web app, open the browser menu and choose Install app or Add to Home screen. Confirm the installation.

Desktop browser

Open the browser menu or the install icon in the address bar, then choose Install app or Add to Dock.

Web app installation depends on your browser. If no install prompt appears, follow the browser steps shown above.