@xdev-asia/xdev-knowledge-mcp 1.0.44 → 1.0.45

package/content/series/luyen-thi/luyen-thi-ckad/chapters/03-app-observability/lessons/05-probes-logging-debugging.md

@@ -0,0 +1,183 @@
+---
+id: ckad-d3-l05
+title: 'Bài 5: Probes, Logging & Debugging'
+slug: 05-probes-logging-debugging
+description: >-
+  Liveness, Readiness và Startup Probes với các probe types (httpGet, tcpSocket,
+  exec). Kubectl logs, exec, debug và port-forward cho CKAD troubleshooting.
+duration_minutes: 55
+is_free: true
+video_url: null
+sort_order: 5
+section_title: "Domain 3: Application Observability and Maintenance (15%)"
+course:
+  id: lt-ckad-series-001
+  title: 'Luyện thi CKAD — Certified Kubernetes Application Developer'
+  slug: luyen-thi-ckad
+---
+
+<img src="/storage/uploads/2026/04/k8s-cert-ckad-bai5-probes.png" alt="Liveness, Readiness và Startup Probes — timeline và probe methods" style="max-width: 800px; width: 100%; border-radius: 12px;" />
+
+<h2 id="probe-types">1. Ba loại Probe</h2>
+
+<table>
+<thead><tr><th>Probe</th><th>Mục đích</th><th>Khi fail?</th></tr></thead>
+<tbody>
+<tr><td><strong>Liveness</strong></td><td>Container có còn "sống" không?</td><td>Container bị restart</td></tr>
+<tr><td><strong>Readiness</strong></td><td>Container có sẵn sàng nhận traffic?</td><td>Removed from Service endpoints (không restart)</td></tr>
+<tr><td><strong>Startup</strong></td><td>App đã khởi động xong chưa?</td><td>Container bị restart (dùng trước liveness check)</td></tr>
+</tbody>
+</table>
+
+<pre><code class="language-text">Probe execution timeline:
+
+  Container starts
+       │
+       ▼
+  startupProbe checks (periodically)
+       │ success
+       ▼
+  Both livenessProbe & readinessProbe run in parallel
+       │                      │
+       ▼ fail                 ▼ fail
+  Container restart       Removed from Service
+                          (pod still running)</code></pre>
+
+<h2 id="probe-methods">2. Probe Methods (httpGet, tcpSocket, exec)</h2>
+
+<pre><code class="language-text">livenessProbe:
+  httpGet:                # HTTP GET — success if status 200-399
+    path: /healthz
+    port: 8080
+    httpHeaders:
+    - name: Custom-Header
+      value: Awesome
+  initialDelaySeconds: 15  # Wait before first probe
+  periodSeconds: 20        # How often to probe
+  timeoutSeconds: 5        # Timeout per probe
+  failureThreshold: 3      # Fail count before action
+  successThreshold: 1      # Success count to pass
+
+readinessProbe:
+  tcpSocket:              # TCP connection — success if port open
+    port: 3306
+  initialDelaySeconds: 5
+  periodSeconds: 10
+
+startupProbe:
+  exec:                   # Run command in container — success if exit 0
+    command:
+    - cat
+    - /tmp/healthy
+  failureThreshold: 30    # Allows 30*10s = 5 min to start
+  periodSeconds: 10</code></pre>
+
+<table>
+<thead><tr><th>Field</th><th>Default</th><th>Ý nghĩa</th></tr></thead>
+<tbody>
+<tr><td><code>initialDelaySeconds</code></td><td>0</td><td>Chờ trước khi probe đầu tiên</td></tr>
+<tr><td><code>periodSeconds</code></td><td>10</td><td>Interval giữa các probes</td></tr>
+<tr><td><code>timeoutSeconds</code></td><td>1</td><td>Timeout của mỗi probe</td></tr>
+<tr><td><code>failureThreshold</code></td><td>3</td><td>Fail bao nhiêu lần thì action</td></tr>
+<tr><td><code>successThreshold</code></td><td>1</td><td>Pass bao nhiêu lần để "healthy"</td></tr>
+</tbody>
+</table>
+
+<blockquote><p><strong>Exam tip:</strong> <strong>Startup probe</strong> dùng khi app khởi động lâu (ví dụ: legacy app cần 2 phút load). Set <code>failureThreshold * periodSeconds</code> &gt;= thời gian startup tối đa. Liveness probe không chạy cho đến khi startup probe pass.</p></blockquote>
+
+<h2 id="logging">3. Logging & kubectl logs</h2>
+
+<pre><code class="language-text"># Xem logs của pod
+kubectl logs podname
+
+# Follow logs (tail -f)
+kubectl logs -f podname
+
+# Previous container (nếu bị crash)
+kubectl logs podname --previous
+
+# Logs của specific container trong multi-container pod
+kubectl logs podname -c container-name
+
+# Logs với timestamp
+kubectl logs podname --timestamps
+
+# Tail N lines
+kubectl logs podname --tail=100</code></pre>
+
+<h2 id="debugging">4. Debugging Commands</h2>
+
+<pre><code class="language-text"># Exec vào container
+kubectl exec -it podname -- /bin/bash
+kubectl exec -it podname -c container-name -- sh
+
+# Port forward để test service locally
+kubectl port-forward pod/podname 8080:80
+kubectl port-forward service/myservice 8080:80
+
+# Ephemeral debug container (khi container không có shell)
+kubectl debug -it podname --image=busybox --target=container-name
+
+# Debug a node
+kubectl debug node/worker-1 -it --image=ubuntu
+
+# Copy files
+kubectl cp podname:/app/logs/error.log ./error.log
+kubectl cp ./config.yaml podname:/app/config.yaml</code></pre>
+
+<blockquote><p><strong>Exam tip:</strong> Khi pod không có shell (distroless image), dùng <code>kubectl debug</code> với ephemeral container. Trong CKAD exam, <code>kubectl exec</code> + <code>kubectl logs</code> là 2 commands debugging quan trọng nhất. Luôn check logs trước khi exec.</p></blockquote>
+
+<h2 id="pod-states">5. Common Pod States & Debug</h2>
+
+<table>
+<thead><tr><th>Pod State</th><th>Nguyên nhân thường gặp</th><th>Debug command</th></tr></thead>
+<tbody>
+<tr><td><code>CrashLoopBackOff</code></td><td>App crash, bad command, missing config</td><td><code>kubectl logs --previous</code></td></tr>
+<tr><td><code>ImagePullBackOff</code></td><td>Wrong image name, registry auth failure</td><td><code>kubectl describe pod</code></td></tr>
+<tr><td><code>Pending</code></td><td>Insufficient resources, unschedulable</td><td><code>kubectl describe pod</code> → Events</td></tr>
+<tr><td><code>OOMKilled</code></td><td>Memory limit exceeded</td><td><code>kubectl describe pod</code> → Last State</td></tr>
+<tr><td><code>Error</code></td><td>Init container failed, bad entrypoint</td><td><code>kubectl logs -c init-c</code></td></tr>
+</tbody>
+</table>
+
+<h2 id="cheatsheet">6. Cheat Sheet</h2>
+
+<table>
+<thead><tr><th>Task</th><th>Command</th></tr></thead>
+<tbody>
+<tr><td>Check pod sức khỏe</td><td><code>kubectl describe pod &lt;name&gt;</code></td></tr>
+<tr><td>Xem logs crash</td><td><code>kubectl logs &lt;pod&gt; --previous</code></td></tr>
+<tr><td>Shell vào container</td><td><code>kubectl exec -it &lt;pod&gt; -- sh</code></td></tr>
+<tr><td>Test service connectivity</td><td><code>kubectl port-forward svc/&lt;name&gt; 8080:80</code></td></tr>
+<tr><td>Debug distroless container</td><td><code>kubectl debug -it &lt;pod&gt; --image=busybox</code></td></tr>
+</tbody>
+</table>
+
+<h2 id="practice">7. Practice Questions</h2>
+
+<p><strong>Q1:</strong> A Pod's readinessProbe fails, but the livenessProbe passes. What happens to the Pod?</p>
+<ul>
+<li>A) The Pod is restarted</li>
+<li>B) The Pod is deleted</li>
+<li>C) The Pod remains running but is removed from the Service's endpoint list ✓</li>
+<li>D) The Pod is marked as Failed</li>
+</ul>
+<p><em>Explanation: Readiness probe failure does NOT restart the container. It only removes the Pod from the Service endpoints so no new traffic is routed to it. The Pod keeps running. When the readiness probe passes again, the Pod is re-added to the endpoints.</em></p>
+
+<p><strong>Q2:</strong> An application takes 3 minutes to start. Without a startupProbe, the livenessProbe with failureThreshold: 3 and periodSeconds: 10 would kill the container before it finishes starting. How should you configure a startupProbe to allow up to 5 minutes for startup?</p>
+<ul>
+<li>A) startupProbe with failureThreshold: 5 and periodSeconds: 60</li>
+<li>B) startupProbe with failureThreshold: 30 and periodSeconds: 10 ✓</li>
+<li>C) startupProbe with failureThreshold: 300 and periodSeconds: 1</li>
+<li>D) startupProbe with initialDelaySeconds: 300</li>
+</ul>
+<p><em>Explanation: failureThreshold × periodSeconds = maximum startup time. 30 × 10s = 300s = 5 minutes. During this window, the liveness probe is disabled. Once the startup probe succeeds, both liveness and readiness probes activate.</em></p>
+
+<p><strong>Q3:</strong> You need to debug a running Pod that uses a distroless container image (no shell available). How do you get a shell for debugging?</p>
+<ul>
+<li>A) kubectl exec -it podname -- /bin/sh</li>
+<li>B) kubectl attach podname -it</li>
+<li>C) kubectl debug -it podname --image=busybox --target=app ✓</li>
+<li>D) kubectl run debug --image=busybox --attach</li>
+</ul>
+<p><em>Explanation: kubectl debug with an ephemeral container injects a debug container (busybox) into the running Pod with access to the same process namespace. The --target flag shares the process namespace with the specified container. This works even when the main container has no shell.</em></p>

package/content/series/luyen-thi/luyen-thi-ckad/chapters/04-app-environment-config/lessons/06-configmaps-secrets.md

@@ -0,0 +1,182 @@
+---
+id: ckad-d4-l06
+title: 'Bài 6: ConfigMaps & Secrets'
+slug: 06-configmaps-secrets
+description: >-
+  Tạo và consume ConfigMaps và Secrets trong Kubernetes. Inject qua env vars
+  (envFrom, valueFrom) và volume mounts. Secret types và security considerations.
+duration_minutes: 55
+is_free: true
+video_url: null
+sort_order: 6
+section_title: "Domain 4: Application Environment, Configuration and Security (25%)"
+course:
+  id: lt-ckad-series-001
+  title: 'Luyện thi CKAD — Certified Kubernetes Application Developer'
+  slug: luyen-thi-ckad
+---
+
+<img src="/storage/uploads/2026/04/k8s-cert-ckad-bai6-configmap-secret.png" alt="ConfigMap và Secret injection — envFrom, valueFrom và Volume Mount" style="max-width: 800px; width: 100%; border-radius: 12px;" />
+
+<h2 id="configmap">1. ConfigMap</h2>
+
+<p>ConfigMap lưu trữ cặp key-value non-sensitive. Không được mã hóa (plain text).</p>
+
+<pre><code class="language-text"># Tạo ConfigMap — Imperative
+kubectl create configmap app-config \
+  --from-literal=DB_HOST=mysql \
+  --from-literal=DB_PORT=3306
+
+kubectl create configmap app-config --from-file=config.properties
+kubectl create configmap app-config --from-env-file=.env
+
+# Declarative YAML
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  name: app-config
+data:
+  DB_HOST: mysql
+  DB_PORT: "3306"
+  config.properties: |
+    server.port=8080
+    debug=false</code></pre>
+
+<h2 id="secret">2. Secret</h2>
+
+<p>Secret lưu trữ sensitive data. Được <strong>base64 encode</strong> (không phải mã hóa — encode thôi!).</p>
+
+<pre><code class="language-text"># Tạo Secret — Imperative
+kubectl create secret generic db-secret \
+  --from-literal=username=admin \
+  --from-literal=password=mypassword
+
+kubectl create secret generic db-secret --from-file=credentials.txt
+
+# Declarative (base64 encode trước)
+echo -n 'admin' | base64    # YWRtaW4=
+echo -n 'mypassword' | base64  # bXlwYXNzd29yZA==
+
+apiVersion: v1
+kind: Secret
+metadata:
+  name: db-secret
+type: Opaque
+data:
+  username: YWRtaW4=
+  password: bXlwYXNzd29yZA==</code></pre>
+
+<table>
+<thead><tr><th>Secret Type</th><th>Mục đích</th></tr></thead>
+<tbody>
+<tr><td><code>Opaque</code></td><td>Generic — default type, any key-value data</td></tr>
+<tr><td><code>kubernetes.io/dockerconfigjson</code></td><td>Docker registry credentials</td></tr>
+<tr><td><code>kubernetes.io/tls</code></td><td>TLS certificate và private key</td></tr>
+<tr><td><code>kubernetes.io/service-account-token</code></td><td>ServiceAccount token (auto-created)</td></tr>
+</tbody>
+</table>
+
+<blockquote><p><strong>Exam tip:</strong> Secret data là <strong>base64 encoded, không encrypted</strong>. Bất kỳ ai có quyền đọc Secret đều có thể decode: <code>echo 'YWRtaW4=' | base64 -d</code>. Để encrypt at rest, phải enable EncryptionConfiguration — nhưng CKAD không test điều này. Exam thường test: tạo secret và inject vào Pod.</p></blockquote>
+
+<h2 id="inject-env">3. Inject qua Environment Variables</h2>
+
+<pre><code class="language-text">spec:
+  containers:
+  - name: app
+    image: myapp
+
+    # Method 1: envFrom — load ALL keys as env vars
+    envFrom:
+    - configMapRef:
+        name: app-config
+    - secretRef:
+        name: db-secret
+
+    # Method 2: valueFrom — load SPECIFIC key
+    env:
+    - name: DATABASE_HOST
+      valueFrom:
+        configMapKeyRef:
+          name: app-config
+          key: DB_HOST
+    - name: DB_PASSWORD
+      valueFrom:
+        secretKeyRef:
+          name: db-secret
+          key: password</code></pre>
+
+<h2 id="inject-volume">4. Inject qua Volume Mount</h2>
+
+<pre><code class="language-text">spec:
+  volumes:
+  - name: config-vol
+    configMap:
+      name: app-config
+  - name: secret-vol
+    secret:
+      secretName: db-secret
+
+  containers:
+  - name: app
+    image: myapp
+    volumeMounts:
+    - name: config-vol
+      mountPath: /etc/config    # Each key becomes a file
+    - name: secret-vol
+      mountPath: /etc/secrets
+      readOnly: true
+
+  # Result: /etc/config/DB_HOST contains "mysql"
+  #         /etc/secrets/password contains "mypassword" (decoded)</code></pre>
+
+<table>
+<thead><tr><th>Method</th><th>Khi dùng</th><th>Auto-update khi CM/Secret đổi?</th></tr></thead>
+<tbody>
+<tr><td><code>envFrom</code> / <code>env.valueFrom</code></td><td>App đọc env vars</td><td>Không (cần restart pod)</td></tr>
+<tr><td>Volume mount</td><td>App đọc từ files, hoặc cần auto-reload</td><td>Có (sau ~1-2 phút)</td></tr>
+</tbody>
+</table>
+
+<blockquote><p><strong>Exam tip:</strong> Volume-mounted ConfigMaps/Secrets tự động update khi nguồn thay đổi (sau kubelet sync period ~1 phút). Env vars phải restart pod mới reflect changes. CKAD thường test cả 2 methods — nắm rõ syntax của <code>configMapKeyRef</code> vs <code>configMapRef</code> (có chữ "Key" thì là single key).</p></blockquote>
+
+<h2 id="cheatsheet">5. Cheat Sheet</h2>
+
+<table>
+<thead><tr><th>Task</th><th>Command / YAML</th></tr></thead>
+<tbody>
+<tr><td>Tạo CM từ literals</td><td><code>kubectl create cm name --from-literal=k=v</code></td></tr>
+<tr><td>Tạo Secret từ literals</td><td><code>kubectl create secret generic n --from-literal=k=v</code></td></tr>
+<tr><td>Load all CM keys as env</td><td><code>envFrom: - configMapRef: name: ...</code></td></tr>
+<tr><td>Load specific key</td><td><code>env: - valueFrom: configMapKeyRef: ...</code></td></tr>
+<tr><td>Mount as files</td><td><code>volumes: configMap/secret + volumeMounts</code></td></tr>
+</tbody>
+</table>
+
+<h2 id="practice">6. Practice Questions</h2>
+
+<p><strong>Q1:</strong> A Pod needs to consume ALL key-value pairs from a ConfigMap named "app-settings" as environment variables. Which configuration is correct?</p>
+<ul>
+<li>A) <code>env: - name: APP_SETTINGS valueFrom: configMapRef: name: app-settings</code></li>
+<li>B) <code>envFrom: - configMapRef: name: app-settings</code> ✓</li>
+<li>C) <code>volumes: - configMap: name: app-settings</code></li>
+<li>D) <code>env: - configMapKeyRef: name: app-settings key: "*"</code></li>
+</ul>
+<p><em>Explanation: envFrom with configMapRef loads ALL keys from the ConfigMap as environment variables. env with valueFrom configMapKeyRef only loads ONE specific key. The wildcard "*" syntax does not exist.</em></p>
+
+<p><strong>Q2:</strong> You create a Secret with the command: kubectl create secret generic mysecret --from-literal=password=secret123. How is the data stored in etcd?</p>
+<ul>
+<li>A) Plain text: "password=secret123"</li>
+<li>B) AES-256 encrypted</li>
+<li>C) Base64 encoded ✓</li>
+<li>D) SHA-256 hashed</li>
+</ul>
+<p><em>Explanation: By default, Kubernetes stores Secret data as base64 encoded values in etcd — NOT encrypted. Base64 is encoding, not encryption. Anyone with etcd access can decode it. To encrypt at rest, an EncryptionConfiguration must be configured separately.</em></p>
+
+<p><strong>Q3:</strong> A ConfigMap is updated with new values. A Pod is using this ConfigMap mounted as a volume at /etc/config. What happens?</p>
+<ul>
+<li>A) The Pod fails immediately because the config changed</li>
+<li>B) The files in /etc/config are automatically updated (with a short delay) ✓</li>
+<li>C) Nothing happens — the Pod must be restarted to see changes</li>
+<li>D) The Pod is restarted automatically by Kubernetes</li>
+</ul>
+<p><em>Explanation: Volume-mounted ConfigMaps are automatically updated when the ConfigMap changes, after the kubelet sync period (typically ~1 minute). Environment variables from ConfigMaps do NOT auto-update — the Pod must be recreated. Applications that watch for file changes can react to these updates without restarts.</em></p>

package/content/series/luyen-thi/luyen-thi-ckad/chapters/04-app-environment-config/lessons/07-securitycontext-pod-security.md

@@ -0,0 +1,168 @@
+---
+id: ckad-d4-l07
+title: 'Bài 7: SecurityContext, Capabilities & ServiceAccounts'
+slug: 07-securitycontext-pod-security
+description: >-
+  SecurityContext cho Pod và Container: runAsUser, runAsNonRoot, readOnlyRootFilesystem,
+  Linux capabilities. ServiceAccount binding và automountServiceAccountToken.
+duration_minutes: 55
+is_free: true
+video_url: null
+sort_order: 7
+section_title: "Domain 4: Application Environment, Configuration and Security (25%)"
+course:
+  id: lt-ckad-series-001
+  title: 'Luyện thi CKAD — Certified Kubernetes Application Developer'
+  slug: luyen-thi-ckad
+---
+
+<img src="/storage/uploads/2026/04/k8s-cert-ckad-bai7-security-context.png" alt="SecurityContext — Pod-level vs Container-level, Linux capabilities" style="max-width: 800px; width: 100%; border-radius: 12px;" />
+
+<h2 id="securitycontext">1. SecurityContext</h2>
+
+<p>SecurityContext định nghĩa các privilege và access control settings cho Pod hoặc Container.</p>
+
+<pre><code class="language-text">apiVersion: v1
+kind: Pod
+spec:
+  securityContext:            # Pod-level: applies to ALL containers
+    runAsUser: 1000           # UID để chạy containers
+    runAsGroup: 3000          # GID primary group
+    fsGroup: 2000             # GID cho mounted volumes
+    runAsNonRoot: true        # Reject containers that run as root
+
+  containers:
+  - name: app
+    image: myapp
+    securityContext:          # Container-level: overrides pod-level
+      allowPrivilegeEscalation: false
+      readOnlyRootFilesystem: true   # Filesystem là read-only
+      capabilities:
+        add: ["NET_BIND_SERVICE"]    # Add capability
+        drop: ["ALL"]               # Drop all, add only what needed</code></pre>
+
+<table>
+<thead><tr><th>Setting</th><th>Level</th><th>Tác dụng</th></tr></thead>
+<tbody>
+<tr><td><code>runAsUser</code></td><td>Pod/Container</td><td>Chạy process với UID cụ thể</td></tr>
+<tr><td><code>runAsNonRoot</code></td><td>Pod/Container</td><td>Từ chối chạy nếu UID = 0 (root)</td></tr>
+<tr><td><code>readOnlyRootFilesystem</code></td><td>Container</td><td>Mount root filesystem read-only</td></tr>
+<tr><td><code>allowPrivilegeEscalation</code></td><td>Container</td><td>Chặn privilege escalation (sudo etc.)</td></tr>
+<tr><td><code>privileged</code></td><td>Container</td><td>Run as privileged (như root trên host)</td></tr>
+<tr><td><code>fsGroup</code></td><td>Pod</td><td>GID cho volume files (shared volume access)</td></tr>
+</tbody>
+</table>
+
+<blockquote><p><strong>Exam tip:</strong> Container-level <code>securityContext</code> <strong>override</strong> Pod-level settings. Nếu Pod có <code>runAsUser: 1000</code> và container có <code>runAsUser: 2000</code>, container đó chạy với UID 2000. Hay bị test: verify user bằng <code>kubectl exec pod -- id</code> hoặc <code>whoami</code>.</p></blockquote>
+
+<h2 id="capabilities">2. Linux Capabilities</h2>
+
+<pre><code class="language-text">Capabilities cho phép grant specific privileges mà không cần full root.
+
+# Ví dụ thường gặp:
+NET_BIND_SERVICE  — Bind to port < 1024 (e.g., port 80)
+NET_ADMIN         — Network administration (ifconfig etc.)
+SYS_TIME          — Modify system clock
+CHOWN             — Change file ownership
+SETUID/SETGID     — Change user/group ID
+
+securityContext:
+  capabilities:
+    drop: ["ALL"]             # Best practice: drop all first
+    add: ["NET_BIND_SERVICE"] # Then re-add only what's needed</code></pre>
+
+<h2 id="serviceaccount">3. ServiceAccounts</h2>
+
+<p>Pod dùng <strong>ServiceAccount</strong> để authenticate với Kubernetes API.</p>
+
+<pre><code class="language-text"># Tạo ServiceAccount
+kubectl create serviceaccount my-sa
+
+# Bind vào Role
+kubectl create rolebinding my-binding \
+  --role=pod-reader \
+  --serviceaccount=default:my-sa
+
+# Assign SA cho Pod
+spec:
+  serviceAccountName: my-sa     # Use specific SA
+  automountServiceAccountToken: false  # Don't auto-mount SA token
+
+# Mặc định: default SA được mount tại /var/run/secrets/kubernetes.io/serviceaccount/
+# Token file có thể gọi K8s API từ container</code></pre>
+
+<table>
+<thead><tr><th>Concept</th><th>Mô tả</th></tr></thead>
+<tbody>
+<tr><td>Default SA</td><td>Mỗi namespace có sẵn <code>default</code> SA (ít quyền)</td></tr>
+<tr><td>Token mount</td><td>Token tự động mount vào pod nếu không tắt</td></tr>
+<tr><td><code>automountServiceAccountToken: false</code></td><td>Tắt việc mount token (best security practice)</td></tr>
+</tbody>
+</table>
+
+<blockquote><p><strong>Exam tip:</strong> Khi Pod cần gọi Kubernetes API (ví dụ: operator pattern), cần ServiceAccount có quyền phù hợp. Nếu Pod không cần gọi API, best practice là set <code>automountServiceAccountToken: false</code>. CKAD thường test: tạo SA, bind role, và set SA trong Pod spec.</p></blockquote>
+
+<h2 id="readonly-volume">4. readOnlyRootFilesystem với emptyDir</h2>
+
+<pre><code class="language-text"># Khi dùng readOnlyRootFilesystem: true, app KHÔNG ghi vào root FS.
+# Nhưng app vẫn cần ghi temp files → dùng emptyDir volume:
+
+spec:
+  containers:
+  - name: app
+    image: myapp
+    securityContext:
+      readOnlyRootFilesystem: true
+    volumeMounts:
+    - name: tmp
+      mountPath: /tmp        # App ghi temp files vào đây
+    - name: cache
+      mountPath: /app/cache
+  volumes:
+  - name: tmp
+    emptyDir: {}
+  - name: cache
+    emptyDir: {}</code></pre>
+
+<h2 id="cheatsheet">5. Cheat Sheet</h2>
+
+<table>
+<thead><tr><th>Task</th><th>YAML / Command</th></tr></thead>
+<tbody>
+<tr><td>Run container as non-root</td><td><code>securityContext: runAsNonRoot: true</code></td></tr>
+<tr><td>Run với specific UID</td><td><code>securityContext: runAsUser: 1000</code></td></tr>
+<tr><td>Read-only filesystem</td><td><code>securityContext: readOnlyRootFilesystem: true</code></td></tr>
+<tr><td>Drop all capabilities</td><td><code>capabilities: drop: ["ALL"]</code></td></tr>
+<tr><td>Gán ServiceAccount</td><td><code>spec: serviceAccountName: my-sa</code></td></tr>
+<tr><td>Verify user trong container</td><td><code>kubectl exec pod -- whoami</code></td></tr>
+</tbody>
+</table>
+
+<h2 id="practice">6. Practice Questions</h2>
+
+<p><strong>Q1:</strong> A Pod spec has securityContext.runAsUser: 1000 at the Pod level. One container within the Pod has securityContext.runAsUser: 2000. What UID does that container run with?</p>
+<ul>
+<li>A) 0 (root, because Pod-level overrides)</li>
+<li>B) 1000 (Pod-level takes priority)</li>
+<li>C) 2000 (Container-level overrides Pod-level) ✓</li>
+<li>D) Both UIDs simultaneously</li>
+</ul>
+<p><em>Explanation: Container-level securityContext settings override Pod-level settings. The container runs with UID 2000. Other containers in the same Pod without a container-level securityContext.runAsUser would inherit the Pod-level UID of 1000.</em></p>
+
+<p><strong>Q2:</strong> An application container needs to bind to port 80 (a privileged port below 1024) but should NOT run as root. How do you configure this?</p>
+<ul>
+<li>A) Set securityContext.privileged: true</li>
+<li>B) Set securityContext.runAsUser: 0</li>
+<li>C) Add NET_BIND_SERVICE capability while dropping ALL others ✓</li>
+<li>D) Use a NodePort Service instead of port 80</li>
+</ul>
+<p><em>Explanation: Linux capabilities allow granular privilege grants. NET_BIND_SERVICE allows binding to ports below 1024 without full root. Best practice is to drop ALL capabilities first, then add only what's needed: capabilities: { drop: ["ALL"], add: ["NET_BIND_SERVICE"] }.</em></p>
+
+<p><strong>Q3:</strong> A Pod is running with readOnlyRootFilesystem: true, but the application tries to write to /tmp and fails. What is the best solution?</p>
+<ul>
+<li>A) Remove readOnlyRootFilesystem: true</li>
+<li>B) Set securityContext.privileged: true</li>
+<li>C) Mount an emptyDir volume at /tmp ✓</li>
+<li>D) Use a ConfigMap mounted at /tmp</li>
+</ul>
+<p><em>Explanation: readOnlyRootFilesystem prevents writes to the container's filesystem, but emptyDir volumes are separate writable mounts. By mounting an emptyDir at /tmp, the application can write temp files there while the root filesystem remains read-only — maintaining the security benefit.</em></p>