Ansible Workshop: Fundamentals – Exercises with Solutions · Ansible

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

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

For roles or collections, the structure expands:

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

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 Fundamentals workshop. They move from explanation to implementation, validation, and model solution.

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

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

For roles or collections, the structure expands:

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

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.

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

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

For roles or collections, the structure expands:

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

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.

Verify inventory and scope before every change.
Use syntax check, check mode, and diff mode.
Justify become.
Document play recap and a second run.
Clean up lab artifacts.

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

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

For roles or collections, the structure expands:

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

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	Control node	lab file, validation, and short rationale
2	managed nodes	lab file, validation, and short rationale
3	inventory	lab file, validation, and short rationale
4	ad-hoc commands	lab file, validation, and short rationale
5	playbooks	lab file, validation, and short rationale
6	modules	lab file, validation, and short rationale
7	handlers	lab file, validation, and short rationale
8	idempotence	lab file, validation, and short rationale

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

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

For roles or collections, the structure expands:

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

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.

Exercise 1: Control node

Deep Dive and Submission Example for Exercise 1: Control node

A complete treatment of Exercise 1: Control node 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: Control node

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

For roles or collections, the structure expands:

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: Control node

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: Control node 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: Control node

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

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: Control node

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: Control node

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: Control node

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 Control node in a small safe lab and document scope, implementation, result, and cleanup.

Task

Create or inspect a suitable inventory.
Prove target scope with --list-hosts.
Create or adapt a playbook.
Use a suitable ansible.builtin module.
Run syntax check, check mode, real run, and a second run.
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.

Exercise 2: managed nodes

Deep Dive and Submission Example for Exercise 2: managed nodes

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

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

For roles or collections, the structure expands:

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: managed nodes

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: managed nodes 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: managed nodes

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

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: managed nodes

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: managed nodes

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: managed nodes

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 managed nodes in a small safe lab and document scope, implementation, result, and cleanup.

Task

Create or inspect a suitable inventory.
Prove target scope with --list-hosts.
Create or adapt a playbook.
Use a suitable ansible.builtin module.
Run syntax check, check mode, real run, and a second run.
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.

Exercise 3: inventory

Deep Dive and Submission Example for Exercise 3: inventory

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

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

Minimal Artifacts for Exercise 3: inventory

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

For roles or collections, the structure expands:

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

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

Transfer to Real Teams

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

Practical Relevance of Exercise 3: inventory

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

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

Example Flow for Exercise 3: inventory

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

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

Common Failure Modes for Exercise 3: inventory

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

Operations Note for Exercise 3: inventory

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

Goal

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

Task

Create or inspect a suitable inventory.
Prove target scope with --list-hosts.
Create or adapt a playbook.
Use a suitable ansible.builtin module.
Run syntax check, check mode, real run, and a second run.
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.

Exercise 4: ad-hoc commands

Deep Dive and Submission Example for Exercise 4: ad-hoc commands

A complete treatment of Exercise 4: ad-hoc commands 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: ad-hoc commands

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

For roles or collections, the structure expands:

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: ad-hoc commands

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: ad-hoc commands 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: ad-hoc commands

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

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: ad-hoc commands

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: ad-hoc commands

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: ad-hoc commands

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 ad-hoc commands in a small safe lab and document scope, implementation, result, and cleanup.

Task

Create or inspect a suitable inventory.
Prove target scope with --list-hosts.
Create or adapt a playbook.
Use a suitable ansible.builtin module.
Run syntax check, check mode, real run, and a second run.
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.

Exercise 5: playbooks

Deep Dive and Submission Example for Exercise 5: playbooks

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

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

For roles or collections, the structure expands:

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

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

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

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

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

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

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 playbooks in a small safe lab and document scope, implementation, result, and cleanup.

Task

Create or inspect a suitable inventory.
Prove target scope with --list-hosts.
Create or adapt a playbook.
Use a suitable ansible.builtin module.
Run syntax check, check mode, real run, and a second run.
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.

Exercise 6: modules

Deep Dive and Submission Example for Exercise 6: modules

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

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

For roles or collections, the structure expands:

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

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

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

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

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

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

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 modules in a small safe lab and document scope, implementation, result, and cleanup.

Task

Create or inspect a suitable inventory.
Prove target scope with --list-hosts.
Create or adapt a playbook.
Use a suitable ansible.builtin module.
Run syntax check, check mode, real run, and a second run.
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.

Exercise 7: handlers

Deep Dive and Submission Example for Exercise 7: handlers

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

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

For roles or collections, the structure expands:

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

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

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

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

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

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

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 handlers in a small safe lab and document scope, implementation, result, and cleanup.

Task

Create or inspect a suitable inventory.
Prove target scope with --list-hosts.
Create or adapt a playbook.
Use a suitable ansible.builtin module.
Run syntax check, check mode, real run, and a second run.
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.

Exercise 8: idempotence

Deep Dive and Submission Example for Exercise 8: idempotence

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

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

For roles or collections, the structure expands:

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

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

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

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

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

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

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 idempotence in a small safe lab and document scope, implementation, result, and cleanup.

Task

Create or inspect a suitable inventory.
Prove target scope with --list-hosts.
Create or adapt a playbook.
Use a suitable ansible.builtin module.
Run syntax check, check mode, real run, and a second run.
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.

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

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

For roles or collections, the structure expands:

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

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.

Model Solution 1: Control node

Deep Dive and Submission Example for Model Solution 1: Control node

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

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

For roles or collections, the structure expands:

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: Control node

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: Control node 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: Control node

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

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: Control node

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: Control node

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: Control node

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:

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

Then syntax and preview are checked:

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.

Model Solution 2: managed nodes

Deep Dive and Submission Example for Model Solution 2: managed nodes

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

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

For roles or collections, the structure expands:

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: managed nodes

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: managed nodes 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: managed nodes

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

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: managed nodes

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: managed nodes

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: managed nodes

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:

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

Then syntax and preview are checked:

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.

Model Solution 3: inventory

Deep Dive and Submission Example for Model Solution 3: inventory

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

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

Minimal Artifacts for Model Solution 3: inventory

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

For roles or collections, the structure expands:

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

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

Transfer to Real Teams

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

Practical Relevance of Model Solution 3: inventory

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

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

Example Flow for Model Solution 3: inventory

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

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

Common Failure Modes for Model Solution 3: inventory

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

Operations Note for Model Solution 3: inventory

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

A good solution proves scope first:

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

Then syntax and preview are checked:

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.

Model Solution 4: ad-hoc commands

Deep Dive and Submission Example for Model Solution 4: ad-hoc commands

A complete treatment of Model Solution 4: ad-hoc commands 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: ad-hoc commands

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

For roles or collections, the structure expands:

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: ad-hoc commands

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: ad-hoc commands 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: ad-hoc commands

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

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: ad-hoc commands

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: ad-hoc commands

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: ad-hoc commands

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:

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

Then syntax and preview are checked:

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.

Model Solution 5: playbooks

Deep Dive and Submission Example for Model Solution 5: playbooks

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

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

For roles or collections, the structure expands:

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

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

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

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

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

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

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:

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

Then syntax and preview are checked:

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.

Model Solution 6: modules

Deep Dive and Submission Example for Model Solution 6: modules

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

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

For roles or collections, the structure expands:

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

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

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

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

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

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

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:

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

Then syntax and preview are checked:

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.

Model Solution 7: handlers

Deep Dive and Submission Example for Model Solution 7: handlers

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

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

For roles or collections, the structure expands:

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

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

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

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

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

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

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:

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

Then syntax and preview are checked:

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.

Model Solution 8: idempotence

Deep Dive and Submission Example for Model Solution 8: idempotence

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

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

For roles or collections, the structure expands:

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

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

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

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

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

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

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:

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

Then syntax and preview are checked:

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.

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

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

For roles or collections, the structure expands:

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

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

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

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

For roles or collections, the structure expands:

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

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.