Workshop-Wiki · Englisch

Ubuntu Exercises: Professional (EN)

These exercises deepen Server-Baseline, cloud-init, Automatisierung, Patch Management, Monitoring, Backup und Performance. Every task requires reproducible evidence instead of description only.

Workshop-Beispiele als ZIP
Lernstand in der Web-App

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

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

Ubuntu Exercises: Professional (EN)

These exercises deepen Server-Baseline, cloud-init, Automatisierung, Patch Management, Monitoring, Backup und Performance. Every task requires reproducible evidence instead of description only.

Submission Format

  • configuration file or patch
  • test data used
  • commands executed
  • status, log or diff excerpt
  • short risk and recovery note
01 / 05

Tasks

Task 01: Release

Build or improve an Ubuntu artifact focused on Release.

Requirements:

  • do not change production systems
  • check configuration locally
  • describe operational impact
  • name an error or abuse path

Evidence:

bash
./run.sh
find work/evidence -type f -maxdepth 1 -print

Task 02: APT

Build or improve an Ubuntu artifact focused on APT.

Requirements:

  • do not change production systems
  • check configuration locally
  • describe operational impact
  • name an error or abuse path

Evidence:

bash
./run.sh
find work/evidence -type f -maxdepth 1 -print

Task 03: systemd

Build or improve an Ubuntu artifact focused on systemd.

Requirements:

  • do not change production systems
  • check configuration locally
  • describe operational impact
  • name an error or abuse path

Evidence:

bash
./run.sh
find work/evidence -type f -maxdepth 1 -print

Task 04: journald

Build or improve an Ubuntu artifact focused on journald.

Requirements:

  • do not change production systems
  • check configuration locally
  • describe operational impact
  • name an error or abuse path

Evidence:

bash
./run.sh
find work/evidence -type f -maxdepth 1 -print

Task 05: Netplan

Build or improve an Ubuntu artifact focused on Netplan.

Requirements:

  • do not change production systems
  • check configuration locally
  • describe operational impact
  • name an error or abuse path

Evidence:

bash
./run.sh
find work/evidence -type f -maxdepth 1 -print

Task 06: UFW

Build or improve an Ubuntu artifact focused on UFW.

Requirements:

  • do not change production systems
  • check configuration locally
  • describe operational impact
  • name an error or abuse path

Evidence:

bash
./run.sh
find work/evidence -type f -maxdepth 1 -print

Task 07: Storage

Build or improve an Ubuntu artifact focused on Storage.

Requirements:

  • do not change production systems
  • check configuration locally
  • describe operational impact
  • name an error or abuse path

Evidence:

bash
./run.sh
find work/evidence -type f -maxdepth 1 -print

Task 08: Backup

Build or improve an Ubuntu artifact focused on Backup.

Requirements:

  • do not change production systems
  • check configuration locally
  • describe operational impact
  • name an error or abuse path

Evidence:

bash
./run.sh
find work/evidence -type f -maxdepth 1 -print

Task 09: AppArmor

Build or improve an Ubuntu artifact focused on AppArmor.

Requirements:

  • do not change production systems
  • check configuration locally
  • describe operational impact
  • name an error or abuse path

Evidence:

bash
./run.sh
find work/evidence -type f -maxdepth 1 -print

Task 10: Incident Response

Build or improve an Ubuntu artifact focused on Incident Response.

Requirements:

  • do not change production systems
  • check configuration locally
  • describe operational impact
  • name an error or abuse path

Evidence:

bash
./run.sh
find work/evidence -type f -maxdepth 1 -print

Task 11: Release

Build or improve an Ubuntu artifact focused on Release.

Requirements:

  • do not change production systems
  • check configuration locally
  • describe operational impact
  • name an error or abuse path

Evidence:

bash
./run.sh
find work/evidence -type f -maxdepth 1 -print

Task 12: APT

Build or improve an Ubuntu artifact focused on APT.

Requirements:

  • do not change production systems
  • check configuration locally
  • describe operational impact
  • name an error or abuse path

Evidence:

bash
./run.sh
find work/evidence -type f -maxdepth 1 -print

Task 13: systemd

Build or improve an Ubuntu artifact focused on systemd.

Requirements:

  • do not change production systems
  • check configuration locally
  • describe operational impact
  • name an error or abuse path

Evidence:

bash
./run.sh
find work/evidence -type f -maxdepth 1 -print

Task 14: journald

Build or improve an Ubuntu artifact focused on journald.

Requirements:

  • do not change production systems
  • check configuration locally
  • describe operational impact
  • name an error or abuse path

Evidence:

bash
./run.sh
find work/evidence -type f -maxdepth 1 -print

Task 15: Netplan

Build or improve an Ubuntu artifact focused on Netplan.

Requirements:

  • do not change production systems
  • check configuration locally
  • describe operational impact
  • name an error or abuse path

Evidence:

bash
./run.sh
find work/evidence -type f -maxdepth 1 -print

Task 16: UFW

Build or improve an Ubuntu artifact focused on UFW.

Requirements:

  • do not change production systems
  • check configuration locally
  • describe operational impact
  • name an error or abuse path

Evidence:

bash
./run.sh
find work/evidence -type f -maxdepth 1 -print

Task 17: Storage

Build or improve an Ubuntu artifact focused on Storage.

Requirements:

  • do not change production systems
  • check configuration locally
  • describe operational impact
  • name an error or abuse path

Evidence:

bash
./run.sh
find work/evidence -type f -maxdepth 1 -print

Task 18: Backup

Build or improve an Ubuntu artifact focused on Backup.

Requirements:

  • do not change production systems
  • check configuration locally
  • describe operational impact
  • name an error or abuse path

Evidence:

bash
./run.sh
find work/evidence -type f -maxdepth 1 -print

Task 19: AppArmor

Build or improve an Ubuntu artifact focused on AppArmor.

Requirements:

  • do not change production systems
  • check configuration locally
  • describe operational impact
  • name an error or abuse path

Evidence:

bash
./run.sh
find work/evidence -type f -maxdepth 1 -print

Task 20: Incident Response

Build or improve an Ubuntu artifact focused on Incident Response.

Requirements:

  • do not change production systems
  • check configuration locally
  • describe operational impact
  • name an error or abuse path

Evidence:

bash
./run.sh
find work/evidence -type f -maxdepth 1 -print

Task 21: Release

Build or improve an Ubuntu artifact focused on Release.

Requirements:

  • do not change production systems
  • check configuration locally
  • describe operational impact
  • name an error or abuse path

Evidence:

bash
./run.sh
find work/evidence -type f -maxdepth 1 -print

Task 22: APT

Build or improve an Ubuntu artifact focused on APT.

Requirements:

  • do not change production systems
  • check configuration locally
  • describe operational impact
  • name an error or abuse path

Evidence:

bash
./run.sh
find work/evidence -type f -maxdepth 1 -print

Task 23: systemd

Build or improve an Ubuntu artifact focused on systemd.

Requirements:

  • do not change production systems
  • check configuration locally
  • describe operational impact
  • name an error or abuse path

Evidence:

bash
./run.sh
find work/evidence -type f -maxdepth 1 -print

Task 24: journald

Build or improve an Ubuntu artifact focused on journald.

Requirements:

  • do not change production systems
  • check configuration locally
  • describe operational impact
  • name an error or abuse path

Evidence:

bash
./run.sh
find work/evidence -type f -maxdepth 1 -print

Task 25: Netplan

Build or improve an Ubuntu artifact focused on Netplan.

Requirements:

  • do not change production systems
  • check configuration locally
  • describe operational impact
  • name an error or abuse path

Evidence:

bash
./run.sh
find work/evidence -type f -maxdepth 1 -print

Task 26: UFW

Build or improve an Ubuntu artifact focused on UFW.

Requirements:

  • do not change production systems
  • check configuration locally
  • describe operational impact
  • name an error or abuse path

Evidence:

bash
./run.sh
find work/evidence -type f -maxdepth 1 -print

Task 27: Storage

Build or improve an Ubuntu artifact focused on Storage.

Requirements:

  • do not change production systems
  • check configuration locally
  • describe operational impact
  • name an error or abuse path

Evidence:

bash
./run.sh
find work/evidence -type f -maxdepth 1 -print

Task 28: Backup

Build or improve an Ubuntu artifact focused on Backup.

Requirements:

  • do not change production systems
  • check configuration locally
  • describe operational impact
  • name an error or abuse path

Evidence:

bash
./run.sh
find work/evidence -type f -maxdepth 1 -print

Task 29: AppArmor

Build or improve an Ubuntu artifact focused on AppArmor.

Requirements:

  • do not change production systems
  • check configuration locally
  • describe operational impact
  • name an error or abuse path

Evidence:

bash
./run.sh
find work/evidence -type f -maxdepth 1 -print

Task 30: Incident Response

Build or improve an Ubuntu artifact focused on Incident Response.

Requirements:

  • do not change production systems
  • check configuration locally
  • describe operational impact
  • name an error or abuse path

Evidence:

bash
./run.sh
find work/evidence -type f -maxdepth 1 -print

Task 31: Release

Build or improve an Ubuntu artifact focused on Release.

Requirements:

  • do not change production systems
  • check configuration locally
  • describe operational impact
  • name an error or abuse path

Evidence:

bash
./run.sh
find work/evidence -type f -maxdepth 1 -print

Task 32: APT

Build or improve an Ubuntu artifact focused on APT.

Requirements:

  • do not change production systems
  • check configuration locally
  • describe operational impact
  • name an error or abuse path

Evidence:

bash
./run.sh
find work/evidence -type f -maxdepth 1 -print

Task 33: systemd

Build or improve an Ubuntu artifact focused on systemd.

Requirements:

  • do not change production systems
  • check configuration locally
  • describe operational impact
  • name an error or abuse path

Evidence:

bash
./run.sh
find work/evidence -type f -maxdepth 1 -print

Task 34: journald

Build or improve an Ubuntu artifact focused on journald.

Requirements:

  • do not change production systems
  • check configuration locally
  • describe operational impact
  • name an error or abuse path

Evidence:

bash
./run.sh
find work/evidence -type f -maxdepth 1 -print

Task 35: Netplan

Build or improve an Ubuntu artifact focused on Netplan.

Requirements:

  • do not change production systems
  • check configuration locally
  • describe operational impact
  • name an error or abuse path

Evidence:

bash
./run.sh
find work/evidence -type f -maxdepth 1 -print

Task 36: UFW

Build or improve an Ubuntu artifact focused on UFW.

Requirements:

  • do not change production systems
  • check configuration locally
  • describe operational impact
  • name an error or abuse path

Evidence:

bash
./run.sh
find work/evidence -type f -maxdepth 1 -print
02 / 05

Solution Notes

Use sample configuration, local evidence and clear rollback steps. Review not only syntax, but also operational impact, security exception and recovery.

03 / 05

Review Checklist for Exercises Professional

  • 01. check release and support status: Record the affected host, package, service, configuration and risk.
  • 02. evaluate package and repository risk: Record the affected host, package, service, configuration and risk.
  • 03. explain service status and logs: Record the affected host, package, service, configuration and risk.
  • 04. document network assumption: Record the affected host, package, service, configuration and risk.
  • 05. review user and sudo rule: Record the affected host, package, service, configuration and risk.
  • 06. evaluate firewall rule and exposure: Record the affected host, package, service, configuration and risk.
  • 07. describe storage and backup path: Record the affected host, package, service, configuration and risk.
  • 08. record patch and reboot window: Record the affected host, package, service, configuration and risk.
  • 09. mark security baseline: Record the affected host, package, service, configuration and risk.
  • 10. name monitoring or alert rule: Record the affected host, package, service, configuration and risk.
  • 11. record rollback or recovery path: Record the affected host, package, service, configuration and risk.
  • 12. write team rule: Record the affected host, package, service, configuration and risk.
  • 13. check release and support status: Record the affected host, package, service, configuration and risk.
  • 14. evaluate package and repository risk: Record the affected host, package, service, configuration and risk.
  • 15. explain service status and logs: Record the affected host, package, service, configuration and risk.
  • 16. document network assumption: Record the affected host, package, service, configuration and risk.
  • 17. review user and sudo rule: Record the affected host, package, service, configuration and risk.
  • 18. evaluate firewall rule and exposure: Record the affected host, package, service, configuration and risk.
  • 19. describe storage and backup path: Record the affected host, package, service, configuration and risk.
  • 20. record patch and reboot window: Record the affected host, package, service, configuration and risk.
  • 21. mark security baseline: Record the affected host, package, service, configuration and risk.
  • 22. name monitoring or alert rule: Record the affected host, package, service, configuration and risk.
  • 23. record rollback or recovery path: Record the affected host, package, service, configuration and risk.
  • 24. write team rule: Record the affected host, package, service, configuration and risk.
  • 25. check release and support status: Record the affected host, package, service, configuration and risk.
  • 26. evaluate package and repository risk: Record the affected host, package, service, configuration and risk.
  • 27. explain service status and logs: Record the affected host, package, service, configuration and risk.
  • 28. document network assumption: Record the affected host, package, service, configuration and risk.
  • 29. review user and sudo rule: Record the affected host, package, service, configuration and risk.
  • 30. evaluate firewall rule and exposure: Record the affected host, package, service, configuration and risk.
  • 31. describe storage and backup path: Record the affected host, package, service, configuration and risk.
  • 32. record patch and reboot window: Record the affected host, package, service, configuration and risk.
  • 33. mark security baseline: Record the affected host, package, service, configuration and risk.
  • 34. name monitoring or alert rule: Record the affected host, package, service, configuration and risk.
  • 35. record rollback or recovery path: Record the affected host, package, service, configuration and risk.
  • 36. write team rule: Record the affected host, package, service, configuration and risk.
  • 37. check release and support status: Record the affected host, package, service, configuration and risk.
  • 38. evaluate package and repository risk: Record the affected host, package, service, configuration and risk.
  • 39. explain service status and logs: Record the affected host, package, service, configuration and risk.
  • 40. document network assumption: Record the affected host, package, service, configuration and risk.
  • 41. review user and sudo rule: Record the affected host, package, service, configuration and risk.
  • 42. evaluate firewall rule and exposure: Record the affected host, package, service, configuration and risk.
  • 43. describe storage and backup path: Record the affected host, package, service, configuration and risk.
  • 44. record patch and reboot window: Record the affected host, package, service, configuration and risk.
  • 45. mark security baseline: Record the affected host, package, service, configuration and risk.
  • 46. name monitoring or alert rule: Record the affected host, package, service, configuration and risk.
  • 47. record rollback or recovery path: Record the affected host, package, service, configuration and risk.
  • 48. write team rule: Record the affected host, package, service, configuration and risk.
  • 49. check release and support status: Record the affected host, package, service, configuration and risk.
  • 50. evaluate package and repository risk: Record the affected host, package, service, configuration and risk.
04 / 05

Practice Appendix: Exercises Professional

This appendix is a working backlog for longer trainings, reviews and repetitions. Each task can be checked locally with sample configuration, shell commands and a Git repository.

A001. Release

  • Task: check release and support status and connect the observation explicitly to Release.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A002. APT

  • Task: evaluate package and repository risk and connect the observation explicitly to APT.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A003. systemd

  • Task: explain service status and logs and connect the observation explicitly to systemd.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A004. journald

  • Task: document network assumption and connect the observation explicitly to journald.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A005. Netplan

  • Task: review user and sudo rule and connect the observation explicitly to Netplan.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A006. UFW

  • Task: evaluate firewall rule and exposure and connect the observation explicitly to UFW.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A007. Storage

  • Task: describe storage and backup path and connect the observation explicitly to Storage.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A008. Backup

  • Task: record patch and reboot window and connect the observation explicitly to Backup.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A009. AppArmor

  • Task: mark security baseline and connect the observation explicitly to AppArmor.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A010. Incident Response

  • Task: name monitoring or alert rule and connect the observation explicitly to Incident Response.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A011. Release

  • Task: record rollback or recovery path and connect the observation explicitly to Release.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A012. APT

  • Task: write team rule and connect the observation explicitly to APT.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A013. systemd

  • Task: check release and support status and connect the observation explicitly to systemd.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A014. journald

  • Task: evaluate package and repository risk and connect the observation explicitly to journald.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A015. Netplan

  • Task: explain service status and logs and connect the observation explicitly to Netplan.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A016. UFW

  • Task: document network assumption and connect the observation explicitly to UFW.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A017. Storage

  • Task: review user and sudo rule and connect the observation explicitly to Storage.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A018. Backup

  • Task: evaluate firewall rule and exposure and connect the observation explicitly to Backup.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A019. AppArmor

  • Task: describe storage and backup path and connect the observation explicitly to AppArmor.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A020. Incident Response

  • Task: record patch and reboot window and connect the observation explicitly to Incident Response.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A021. Release

  • Task: mark security baseline and connect the observation explicitly to Release.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A022. APT

  • Task: name monitoring or alert rule and connect the observation explicitly to APT.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A023. systemd

  • Task: record rollback or recovery path and connect the observation explicitly to systemd.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A024. journald

  • Task: write team rule and connect the observation explicitly to journald.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A025. Netplan

  • Task: check release and support status and connect the observation explicitly to Netplan.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A026. UFW

  • Task: evaluate package and repository risk and connect the observation explicitly to UFW.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A027. Storage

  • Task: explain service status and logs and connect the observation explicitly to Storage.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A028. Backup

  • Task: document network assumption and connect the observation explicitly to Backup.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A029. AppArmor

  • Task: review user and sudo rule and connect the observation explicitly to AppArmor.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A030. Incident Response

  • Task: evaluate firewall rule and exposure and connect the observation explicitly to Incident Response.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A031. Release

  • Task: describe storage and backup path and connect the observation explicitly to Release.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A032. APT

  • Task: record patch and reboot window and connect the observation explicitly to APT.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A033. systemd

  • Task: mark security baseline and connect the observation explicitly to systemd.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A034. journald

  • Task: name monitoring or alert rule and connect the observation explicitly to journald.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A035. Netplan

  • Task: record rollback or recovery path and connect the observation explicitly to Netplan.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A036. UFW

  • Task: write team rule and connect the observation explicitly to UFW.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A037. Storage

  • Task: check release and support status and connect the observation explicitly to Storage.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A038. Backup

  • Task: evaluate package and repository risk and connect the observation explicitly to Backup.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A039. AppArmor

  • Task: explain service status and logs and connect the observation explicitly to AppArmor.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A040. Incident Response

  • Task: document network assumption and connect the observation explicitly to Incident Response.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A041. Release

  • Task: review user and sudo rule and connect the observation explicitly to Release.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A042. APT

  • Task: evaluate firewall rule and exposure and connect the observation explicitly to APT.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A043. systemd

  • Task: describe storage and backup path and connect the observation explicitly to systemd.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A044. journald

  • Task: record patch and reboot window and connect the observation explicitly to journald.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A045. Netplan

  • Task: mark security baseline and connect the observation explicitly to Netplan.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A046. UFW

  • Task: name monitoring or alert rule and connect the observation explicitly to UFW.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A047. Storage

  • Task: record rollback or recovery path and connect the observation explicitly to Storage.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A048. Backup

  • Task: write team rule and connect the observation explicitly to Backup.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A049. AppArmor

  • Task: check release and support status and connect the observation explicitly to AppArmor.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A050. Incident Response

  • Task: evaluate package and repository risk and connect the observation explicitly to Incident Response.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A051. Release

  • Task: explain service status and logs and connect the observation explicitly to Release.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A052. APT

  • Task: document network assumption and connect the observation explicitly to APT.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A053. systemd

  • Task: review user and sudo rule and connect the observation explicitly to systemd.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A054. journald

  • Task: evaluate firewall rule and exposure and connect the observation explicitly to journald.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A055. Netplan

  • Task: describe storage and backup path and connect the observation explicitly to Netplan.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A056. UFW

  • Task: record patch and reboot window and connect the observation explicitly to UFW.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A057. Storage

  • Task: mark security baseline and connect the observation explicitly to Storage.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A058. Backup

  • Task: name monitoring or alert rule and connect the observation explicitly to Backup.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A059. AppArmor

  • Task: record rollback or recovery path and connect the observation explicitly to AppArmor.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A060. Incident Response

  • Task: write team rule and connect the observation explicitly to Incident Response.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A061. Release

  • Task: check release and support status and connect the observation explicitly to Release.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A062. APT

  • Task: evaluate package and repository risk and connect the observation explicitly to APT.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A063. systemd

  • Task: explain service status and logs and connect the observation explicitly to systemd.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A064. journald

  • Task: document network assumption and connect the observation explicitly to journald.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A065. Netplan

  • Task: review user and sudo rule and connect the observation explicitly to Netplan.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A066. UFW

  • Task: evaluate firewall rule and exposure and connect the observation explicitly to UFW.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A067. Storage

  • Task: describe storage and backup path and connect the observation explicitly to Storage.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A068. Backup

  • Task: record patch and reboot window and connect the observation explicitly to Backup.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A069. AppArmor

  • Task: mark security baseline and connect the observation explicitly to AppArmor.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A070. Incident Response

  • Task: name monitoring or alert rule and connect the observation explicitly to Incident Response.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A071. Release

  • Task: record rollback or recovery path and connect the observation explicitly to Release.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A072. APT

  • Task: write team rule and connect the observation explicitly to APT.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A073. systemd

  • Task: check release and support status and connect the observation explicitly to systemd.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A074. journald

  • Task: evaluate package and repository risk and connect the observation explicitly to journald.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A075. Netplan

  • Task: explain service status and logs and connect the observation explicitly to Netplan.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A076. UFW

  • Task: document network assumption and connect the observation explicitly to UFW.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A077. Storage

  • Task: review user and sudo rule and connect the observation explicitly to Storage.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A078. Backup

  • Task: evaluate firewall rule and exposure and connect the observation explicitly to Backup.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A079. AppArmor

  • Task: describe storage and backup path and connect the observation explicitly to AppArmor.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A080. Incident Response

  • Task: record patch and reboot window and connect the observation explicitly to Incident Response.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A081. Release

  • Task: mark security baseline and connect the observation explicitly to Release.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A082. APT

  • Task: name monitoring or alert rule and connect the observation explicitly to APT.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A083. systemd

  • Task: record rollback or recovery path and connect the observation explicitly to systemd.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A084. journald

  • Task: write team rule and connect the observation explicitly to journald.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A085. Netplan

  • Task: check release and support status and connect the observation explicitly to Netplan.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A086. UFW

  • Task: evaluate package and repository risk and connect the observation explicitly to UFW.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A087. Storage

  • Task: explain service status and logs and connect the observation explicitly to Storage.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A088. Backup

  • Task: document network assumption and connect the observation explicitly to Backup.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A089. AppArmor

  • Task: review user and sudo rule and connect the observation explicitly to AppArmor.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.

A090. Incident Response

  • Task: evaluate firewall rule and exposure and connect the observation explicitly to Incident Response.
  • Evidence: Record at least one Ubuntu-related command, expected output and a boundary of that evidence.
  • Operations question: What would a wrong assumption cause in dev, staging, prod and CI?
  • Security question: Which accounts, services, packages, ports, logs or secrets would be critical?
  • Recovery: Describe whether rollback, restore, package downgrade, reboot, key rotation or manual correction would be needed.
05 / 05

UBU · Orthevs Academy

31 Module als durchgängiger Lernpfad.

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

Orthevs – Engineering als Grundlage für das, was als Nächstes kommt.

Orthevs als App

Orthevs installieren

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

iPhone und iPad

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

Android

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

Desktop-Browser

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

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