diff --git a/08_Vault/README.md b/08_Vault/README.md
index e68a2aa..5fd70f6 100644
--- a/08_Vault/README.md
+++ b/08_Vault/README.md
@@ -128,4 +128,138 @@ These annotations are used to configure the Vault Agent to inject secrets into t
 Use the below command to check the vault secrets from the pod volume
 ```
 kubectl exec -it vault-test-84d9dc9986-gcxfv -- sh -c "cat /vault/secrets/login && cat /vault/secrets/my-first-secret" -n vault
-```
\ No newline at end of file
+```
+
+
+
+
+----
+
+
+Wenn du Kubernetes mit Vault konfiguriert hast, ermöglichst du eine **sichere Integration zwischen deinem Kubernetes-Cluster und HashiCorp Vault**. Hier sind die wichtigsten Szenarien und Vorteile:
+
+## Hauptfunktionen
+
+### 1. **Automatische Pod-Authentifizierung**
+Pods können sich automatisch bei Vault authentifizieren, ohne dass du Credentials manuell verteilen musst. Vault nutzt Kubernetes Service Accounts zur Identitätsverifizierung.
+
+### 2. **Dynamische Secrets für Anwendungen**
+Anwendungen können zur Laufzeit Secrets von Vault abrufen, statt sie in ConfigMaps oder Kubernetes Secrets zu speichern.
+
+## Praktische Szenarien
+
+### **Szenario 1: Vault Agent Sidecar Injection**
+Vault injiziert automatisch einen Sidecar-Container, der Secrets abruft und für deine App bereitstellt:
+
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+  annotations:
+    vault.hashicorp.com/agent-inject: "true"
+    vault.hashicorp.com/role: "myapp"
+    vault.hashicorp.com/agent-inject-secret-database: "database/creds/myapp-role"
+spec:
+  serviceAccountName: myapp
+  containers:
+  - name: app
+    image: myapp:latest
+```
+
+**Ergebnis:** Datenbank-Credentials werden automatisch in `/vault/secrets/database` bereitgestellt.
+
+### **Szenario 2: Dynamische Datenbank-Credentials**
+Statt statische DB-Passwörter zu verwenden, generiert Vault temporäre Credentials:
+
+- Jeder Pod bekommt eigene DB-Credentials
+- Credentials sind zeitlich begrenzt (z.B. 24h)
+- Automatische Rotation
+- Einfaches Widerrufen bei Kompromittierung
+
+### **Szenario 3: Externe Secrets Operator (ESO)**
+Secrets werden als native Kubernetes Secrets synchronisiert:
+
+```yaml
+apiVersion: external-secrets.io/v1beta1
+kind: SecretStore
+metadata:
+  name: vault-backend
+spec:
+  provider:
+    vault:
+      server: "https://vault.test.k8s.schnrbs.work"
+      path: "secret"
+      auth:
+        kubernetes:
+          mountPath: "kubernetes"
+          role: "myapp"
+```
+
+### **Szenario 4: Verschlüsselung als Service**
+Anwendungen können Vault's Transit Engine nutzen:
+
+```bash
+# Daten verschlüsseln ohne den Key zu kennen
+vault write transit/encrypt/my-key plaintext=$(base64 <<< "sensitive data")
+
+# Daten entschlüsseln
+vault write transit/decrypt/my-key ciphertext="vault:v1:abc..."
+```
+
+### **Szenario 5: PKI/Zertifikats-Management**
+Automatische Ausstellung von TLS-Zertifikaten für Service-to-Service-Kommunikation:
+
+- Kurzlebige Zertifikate (z.B. 1h)
+- Automatische Rotation
+- Zero-Trust-Netzwerk
+
+### **Szenario 6: Multi-Tenancy**
+Verschiedene Namespaces/Teams haben isolierten Zugriff:
+
+```bash
+# Team A darf nur auf secret/team-a/* zugreifen
+# Team B darf nur auf secret/team-b/* zugreifen
+```
+
+## Vorteile gegenüber Kubernetes Secrets
+
+| Aspekt | Kubernetes Secrets | Vault Integration |
+|--------|-------------------|-------------------|
+| Verschlüsselung at rest | Optional, etcd-Ebene | Immer, zusätzlich verschlüsselt |
+| Secret Rotation | Manuell | Automatisch/dynamisch |
+| Audit Log | Begrenzt | Detailliert für jeden Zugriff |
+| Dynamische Secrets | Nein | Ja (DB, Cloud, etc.) |
+| Granulare Policies | Begrenzt | Sehr feinkörnig |
+| Encryption-as-a-Service | Nein | Ja |
+
+## Typischer Workflow nach der Konfiguration
+
+1. **Policy erstellen:** Definiere, wer auf welche Secrets zugreifen darf
+2. **Role erstellen:** Verknüpfe Kubernetes Service Accounts mit Vault Policies
+3. **Secrets bereitstellen:** Nutze Vault Agent Injection oder CSI Driver
+4. **Anwendung deployen:** Pods authentifizieren sich automatisch
+
+## Best Practice Setup
+
+Nach der Kubernetes Auth-Aktivierung solltest du:
+
+```bash
+# 1. Policy erstellen
+vault policy write myapp - <<EOF
+path "secret/data/myapp/*" {
+  capabilities = ["read"]
+}
+EOF
+
+# 2. Role erstellen
+vault write auth/kubernetes/role/myapp \
+  bound_service_account_names=myapp \
+  bound_service_account_namespaces=production \
+  policies=myapp \
+  ttl=1h
+
+# 3. Service Account in K8s erstellen
+kubectl create serviceaccount myapp -n production
+```
+
+Möchtest du ein spezifisches Szenario genauer erkunden oder brauchst du Hilfe bei der Konfiguration eines bestimmten Use Cases?
\ No newline at end of file