diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md
new file mode 100644
index 00000000..e5e5a1a6
--- /dev/null
+++ b/.github/pull_request_template.md
@@ -0,0 +1,13 @@
+## Goal
+What does this PR accomplish?
+
+## Changes
+- 
+
+## Testing
+How was it verified?
+
+### Checklist
+- [ ] Clear, descriptive PR title
+- [ ] Documentation updated if needed
+- [ ] No secrets or large temporary files committed
diff --git a/.github/workflows/lab3.yml b/.github/workflows/lab3.yml
new file mode 100644
index 00000000..f7aff590
--- /dev/null
+++ b/.github/workflows/lab3.yml
@@ -0,0 +1,37 @@
+name: Lab 3 CI
+
+on:
+  push:
+    branches:
+      - feature/lab3
+  workflow_dispatch:
+
+jobs:
+  hello:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout repository
+        uses: actions/checkout@v4
+
+      - name: Print basic info
+        run: |
+          echo "Triggered by: $GITHUB_EVENT_NAME"
+          echo "Branch: $GITHUB_REF"
+          echo "Commit: $GITHUB_SHA"
+          date
+          ls -la
+
+      - name: System information
+        run: |
+          echo "=== OS / Kernel ==="
+          uname -a
+          echo
+          echo "=== CPU ==="
+          nproc
+          lscpu | head -n 30 || true
+          echo
+          echo "=== Memory ==="
+          free -h || true
+          echo
+          echo "=== Disk ==="
+          df -h
diff --git a/labs/submission1.md b/labs/submission1.md
new file mode 100644
index 00000000..58a15867
--- /dev/null
+++ b/labs/submission1.md
@@ -0,0 +1,27 @@
+# Lab 1 — Submission
+
+## Task 1 — SSH Commit Signing
+
+### Benefits of signed commits
+Signed commits provide cryptographic proof that a commit was created by a trusted author and was not modified after being created. This ensures the integrity of the codebase and protects against malicious or accidental tampering with commit history. Commit signing also establishes clear authorship, which is critical in collaborative and distributed teams. In CI/CD pipelines, signed commits increase trust in automated processes by guaranteeing that only verified code is built and deployed. From a security perspective, commit signing helps prevent supply chain attacks. Overall, signed commits improve transparency, accountability, and trust in the development workflow.
+
+### Evidence
+- Screenshot showing the “Verified” badge on a signed commit in GitHub.
+- SSH-based commit signing is configured using an ed25519 SSH key. Commits are created with `git commit -S`, and GitHub successfully verifies them as signed.
+
+### Why is commit signing important in DevOps workflows?
+In DevOps workflows, commit signing is important because it ensures that only authenticated and trusted changes enter the codebase. It helps teams maintain a secure and auditable development process, especially when multiple contributors and automated systems are involved. Signed commits integrate well with CI/CD pipelines by adding an additional layer of trust before builds and deployments. This practice reduces the risk of unauthorized code changes and improves overall security posture.
+
+---
+
+## Task 2 — PR Template & Checklist
+
+### Evidence
+- Screenshot showing that the pull request description is automatically populated from `.github/pull_request_template.md`.
+- The PR template file `.github/pull_request_template.md` is located on the `main` branch of the forked repository.
+
+### How PR templates improve collaboration
+PR templates standardize the information provided by contributors, making pull requests easier and faster to review. They ensure that the purpose of the change, the list of modifications, and verification steps are always documented. Checklists reduce the chance of missing important steps such as documentation updates or security checks. This leads to more consistent reviews, better communication between team members, and higher overall code quality. As a result, PR templates streamline collaboration and reduce friction in team workflows.
+
+### Challenges
+None.
diff --git a/labs/submission2.md b/labs/submission2.md
new file mode 100644
index 00000000..01ed903f
--- /dev/null
+++ b/labs/submission2.md
@@ -0,0 +1,203 @@
+# Lab 2 Submission
+
+## Task 1 --- Git Object Model Exploration
+
+### Commands
+
+``` sh
+echo "Test content" > test.txt
+git add test.txt
+git commit -m "Add test file"
+git log --oneline -1
+git cat-file -p HEAD
+git cat-file -p edfdd8ae877cc522b0ead2e18c764afa356a252b
+git cat-file -p 2eec599a1130d2ff231309bb776d1989b97c6ab2
+```
+
+### Outputs
+
+**Commit object:**
+
+    tree edfdd8ae877cc522b0ead2e18c764afa356a252b
+    Add test file
+
+**Tree object (excerpt):**
+
+    100644 blob 2eec599a1130d2ff231309bb776d1989b97c6ab2    test.txt
+
+**Blob object:**
+
+    Test content
+
+### Explanation
+
+-   **Blob:** stores raw file content.
+-   **Tree:** directory snapshot mapping names → blobs/trees.
+-   **Commit:** metadata + pointer to root tree (repo snapshot).
+
+**Storage model:** Git stores file data as blobs, directory structure as
+trees, and commits reference trees to represent full project snapshots.
+
+
+
+
+
+
+
+
+## Task 2 — Reset and Reflog Recovery
+
+### Commands + key outputs
+
+Initial history:
+```sh
+git log --oneline -5
+c92cc02 (HEAD -> git-reset-practice) Third commit
+6b137ff Second commit
+da62d38 First commit
+````
+
+Soft reset (move HEAD back, keep index + working tree):
+
+```sh
+git reset --soft HEAD~1
+git log --oneline -5
+6b137ff (HEAD -> git-reset-practice) Second commit
+da62d38 First commit
+
+git status
+Changes to be committed:
+  modified: file.txt
+```
+
+Hard reset (move HEAD back, discard index + working tree changes):
+
+```sh
+git reset --hard HEAD~1
+git log --oneline -5
+da62d38 (HEAD -> git-reset-practice) First commit
+
+git status
+nothing to commit, working tree clean
+```
+
+Reflog + recovery:
+
+```sh
+git reflog -10
+c92cc02 HEAD@{2}: commit: Third commit
+...
+
+git reset --hard c92cc02
+git log --oneline -5
+c92cc02 (HEAD -> git-reset-practice) Third commit
+6b137ff Second commit
+da62d38 First commit
+```
+
+### Explanation
+
+* `git reset --soft`: история (HEAD) откатывается, но изменения остаются в **index (staged)** и рабочей директории.
+* `git reset --hard`: история откатывается и изменения удаляются из **index** и **working tree**.
+* `git reflog` показывает прошлые положения HEAD, поэтому можно восстановиться, сделав `git reset --hard <hash>` на нужное состояние.
+
+
+
+
+
+## Task 3 — Visualize Commit History
+
+Graph:
+```sh
+git log --oneline --graph --all --decorate
+* dae0f56 (side-branch) Side branch commit
+* d580171 (HEAD -> feature/lab2) docs: add task2
+| * c92cc02 (git-reset-practice) Third commit
+| * 6b137ff Second commit
+| * da62d38 First commit
+|/  
+* 0bb29fa docs: add task1
+* ed0929f Add test file
+````
+
+Commit messages (from the graph): `Side branch commit`, `docs: add task2`, `Third commit`, `Second commit`, `First commit`, `docs: add task1`, `Add test file`.
+
+Reflection: `--graph --all` makes it clear where branches diverge and which commits belong to each branch.
+
+
+
+
+
+
+## Task 4 — Tagging Commits
+
+Commands:
+```sh
+git tag v1.0.0
+git show --oneline --no-patch v1.0.0
+git push origin v1.0.0
+````
+
+Tag info:
+
+```
+e7e523d docs: add task3
+```
+
+Why tags matter: tags mark release points, enable versioning, and are commonly used by CI/CD pipelines and release notes.
+
+
+
+
+## Task 5 — switch vs checkout vs restore
+
+### git switch (modern branch switching)
+```sh
+git switch -c cmd-compare
+git switch -
+````
+
+Switch cleanly toggles between branches.
+
+### git checkout (legacy)
+
+```sh
+git checkout -b cmd-compare-2
+git switch -
+```
+
+Checkout can create/switch branches but is overloaded.
+
+### git restore (file operations)
+
+Working tree restore attempt:
+
+```sh
+echo "scratch" >> demo.txt
+git restore demo.txt
+```
+
+Result: failed because the file was untracked.
+
+Index restore:
+
+```sh
+echo "scratch2" >> demo.txt
+git add demo.txt
+git restore --staged demo.txt
+```
+
+### When to use each
+
+* `git switch` — switching branches (clear intent).
+* `git restore` — restoring files or index state.
+* `git checkout` — legacy multi-purpose command.
+
+
+
+
+
+## GitHub Community
+
+Starring repositories helps bookmark useful projects and signals community trust and popularity.  
+Following developers supports networking, learning from others, and professional growth.
diff --git a/labs/submission3.md b/labs/submission3.md
new file mode 100644
index 00000000..64c8d00b
--- /dev/null
+++ b/labs/submission3.md
@@ -0,0 +1,58 @@
+# Lab 3 — CI/CD (GitHub Actions)
+
+## Platform
+GitHub Actions
+
+---
+
+## Task 1 — First GitHub Actions Workflow
+
+### Workflow file
+- `.github/workflows/lab3.yml`
+
+### Evidence
+- Run link: https://github.com/vozamhcak/DevOps-Intro/actions/runs/22237239314
+
+### What triggered the run?
+- The workflow was triggered by a `push` to the `feature/lab3` branch.
+
+### Key concepts
+- **Workflow**: YAML configuration stored in `.github/workflows/`
+- **Jobs**: logical groups of steps executed on a runner
+- **Steps**: individual commands or actions inside a job
+- **Runner**: virtual machine that executes jobs (`ubuntu-latest`)
+- **Trigger**: event that starts workflow execution (`push`)
+
+### Notes / analysis
+- The workflow checks out the repository using `actions/checkout`.
+- It prints GitHub environment variables and basic system info.
+- Logs are accessible via the GitHub Actions UI (Actions → workflow run → job logs).
+
+
+
+---
+
+## Task 2 — Manual Trigger + System Information
+
+### Workflow changes
+- Added `workflow_dispatch` trigger to enable manual runs.
+- Extended workflow with a step that gathers runner system information.
+
+### Evidence (automatic run after changes)
+- Run link: https://github.com/vozamhcak/DevOps-Intro/actions/runs/22237477623
+
+### System information (excerpt from logs)
+Example data collected from runner:
+- OS: Ubuntu (GitHub-hosted runner)
+- CPU: multiple cores (nproc + lscpu output)
+- Memory: reported via `free -h`
+- Disk: reported via `df -h`
+
+### Manual vs automatic triggers
+- Automatic trigger: executed on push to `feature/lab3`.
+- Manual trigger: enabled via `workflow_dispatch` in workflow YAML.
+
+### Runner environment analysis
+- GitHub-hosted runners provide Linux-based ephemeral environments.
+- Each workflow run executes in a clean VM.
+- Useful for reproducible CI pipelines and testing.
diff --git a/labs/submission4.md b/labs/submission4.md
new file mode 100644
index 00000000..df164669
--- /dev/null
+++ b/labs/submission4.md
@@ -0,0 +1,307 @@
+# Lab 4 — OS & Networking (macOS)
+
+> Note: The original lab uses Linux/systemd tools. Since this was completed on macOS, equivalent tools were used:
+>
+> * `systemd-analyze` → `uptime`, `sysctl kern.boottime`
+> * `systemctl` → `launchctl`
+> * `free` and `/proc/meminfo` → `sysctl`, `vm_stat`, `top`
+
+---
+
+## Task 1 — Operating System Analysis
+
+### 1.1 Boot Performance Analysis
+
+**Command:** `uptime`
+
+```text
+23:24  up 16 days, 50 mins, 2 users, load averages: 3.27 5.24 6.07
+```
+
+**Command:** `sysctl -n kern.boottime`
+
+```text
+{ sec = 1770838459, usec = 678680 } Wed Feb 11 22:34:19 2026
+```
+
+**Command:** `log show --style compact --last 10m --predicate 'eventMessage CONTAINS "Previous shutdown cause"'`
+
+```text
+Timestamp               Ty Process[PID:TID]
+```
+
+**Observations:**
+
+* The system has been running for over 16 days without reboot.
+* Boot timestamp confirms last reboot on Feb 11, 2026.
+* No recent shutdown cause entries were found in logs (likely due to clean uptime and log retention).
+
+---
+
+### 1.2 Process Forensics
+
+**Top processes by CPU:**
+
+```text
+PID   PPID COMMAND          %MEM  %CPU
+48612   525 /Library/Applica  0.7  28.2
+46109     1 /System/Library/  0.8  26.6
+402       1 /System/Library/  1.0  22.8
+46110     1 /System/Library/  0.8  11.1
+34824     1 /Applications/V2  0.5   8.5
+```
+
+**Top processes by memory:**
+
+```text
+PID   PPID COMMAND          %MEM  %CPU
+47317     1 /System/Library/  3.3   8.1
+1424      1 /System/Volumes/  1.7   3.0
+402       1 /System/Library/  0.9  20.7
+47293     1 /System/Library/  0.8   0.0
+1284      1 /Applications/V2  0.8   3.8
+```
+
+**Top memory-consuming process:**
+WebKit system process (browser rendering component, sanitized).
+
+**Observations:**
+
+* CPU usage is distributed across multiple system services and applications.
+* The highest memory usage comes from a WebKit-related process, which is typical for macOS browsers.
+* No single process dominates system resources, indicating balanced load.
+
+---
+
+### 1.3 Service Dependencies (launchd equivalent)
+
+**Command:** `launchctl list | head -n 30`
+
+```text
+PID	Status	Label
+-	0	com.apple.SafariHistoryServiceAgent
+47299	-9	com.apple.progressd
+-	0	com.apple.enhancedloggingd
+46388	-9	com.apple.cloudphotod
+-	-9	com.apple.MENotificationService
+612	0	com.apple.Finder
+23878	-9	com.apple.homed
+33542	-9	com.apple.dataaccess.dataaccessd
+-	0	com.apple.quicklook
+-	0	com.apple.parentalcontrols.check
+797	0	com.apple.mediaremoteagent
+645	0	com.apple.FontWorker
+27792	-9	com.apple.bird
+-	0	com.apple.amp.mediasharingd
+-	-9	com.apple.knowledgeconstructiond
+33150	-9	com.apple.inputanalyticsd
+-	0	com.apple.familycontrols.useragent
+-	0	com.apple.AssetCache.agent
+46319	0	com.apple.GameController.gamecontrolleragentd
+-	0	com.apple.universalaccessAuthWarn
+-	0	com.apple.UserPictureSyncAgent
+694	0	com.apple.nsurlsessiond
+42366	-9	com.apple.devicecheckd
+-	0	com.apple.syncservices.uihandler
+33270	-9	com.apple.iconservices.iconservicesagent
+-	-9	com.apple.diagnosticextensionsd
+-	-9	com.apple.intelligenceplatformd
+27438	-9	com.apple.SafariBookmarksSyncAgent
+-	0	com.apple.cmio.LaunchCMIOUserExtensionsAgent
+```
+
+**Command:** `launchctl print system | head -n 80`
+
+```text
+system = {
+	type = system
+	handle = 0
+	active count = 986
+	service count = 423
+	active service count = 159
+	maximum allowed shutdown time = 71 s
+	...
+}
+```
+
+**Observations:**
+
+* macOS uses `launchd` instead of `systemd` for service management.
+* Over 400 registered services exist, with ~150 active at runtime.
+* Many Apple background services (iCloud, media, analytics) are visible.
+* Some services show negative exit status, which is normal for inactive or on-demand daemons.
+
+---
+
+### 1.4 User Sessions
+
+**Command:** `who -a`
+
+```text
+system boot  Feb 11 22:34 
+vozamhcak    console      Feb 11 22:34 
+vozamhcak    ttys000      Feb 20 21:58 
+vozamhcak    ttys001      Feb 15 13:06
+```
+
+**Command:** `last -n 5`
+
+```text
+vozamhcak  ttys000  Fri Feb 20 21:58   still logged in
+vozamhcak  ttys000  Tue Feb 17 23:32 - 23:32
+vozamhcak  ttys001  Sun Feb 15 13:06 - 13:06
+vozamhcak  ttys000  Sun Feb 15 10:35 - 10:35
+vozamhcak  ttys000  Fri Feb 13 16:06 - 16:06
+```
+
+**Observations:**
+
+* Single user environment with multiple terminal sessions.
+* Long-running console session aligns with system uptime.
+* No suspicious login activity detected.
+
+---
+
+### 1.5 Memory Analysis
+
+**Total RAM:**
+
+```text
+sysctl -n hw.memsize
+8589934592
+```
+
+**Swap usage:**
+
+```text
+vm.swapusage: total = 1024.00M  used = 407.50M  free = 616.50M  (encrypted)
+```
+
+**vm_stat snapshot (abridged):**
+
+```text
+Pages free: 4144
+Pages active: 85455
+Pages inactive: 84543
+Pages wired down: 99066
+Pages stored in compressor: 593356
+Swapouts: 37088
+```
+
+**top memory summary:**
+
+```text
+PhysMem: 7525M used (1496M wired, 3353M compressor), 91M unused.
+```
+
+**Observations:**
+
+* System has 8 GB RAM total.
+* Majority of memory is actively used, with heavy reliance on compression.
+* Swap usage (~400 MB) indicates moderate memory pressure but not critical.
+* macOS memory compression is actively reducing swap overhead.
+
+---
+
+## Summary (Task 1)
+
+* System shows long stable uptime (16+ days).
+* Resource usage is balanced without runaway processes.
+* Top memory consumer is a WebKit rendering process.
+* Memory pressure is moderate but managed via compression.
+* macOS service model differs from Linux but provides similar observability via `launchctl`.
+
+
+
+
+---
+
+## Task 2 — Networking Analysis
+
+### 2.1 Network Path Tracing
+
+**Command:** `traceroute github.com`
+
+```text
+traceroute to github.com (140.82.121.x), 64 hops max, 40 byte packets
+1  * * *
+2  * * *
+3  * * *
+```
+
+**Observation:**
+Traceroute did not return visible hops. This is common on modern networks where ICMP or UDP traceroute probes are blocked by routers, firewalls, or NAT layers (especially on macOS and VPN environments).
+
+---
+
+**Command:** `dig github.com`
+
+```text
+;; ANSWER SECTION:
+github.com.        1    IN    A    198.18.0.xxx
+```
+
+**Observations:**
+
+* DNS resolution succeeded with status NOERROR.
+* Response was returned almost instantly (~1 ms).
+* DNS server used: 1.1.1.1 (Cloudflare).
+* The returned IP appears to be NAT or filtered environment (non-public range).
+
+---
+
+### 2.2 Packet Capture (DNS)
+
+**Command:** `sudo tcpdump -c 5 -i any 'port 53' -nn`
+
+```text
+0 packets captured
+```
+
+**Observations:**
+
+* No packets were captured during the short window.
+* This is expected in cases where:
+
+  * DNS caching is active
+  * macOS network privacy features are enabled
+  * DNS-over-HTTPS or system resolver abstraction is used
+* Modern macOS versions often hide DNS traffic from raw tcpdump unless running longer captures.
+
+**Example DNS query (from manual trigger):**
+
+```text
+dig google.com → A record returned successfully
+```
+
+---
+
+### 2.3 Reverse DNS Lookups
+
+**Command:** `dig -x 8.8.4.4`
+
+```text
+8.8.4.4 → dns.google
+```
+
+**Command:** `dig -x 1.1.2.2`
+
+```text
+Status: NXDOMAIN
+```
+
+**Comparison:**
+
+* 8.8.4.4 has a valid PTR record resolving to dns.google.
+* 1.1.2.2 does not have a reverse DNS entry (NXDOMAIN).
+* This demonstrates that reverse DNS is optional and depends on provider configuration.
+
+---
+
+## Summary (Task 2)
+
+* DNS resolution is fast and reliable via Cloudflare resolver.
+* Traceroute visibility is limited, likely due to firewall or NAT filtering.
+* Packet capture did not reveal DNS traffic, likely due to OS-level DNS abstraction or caching.
+* Reverse DNS results demonstrate both valid PTR resolution and NXDOMAIN scenarios.
+
diff --git a/labs/submission5.md b/labs/submission5.md
new file mode 100644
index 00000000..57027783
--- /dev/null
+++ b/labs/submission5.md
@@ -0,0 +1,248 @@
+# Lab 5 — Virtualization & System Analysis
+
+## Host System
+
+OS: macOS 26.2 (25C56)
+VirtualBox version: 7.2.6 r172322
+
+## VM Configuration
+
+RAM: 4096 MB
+CPU: 2 cores
+Disk: 25 GB
+OS: Ubuntu 24.04.4 LTS
+
+---
+
+# Operating System Information
+
+Command:
+`cat /etc/os-release`
+
+Output:
+
+```
+PRETTY_NAME="Ubuntu 24.04.4 LTS"
+NAME="Ubuntu"
+VERSION_ID="24.04"
+VERSION="24.04.4 LTS (Noble Numbat)"
+VERSION_CODENAME=noble
+ID=ubuntu
+ID_LIKE=debian
+HOME_URL="https://www.ubuntu.com/"
+SUPPORT_URL="https://help.ubuntu.com/"
+BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
+PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
+UBUNTU_CODENAME=noble
+LOGO=ubuntu-logo
+```
+
+Command:
+`uname -a`
+
+Output:
+
+```
+Linux Ubuntu24 6.17.0-14-generic #14~24.04.1-Ubuntu SMP PREEMPT_DYNAMIC Fri Jan 16 09:16:28 UTC 2026 aarch64 aarch64 aarch64 GNU/Linux
+```
+
+Command:
+`hostnamectl`
+
+Output:
+
+```
+ Static hostname: Ubuntu24
+       Icon name: computer
+      Machine ID: 6a22911ebd444d7e9b61145fed18ff16
+         Boot ID: 8276994981364b1fbe8c191de6717d2a
+Operating System: Ubuntu 24.04.4 LTS
+          Kernel: Linux 6.17.0-14-generic
+    Architecture: arm64
+```
+
+---
+
+# CPU Information
+
+Command:
+`lscpu`
+
+Output:
+
+```
+Architecture:                aarch64
+CPU op-mode(s):              64-bit
+Byte Order:                  Little Endian
+CPU(s):                      2
+On-line CPU(s) list:         0,1
+Vendor ID:                   Apple
+Model name:                  -
+Model:                       0
+Thread(s) per core:          1
+Core(s) per cluster:         2
+Cluster(s):                  1
+Stepping:                    0x0
+BogoMIPS:                    48.00
+Flags:                       fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
+NUMA node(s):                1
+NUMA node0 CPU(s):           0,1
+```
+
+Command:
+`nproc`
+
+Output:
+
+```
+2
+```
+
+---
+
+# Memory Information
+
+Command:
+`free -h`
+
+Output:
+
+```
+               total        used        free      shared  buff/cache   available
+Mem:           3.8Gi       999Mi       1.4Gi        33Mi       1.6Gi       2.8Gi
+Swap:             0B          0B          0B
+```
+
+Command:
+`cat /proc/meminfo | head`
+
+Output:
+
+```
+MemTotal:        3987172 kB
+MemFree:         1494964 kB
+MemAvailable:    2963468 kB
+Buffers:           38832 kB
+Cached:          1567756 kB
+SwapCached:            0 kB
+Active:          1861572 kB
+Inactive:         354828 kB
+Active(anon):     644208 kB
+Inactive(anon):        0 kB
+```
+
+---
+
+# Network Configuration
+
+Command:
+`ip a`
+
+Output:
+
+```
+1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536
+    inet 127.0.0.1/8 scope host lo
+
+2: enp0s8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
+    link/ether 08:00:27:89:aa:1c
+    inet 10.0.2.15/24 brd 10.0.2.255 scope global dynamic enp0s8
+    inet6 fe80::a00:27ff:fe89:aa1c/64 scope link
+```
+
+Command:
+`ip route`
+
+Output:
+
+```
+default via 10.0.2.2 dev enp0s8 proto dhcp src 10.0.2.15 metric 100
+10.0.2.0/24 dev enp0s8 proto kernel scope link src 10.0.2.15 metric 100
+```
+
+Command:
+`cat /etc/resolv.conf`
+
+Output:
+
+```
+nameserver 127.0.0.53
+options edns0 trust-ad
+search .
+```
+
+---
+
+# Storage Information
+
+Command:
+`lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS`
+
+Output:
+
+```
+NAME     SIZE TYPE FSTYPE   MOUNTPOINTS
+loop0   68.9M loop squashfs /snap/core22/2293
+loop1  236.1M loop squashfs /snap/firefox/7764
+loop2      4K loop squashfs /snap/bare/5
+loop3     10M loop squashfs /snap/snap-store/1271
+loop4    503M loop squashfs /snap/gnome-42-2204/245
+loop5   91.7M loop squashfs /snap/gtk-common-themes/1535
+loop6   41.6M loop squashfs /snap/snapd/25939
+loop7    556K loop squashfs /snap/snapd-desktop-integration/346
+sda       25G disk
+├─sda1     1G part vfat     /boot/efi
+└─sda2  23.9G part ext4     /
+sr0     1024M rom
+```
+
+Command:
+`df -hT`
+
+Output:
+
+```
+Filesystem     Type      Size  Used Avail Use% Mounted on
+tmpfs          tmpfs     390M  1.6M  388M   1% /run
+/dev/sda2      ext4       24G  5.4G   17G  25% /
+tmpfs          tmpfs     2.0G     0  2.0G   0% /dev/shm
+/dev/sda1      vfat      1.1G  6.4M  1.1G   1% /boot/efi
+```
+
+---
+
+# Virtualization Detection
+
+Command:
+`systemd-detect-virt`
+
+Output:
+
+```
+none
+```
+
+Command:
+`lscpu | grep Hypervisor`
+
+Output:
+
+```
+(no hypervisor field detected)
+```
+
+Command:
+`dmesg | grep -i hypervisor | head`
+
+Output:
+
+```
+dmesg: read kernel buffer failed: Operation not permitted
+```
+
+---
+
+# Reflection
+
+Most useful tools: `lscpu`, `free`, `ip`, `lsblk`, and `df` because they provide clear information about CPU configuration, memory usage, network interfaces, and storage layout in a single command.
+
diff --git a/labs/submission6.md b/labs/submission6.md
new file mode 100644
index 00000000..0534c065
--- /dev/null
+++ b/labs/submission6.md
@@ -0,0 +1,212 @@
+# Lab 6 — Container Fundamentals with Docker
+
+## Task 1 — Container Lifecycle & Image Management
+
+### docker ps -a
+
+```
+CONTAINER ID   IMAGE     COMMAND   CREATED   STATUS    PORTS     NAMES
+```
+
+### docker images ubuntu
+
+```
+IMAGE           ID             DISK USAGE   CONTENT SIZE
+ubuntu:latest   d1e2e92c075e        141MB         30.8MB
+```
+
+### OS Version inside container
+
+```
+PRETTY_NAME="Ubuntu 24.04.4 LTS"
+NAME="Ubuntu"
+VERSION_ID="24.04"
+VERSION="24.04.4 LTS (Noble Numbat)"
+```
+
+### Running processes
+
+```
+USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
+root         1  0.0  0.0   4300  3636 pts/0    Ss   18:03   0:00 /bin/bash
+root        10  0.0  0.0   7632  3656 pts/0    R+   18:04   0:00 ps aux
+```
+
+### Exported image size
+
+```
+-rw-------  1 vozamhcak  staff    29M Mar 13 21:04 ubuntu_image.tar
+```
+
+### Error when trying to remove image
+
+```
+Error response from daemon: conflict: unable to delete ubuntu:latest (must be forced) - container 8a2921a549bf is using its referenced image d1e2e92c075e
+```
+
+### Analysis
+
+Docker does not allow deleting an image if a container created from that image still exists. The container depends on the image layers to run, so Docker prevents removal to avoid breaking the container. After deleting the container, the image can be removed successfully.
+
+### What is inside the exported tar file?
+
+The tar archive contains the Docker image layers, metadata, configuration files, and manifest information required to reconstruct the image later using `docker load`.
+
+---
+
+# Task 2 — Custom Image Creation & Analysis
+
+### Default Nginx page
+
+```
+Welcome to nginx!
+```
+
+### Custom HTML content
+
+```html
+<html>
+<head>
+<title>The best</title>
+</head>
+<body>
+<h1>website</h1>
+</body>
+</html>
+```
+
+### Verification with curl
+
+```
+<html>
+<head>
+<title>The best</title>
+</head>
+<body>
+<h1>website</h1>
+</body>
+</html>
+```
+
+### docker diff output
+
+```
+C /run
+C /run/nginx.pid
+C /etc
+C /etc/nginx
+C /etc/nginx/conf.d
+C /etc/nginx/conf.d/default.conf
+```
+
+### Analysis of docker diff
+
+* `C` means the file or directory was **changed**.
+* These changes show runtime modifications made by Nginx when the container started.
+
+### docker commit vs Dockerfile
+
+**Advantages of docker commit**
+
+* Quick and simple way to create a new image from a running container.
+* Useful for experimentation or debugging.
+
+**Disadvantages**
+
+* Not reproducible.
+* Hard to track changes.
+* Not suitable for production workflows.
+
+**Dockerfile advantages**
+
+* Reproducible builds
+* Version control
+* Clear build instructions
+
+---
+
+# Task 3 — Container Networking & Service Discovery
+
+### Ping between containers
+
+```
+PING container2 (172.18.0.3)
+3 packets transmitted, 3 packets received, 0% packet loss
+```
+
+### Network inspect (important part)
+
+```
+container1 → 172.18.0.2
+container2 → 172.18.0.3
+```
+
+### DNS resolution
+
+```
+Name: container2
+Address: 172.18.0.3
+```
+
+### Analysis
+
+Docker provides an internal DNS server for user-defined networks. This allows containers to communicate with each other using container names instead of IP addresses.
+
+### Advantages of user-defined bridge networks
+
+* Automatic DNS resolution
+* Better isolation between applications
+* Easier service discovery
+* Improved network management
+
+---
+
+# Task 4 — Data Persistence with Volumes
+
+### Custom HTML
+
+```html
+<html><body><h1>Persistent Data</h1></body></html>
+```
+
+### curl output before container removal
+
+```
+<html><body><h1>Persistent Data</h1></body></html>
+```
+
+### curl output after container recreation
+
+```
+<html><body><h1>Persistent Data</h1></body></html>
+```
+
+### Volume inspection
+
+```
+Mountpoint: /var/lib/docker/volumes/app_data/_data
+Driver: local
+```
+
+### Analysis
+
+Volumes store data outside the container filesystem. This allows data to persist even if containers are removed and recreated.
+
+### Volumes vs Bind Mounts vs Container Storage
+
+**Volumes**
+
+* Managed by Docker
+* Best performance
+* Recommended for persistent data
+
+**Bind mounts**
+
+* Map directories from the host system
+* Useful during development
+
+**Container storage**
+
+* Stored inside the container layer
+* Data is lost when the container is removed
+
diff --git a/labs/submission7.md b/labs/submission7.md
new file mode 100644
index 00000000..5dfe4976
--- /dev/null
+++ b/labs/submission7.md
@@ -0,0 +1,233 @@
+# Lab 7 — GitOps Fundamentals
+
+## Task 1 — Git State Reconciliation
+
+### 1.1 Initial State
+
+**desired-state.txt**
+```
+
+version: 1.0
+app: myapp
+replicas: 3
+
+```
+
+**current-state.txt**
+```
+
+version: 1.0
+app: myapp
+replicas: 3
+
+```
+
+---
+
+### 1.3 Drift Detection and Reconciliation
+
+**Simulated drift:**
+```
+
+version: 2.0
+app: myapp
+replicas: 5
+
+```
+
+**Reconciliation output:**
+```
+
+Fri Mar 20 18:30:58 MSK 2026 - ⚠️  DRIFT DETECTED!
+Reconciling current state with desired state...
+Fri Mar 20 18:30:58 MSK 2026 - ✅ Reconciliation complete
+
+```
+
+**Diff after reconciliation:**
+```
+
+(no output — files are identical)
+
+```
+
+**Final current-state.txt:**
+```
+
+version: 1.0
+app: myapp
+replicas: 3
+
+```
+
+---
+
+### 1.4 Continuous Reconciliation (Auto-Healing)
+
+**Drift introduced:**
+```
+
+replicas: 10
+
+````
+
+**Observed behavior:**
+- The reconciliation loop detected drift automatically
+- State was restored without manual intervention
+- Demonstrates self-healing behavior
+
+---
+
+### Analysis
+
+The GitOps reconciliation loop continuously compares the **desired state** (stored in Git) with the **current state** (running system).
+
+If a difference is detected:
+1. Drift is identified
+2. System automatically applies the desired configuration
+3. State becomes consistent again
+
+This prevents configuration drift by ensuring:
+- Manual changes are overridden
+- System always converges to declared state
+- No human intervention is required
+
+---
+
+### Reflection
+
+Declarative configuration defines *what the system should look like*, not *how to achieve it*.
+
+Advantages over imperative approach:
+- Idempotency (safe to reapply multiple times)
+- Easier debugging (state is explicit)
+- Version control via Git
+- Enables automation and rollback
+
+---
+
+## Task 2 — GitOps Health Monitoring
+
+### 2.1 healthcheck.sh
+
+```bash
+#!/bin/bash
+# healthcheck.sh - Monitor GitOps sync health
+
+DESIRED_MD5=$(md5 -q desired-state.txt)
+CURRENT_MD5=$(md5 -q current-state.txt)
+
+if [ "$DESIRED_MD5" != "$CURRENT_MD5" ]; then
+    echo "$(date) - ❌ CRITICAL: State mismatch detected!" | tee -a health.log
+    echo "  Desired MD5: $DESIRED_MD5" | tee -a health.log
+    echo "  Current MD5: $CURRENT_MD5" | tee -a health.log
+else
+    echo "$(date) - ✅ OK: States synchronized" | tee -a health.log
+fi
+````
+
+---
+
+### 2.2 Health Monitoring Results
+
+**Mismatch detected:**
+
+```
+Fri Mar 20 18:32:33 MSK 2026 - ❌ CRITICAL: State mismatch detected!
+  Desired MD5: a15a1a4f965ecd8f9e23a33a6b543155
+  Current MD5: 86c1e4f2cba0e303f72049ccbb3141bf
+```
+
+**After additional drift:**
+
+```
+Fri Mar 20 18:32:38 MSK 2026 - ❌ CRITICAL: State mismatch detected!
+  Desired MD5: a15a1a4f965ecd8f9e23a33a6b543155
+  Current MD5: 7a7e95e8ec1e6e1833160b5f21f09692
+```
+
+**After reconciliation:**
+
+```
+Fri Mar 20 18:32:43 MSK 2026 - ✅ OK: States synchronized
+```
+
+---
+
+### 2.3 Continuous Monitoring (monitor.sh)
+
+**Output excerpt:**
+
+```
+--- Check #1 ---
+❌ CRITICAL: State mismatch detected
+⚠️ DRIFT DETECTED → reconciliation triggered
+
+--- Check #2+ ---
+✅ OK: States synchronized
+```
+
+**Observation:**
+
+* First iteration detects drift
+* System automatically fixes it
+* All subsequent checks remain healthy
+
+---
+
+### Complete health.log
+
+```
+Fri Mar 20 18:32:33 MSK 2026 - ❌ CRITICAL: State mismatch detected!
+  Desired MD5: a15a1a4f965ecd8f9e23a33a6b543155
+  Current MD5: 86c1e4f2cba0e303f72049ccbb3141bf
+Fri Mar 20 18:32:38 MSK 2026 - ❌ CRITICAL: State mismatch detected!
+  Desired MD5: a15a1a4f965ecd8f9e23a33a6b543155
+  Current MD5: 7a7e95e8ec1e6e1833160b5f21f09692
+Fri Mar 20 18:32:43 MSK 2026 - ✅ OK: States synchronized
+```
+
+---
+
+### Analysis
+
+MD5 checksums provide a fast way to detect changes in configuration files.
+
+Instead of comparing line-by-line:
+
+* Each file is reduced to a hash
+* Any change results in a different hash
+* Enables efficient monitoring at scale
+
+---
+
+### Comparison with ArgoCD
+
+This implementation mirrors GitOps tools like ArgoCD:
+
+| This Lab          | ArgoCD Equivalent    |
+| ----------------- | -------------------- |
+| desired-state.txt | Git repository       |
+| current-state.txt | Kubernetes cluster   |
+| reconcile.sh      | Sync loop            |
+| healthcheck.sh    | Sync status / health |
+| MD5 comparison    | Diffing manifests    |
+
+ArgoCD continuously:
+
+* Detects drift
+* Shows "OutOfSync" status
+* Automatically or manually syncs state
+
+---
+
+## Conclusion
+
+This lab demonstrates core GitOps principles:
+
+* Git as single source of truth
+* Continuous reconciliation
+* Automated self-healing
+* Health monitoring via checksums
+
+The system ensures consistency, reliability, and automation — key properties of modern infrastructure management.
diff --git a/labs/submission8.md b/labs/submission8.md
new file mode 100644
index 00000000..35ca130d
--- /dev/null
+++ b/labs/submission8.md
@@ -0,0 +1,122 @@
+# Lab 8 — Site Reliability Engineering (SRE)
+
+## Task 1 — Key Metrics for SRE and System Analysis
+
+### System resource monitoring
+
+I ran the required commands on my local machine (macOS) and checked CPU, memory, disk, and I/O activity.
+
+#### Top 3 CPU-consuming applications
+
+1. `com.apple.WebKit.WebContent` — `99.1%`
+2. `WindowServer` — `16.3%`
+3. `mapssyncd` — `6.8%`
+
+```bash
+ps -axo pid,ppid,%cpu,%mem,command | sort -nrk3 | head -n 10
+````
+
+```text
+ 1687     1  99.1  7.6 /System/Library/Frameworks/WebKit.framework/.../com.apple.WebKit.WebContent
+  401     1  16.3  0.9 /System/Library/PrivateFrameworks/SkyLight.framework/Resources/WindowServer -daemon
+ 3099     1   6.8  0.1 /System/Library/PrivateFrameworks/MapsSync.framework/mapssyncd
+```
+
+#### Top 3 memory-consuming applications
+
+1. `com.apple.WebKit.WebContent` — `7.7%`
+2. `AppleSpell` — `2.4%`
+3. `com.apple.WebKit.WebContent` — `2.3%`
+
+```bash
+ps -axo pid,ppid,%mem,%cpu,command | sort -nrk3 | head -n 10
+```
+
+```text
+ 1687     1  7.7   5.7 /System/Library/Frameworks/WebKit.framework/.../com.apple.WebKit.WebContent
+ 1316     1  2.4   0.0 /System/Library/Services/AppleSpell.service/Contents/MacOS/AppleSpell
+ 1761     1  2.3   6.5 /System/Library/Frameworks/WebKit.framework/.../com.apple.WebKit.WebContent
+```
+
+#### I/O usage
+
+```bash
+iostat -w 1 -c 5
+```
+
+```text
+              disk0       cpu    load average
+    KB/t  tps  MB/s  us sy id   1m   5m   15m
+   21.85 1180 25.18  21  9 71  2.20 9.68 8.37
+    4.89   99  0.47   7  3 90  2.20 9.68 8.37
+    4.98   65  0.31   7  3 89  2.26 9.57 8.34
+    4.95  143  0.69   9  4 86  2.26 9.57 8.34
+   23.70  282  6.52   8  4 88  2.26 9.57 8.34
+```
+
+From the `iostat` output, the system had short bursts of disk activity, but overall it did not look heavily I/O-bound.
+
+---
+
+### Disk space management
+
+#### Disk usage
+
+```bash
+df -h
+```
+
+```text
+Filesystem        Size    Used   Avail Capacity Mounted on
+/dev/disk3s1s1   228Gi    12Gi    75Gi    14%   /
+/dev/disk3s5     228Gi   132Gi    75Gi    64%   /System/Volumes/Data
+```
+
+#### Largest directories in `/var`
+
+```bash
+du -sh /private/var/* 2>/dev/null | sort -hr | head -n 10
+```
+
+```text
+2.2G	/private/var/db
+2.0G	/private/var/vm
+1.4G	/private/var/folders
+93M	/private/var/log
+```
+
+#### Top 3 largest files in `/var`
+
+```bash
+find /private/var -type f -exec du -h {} + 2>/dev/null | sort -hr | head -n 3
+```
+
+```text
+2.0G	/private/var/vm/sleepimage
+158M	/private/var/db/uuidtext/dsc/0B32AEB647383BEFA00A0F484C0F1230
+153M	/private/var/db/uuidtext/dsc/674DB25A34B23C568BD47D78005B2F2E
+```
+
+### Analysis
+
+The main load came from browser-related processes, especially `WebKit.WebContent`. One browser process used almost all CPU at the time of measurement, and several WebKit processes also appeared in memory-heavy processes. Disk usage looked normal overall, and the biggest space in `/private/var` was used by system files like `sleepimage` and system databases.
+
+### Reflection
+
+The easiest optimization would be to close heavy browser tabs and stop background applications that are not needed. I would also review long-running services like the Java/Kafka process because they take memory even when idle. For disk usage, I would mainly monitor logs, caches, and temporary files instead of deleting system files directly.
+
+---
+
+## Task 2 — Practical Website Monitoring Setup
+
+For website monitoring, I used **[https://example.com](https://example.com)** as the target website.
+
+I created an **API check** to verify that the site returns status code `200`. I also created a **browser check** to confirm that the page loads correctly and that the main text on the page is visible. In addition, I configured an alert rule to notify me in case of failed checks or slow response time.
+
+### Why these checks
+
+I chose these checks because they cover both basic availability and visible page content. A website may still respond with HTTP 200 even if something important on the page is broken, so browser checks are useful in addition to API checks.
+
+### Reflection
+
+This setup helps detect downtime and simple user-facing issues early. It is a basic but practical example of SRE monitoring because it focuses on availability, response behavior, and alerting.
\ No newline at end of file
diff --git a/test.txt b/test.txt
new file mode 100644
index 00000000..2eec599a
--- /dev/null
+++ b/test.txt
@@ -0,0 +1 @@
+Test content