Ansible Workshop: Intermediate – 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 Intermediate 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	variable precedence	lab file, validation, and short rationale
2	facts	lab file, validation, and short rationale
3	templates	lab file, validation, and short rationale
4	roles	lab file, validation, and short rationale
5	includes	lab file, validation, and short rationale
6	imports	lab file, validation, and short rationale
7	blocks	lab file, validation, and short rationale
8	rescue	lab file, validation, and short rationale

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

Deep Dive and Submission Example for Exercise 1: variable precedence

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

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

Minimal Artifacts for Exercise 1: variable precedence

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

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

Transfer to Real Teams

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

Practical Relevance of Exercise 1: variable precedence

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

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

Example Flow for Exercise 1: variable precedence

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

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

Review Criteria for Exercise 1: variable precedence

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

Common Failure Modes for Exercise 1: variable precedence

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

Operations Note for Exercise 1: variable precedence

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

Goal

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

Task

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

Deep Dive and Submission Example for Exercise 2: facts

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

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

Minimal Artifacts for Exercise 2: facts

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

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

Transfer to Real Teams

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

Practical Relevance of Exercise 2: facts

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

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

Example Flow for Exercise 2: facts

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

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

Review Criteria for Exercise 2: facts

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

Common Failure Modes for Exercise 2: facts

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

Operations Note for Exercise 2: facts

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

Goal

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

Task

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

Deep Dive and Submission Example for Exercise 3: templates

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

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

Minimal Artifacts for Exercise 3: templates

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

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

Transfer to Real Teams

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

Practical Relevance of Exercise 3: templates

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

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

Example Flow for Exercise 3: templates

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

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

Review Criteria for Exercise 3: templates

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

Common Failure Modes for Exercise 3: templates

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

Operations Note for Exercise 3: templates

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

Goal

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

Task

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

Deep Dive and Submission Example for Exercise 4: roles

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

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

Minimal Artifacts for Exercise 4: roles

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

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

Transfer to Real Teams

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

Practical Relevance of Exercise 4: roles

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

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

Example Flow for Exercise 4: roles

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

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

Review Criteria for Exercise 4: roles

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

Common Failure Modes for Exercise 4: roles

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

Operations Note for Exercise 4: roles

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

Goal

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

Task

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

Deep Dive and Submission Example for Exercise 5: includes

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

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

Minimal Artifacts for Exercise 5: includes

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

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

Transfer to Real Teams

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

Practical Relevance of Exercise 5: includes

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

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

Example Flow for Exercise 5: includes

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

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

Review Criteria for Exercise 5: includes

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

Common Failure Modes for Exercise 5: includes

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

Operations Note for Exercise 5: includes

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

Goal

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

Task

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

Deep Dive and Submission Example for Exercise 6: imports

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

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

Minimal Artifacts for Exercise 6: imports

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

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

Transfer to Real Teams

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

Practical Relevance of Exercise 6: imports

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

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

Example Flow for Exercise 6: imports

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

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

Review Criteria for Exercise 6: imports

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

Common Failure Modes for Exercise 6: imports

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

Operations Note for Exercise 6: imports

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

Goal

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

Task

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

Deep Dive and Submission Example for Exercise 7: blocks

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

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

Minimal Artifacts for Exercise 7: blocks

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

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

Transfer to Real Teams

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

Practical Relevance of Exercise 7: blocks

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

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

Example Flow for Exercise 7: blocks

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

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

Review Criteria for Exercise 7: blocks

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

Common Failure Modes for Exercise 7: blocks

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

Operations Note for Exercise 7: blocks

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

Goal

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

Task

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

Deep Dive and Submission Example for Exercise 8: rescue

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

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

Minimal Artifacts for Exercise 8: rescue

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

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

Transfer to Real Teams

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

Practical Relevance of Exercise 8: rescue

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

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

Example Flow for Exercise 8: rescue

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

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

Review Criteria for Exercise 8: rescue

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

Common Failure Modes for Exercise 8: rescue

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

Operations Note for Exercise 8: rescue

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

Goal

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

Task

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

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

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

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

Minimal Artifacts for Model Solution 1: variable precedence

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

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

Transfer to Real Teams

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

Practical Relevance of Model Solution 1: variable precedence

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

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

Example Flow for Model Solution 1: variable precedence

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

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

Review Criteria for Model Solution 1: variable precedence

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

Common Failure Modes for Model Solution 1: variable precedence

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

Operations Note for Model Solution 1: variable precedence

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

A good solution proves scope first:

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

Deep Dive and Submission Example for Model Solution 2: facts

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

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

Minimal Artifacts for Model Solution 2: facts

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

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

Transfer to Real Teams

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

Practical Relevance of Model Solution 2: facts

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

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

Example Flow for Model Solution 2: facts

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

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

Review Criteria for Model Solution 2: facts

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

Common Failure Modes for Model Solution 2: facts

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

Operations Note for Model Solution 2: facts

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

A good solution proves scope first:

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

Deep Dive and Submission Example for Model Solution 3: templates

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

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

Minimal Artifacts for Model Solution 3: templates

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

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

Transfer to Real Teams

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

Practical Relevance of Model Solution 3: templates

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

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

Example Flow for Model Solution 3: templates

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

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

Review Criteria for Model Solution 3: templates

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

Common Failure Modes for Model Solution 3: templates

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

Operations Note for Model Solution 3: templates

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

A good solution proves scope first:

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

Deep Dive and Submission Example for Model Solution 4: roles

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

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

Minimal Artifacts for Model Solution 4: roles

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

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

Transfer to Real Teams

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

Practical Relevance of Model Solution 4: roles

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

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

Example Flow for Model Solution 4: roles

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

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

Review Criteria for Model Solution 4: roles

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

Common Failure Modes for Model Solution 4: roles

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

Operations Note for Model Solution 4: roles

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

A good solution proves scope first:

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

Deep Dive and Submission Example for Model Solution 5: includes

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

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

Minimal Artifacts for Model Solution 5: includes

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

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

Transfer to Real Teams

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

Practical Relevance of Model Solution 5: includes

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

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

Example Flow for Model Solution 5: includes

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

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

Review Criteria for Model Solution 5: includes

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

Common Failure Modes for Model Solution 5: includes

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

Operations Note for Model Solution 5: includes

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

A good solution proves scope first:

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

Deep Dive and Submission Example for Model Solution 6: imports

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

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

Minimal Artifacts for Model Solution 6: imports

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

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

Transfer to Real Teams

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

Practical Relevance of Model Solution 6: imports

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

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

Example Flow for Model Solution 6: imports

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

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

Review Criteria for Model Solution 6: imports

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

Common Failure Modes for Model Solution 6: imports

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

Operations Note for Model Solution 6: imports

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

A good solution proves scope first:

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

Deep Dive and Submission Example for Model Solution 7: blocks

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

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

Minimal Artifacts for Model Solution 7: blocks

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

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

Transfer to Real Teams

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

Practical Relevance of Model Solution 7: blocks

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

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

Example Flow for Model Solution 7: blocks

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

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

Review Criteria for Model Solution 7: blocks

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

Common Failure Modes for Model Solution 7: blocks

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

Operations Note for Model Solution 7: blocks

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

A good solution proves scope first:

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

Deep Dive and Submission Example for Model Solution 8: rescue

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

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

Minimal Artifacts for Model Solution 8: rescue

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

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

Transfer to Real Teams

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

Practical Relevance of Model Solution 8: rescue

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

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

Example Flow for Model Solution 8: rescue

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

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

Review Criteria for Model Solution 8: rescue

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

Common Failure Modes for Model Solution 8: rescue

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

Operations Note for Model Solution 8: rescue

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

A good solution proves scope first:

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.