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

package/content/series/luyen-thi/luyen-thi-ckad/chapters/02-app-deployment/lessons/03-rolling-updates-rollbacks.md

@@ -0,0 +1,148 @@
+---
+id: ckad-d2-l03
+title: 'Bài 3: Rolling Updates, Rollbacks & Deployment Strategies'
+slug: 03-rolling-updates-rollbacks
+description: >-
+  Deployment strategies: RollingUpdate vs Recreate. Kubectl rollout commands,
+  maxUnavailable/maxSurge. Revision history và rollback kỹ thuật cho CKAD.
+duration_minutes: 55
+is_free: true
+video_url: null
+sort_order: 3
+section_title: "Domain 2: Application Deployment (20%)"
+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-bai3-rolling-update.png" alt="Rolling Update và Rollback — maxUnavailable, maxSurge, ReplicaSet history" style="max-width: 800px; width: 100%; border-radius: 12px;" />
+
+<h2 id="strategies">1. Deployment Strategies</h2>
+
+<table>
+<thead><tr><th>Strategy</th><th>Cách hoạt động</th><th>Downtime?</th><th>Khi dùng</th></tr></thead>
+<tbody>
+<tr><td><strong>RollingUpdate</strong></td><td>Replace pods dần dần, maintain availability</td><td>Không</td><td>Default, production</td></tr>
+<tr><td><strong>Recreate</strong></td><td>Kill tất cả pods cũ, tạo mới</td><td>Có</td><td>Dev/test, breaking changes</td></tr>
+</tbody>
+</table>
+
+<pre><code class="language-text">spec:
+  strategy:
+    type: RollingUpdate
+    rollingUpdate:
+      maxUnavailable: 1   # OR "25%"  — Max pods unavailable during update
+      maxSurge: 1         # OR "25%"  — Max extra pods above desired count
+
+      ┌─────────────────────────────────────────────────┐
+      │ Desired: 4 pods                                  │
+      │                                                  │
+      │ maxUnavailable: 1 → min 3 pods must be running  │
+      │ maxSurge: 1       → max 5 pods total at once    │
+      │                                                  │
+      │ Step 1: Create 1 new pod (5 total = desired+surge)│
+      │ Step 2: Terminate 1 old pod (4 total)           │
+      │ Step 3: Repeat until all replaced               │
+      └─────────────────────────────────────────────────┘</code></pre>
+
+<blockquote><p><strong>Exam tip:</strong> <code>maxUnavailable</code> và <code>maxSurge</code> KHÔNG thể cùng lúc là 0. Nếu cần zero-downtime update: set <code>maxUnavailable: 0</code> và <code>maxSurge: 1</code> (hoặc cao hơn).</p></blockquote>
+
+<h2 id="rollout">2. kubectl rollout Commands</h2>
+
+<pre><code class="language-text"># Xem trạng thái rollout
+kubectl rollout status deployment/myapp
+
+# Xem revision history
+kubectl rollout history deployment/myapp
+kubectl rollout history deployment/myapp --revision=2
+
+# Rollback về version trước
+kubectl rollout undo deployment/myapp
+
+# Rollback về revision cụ thể
+kubectl rollout undo deployment/myapp --to-revision=2
+
+# Tạm dừng rollout
+kubectl rollout pause deployment/myapp
+
+# Resume rollout
+kubectl rollout resume deployment/myapp</code></pre>
+
+<table>
+<thead><tr><th>Command</th><th>Tác dụng</th></tr></thead>
+<tbody>
+<tr><td><code>rollout status</code></td><td>Wait/show current rollout progress</td></tr>
+<tr><td><code>rollout history</code></td><td>List revision history</td></tr>
+<tr><td><code>rollout undo</code></td><td>Rollback to previous (or specific) revision</td></tr>
+<tr><td><code>rollout pause/resume</code></td><td>Pause để canary test, rồi resume</td></tr>
+<tr><td><code>rollout restart</code></td><td>Force restart tất cả pods (rolling)</td></tr>
+</tbody>
+</table>
+
+<blockquote><p><strong>Exam tip:</strong> Để lưu <code>CHANGE-CAUSE</code> trong revision history, thêm annotation: <code>kubectl annotate deployment/myapp kubernetes.io/change-cause="Updated image to v2"</code> TRƯỚC khi update. Hoặc dùng <code>--record</code> flag (deprecated nhưng vẫn hoạt động trong exam).</p></blockquote>
+
+<h2 id="trigger">3. Trigger & Monitor Update</h2>
+
+<pre><code class="language-text"># Update image (trigger rolling update)
+kubectl set image deployment/myapp container-name=nginx:1.25
+
+# Xem ReplicaSet history (mỗi update tạo mới 1 RS)
+kubectl get rs
+# NAME              DESIRED   CURRENT   READY
+# myapp-7d9b8c      4         4         4     ← current
+# myapp-6f5a2b      0         0         0     ← old (kept for rollback)
+
+# Scale deployment
+kubectl scale deployment/myapp --replicas=6
+
+# Edit deployment trực tiếp
+kubectl edit deployment/myapp</code></pre>
+
+<h2 id="revisionhistory">4. Revision History Limit</h2>
+
+<pre><code class="language-text">spec:
+  revisionHistoryLimit: 10  # Default: 10 old RS kept for rollback
+                             # Set to 0 to disable rollback capability</code></pre>
+
+<h2 id="cheatsheet">5. Cheat Sheet</h2>
+
+<table>
+<thead><tr><th>Tình huống exam</th><th>Command</th></tr></thead>
+<tbody>
+<tr><td>Update image</td><td><code>kubectl set image deploy/app c=image:v2</code></td></tr>
+<tr><td>Check rollout</td><td><code>kubectl rollout status deploy/app</code></td></tr>
+<tr><td>Rollback nhanh</td><td><code>kubectl rollout undo deploy/app</code></td></tr>
+<tr><td>Rollback về rev 3</td><td><code>kubectl rollout undo deploy/app --to-revision=3</code></td></tr>
+<tr><td>Zero-downtime config</td><td><code>maxUnavailable: 0, maxSurge: 1</code></td></tr>
+</tbody>
+</table>
+
+<h2 id="practice">6. Practice Questions</h2>
+
+<p><strong>Q1:</strong> A Deployment with 10 replicas is configured with maxUnavailable: 2 and maxSurge: 3. During a rolling update, what is the maximum number of pods that can exist at any given time?</p>
+<ul>
+<li>A) 10</li>
+<li>B) 12</li>
+<li>C) 13 ✓</li>
+<li>D) 15</li>
+</ul>
+<p><em>Explanation: maxSurge=3 means up to 3 extra pods above the desired count (10) can exist simultaneously. So maximum = 10 + 3 = 13 pods. Meanwhile, maxUnavailable=2 means at least 8 pods must be available.</em></p>
+
+<p><strong>Q2:</strong> You updated a Deployment and then realized the new version has a bug. Which command quickly reverts to the previous working version?</p>
+<ul>
+<li>A) <code>kubectl delete deployment myapp && kubectl apply -f old.yaml</code></li>
+<li>B) <code>kubectl rollout undo deployment/myapp</code> ✓</li>
+<li>C) <code>kubectl rollout history deployment/myapp</code></li>
+<li>D) <code>kubectl set image deployment/myapp container=old-image</code></li>
+</ul>
+<p><em>Explanation: rollout undo is the fastest way to revert to the previous revision. It creates a new rolling update back to the previous ReplicaSet. Option D also works but requires knowing the exact old image name.</em></p>
+
+<p><strong>Q3:</strong> A Deployment uses Recreate strategy. What is the expected behavior during an update?</p>
+<ul>
+<li>A) Pods are replaced one at a time with no downtime</li>
+<li>B) All existing pods are terminated before new pods are created, causing downtime ✓</li>
+<li>C) Half the pods are updated at once while the other half serve traffic</li>
+<li>D) New pods are created first, then old pods are terminated</li>
+</ul>
+<p><em>Explanation: Recreate strategy terminates ALL existing pods at once (scale to 0), then creates the new pods. This causes downtime but ensures no two versions run simultaneously — suitable when old and new versions cannot coexist.</em></p>

package/content/series/luyen-thi/luyen-thi-ckad/chapters/02-app-deployment/lessons/04-helm-kustomize.md

@@ -0,0 +1,181 @@
+---
+id: ckad-d2-l04
+title: 'Bài 4: Helm & Kustomize'
+slug: 04-helm-kustomize
+description: >-
+  Helm charts, releases, values.yaml và upgrade/rollback workflow. Kustomize
+  overlays và bases. Phân biệt khi nào dùng Helm vs Kustomize cho CKAD.
+duration_minutes: 50
+is_free: true
+video_url: null
+sort_order: 4
+section_title: "Domain 2: Application Deployment (20%)"
+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-bai4-helm-kustomize.png" alt="Helm vs Kustomize — Chart structure, template engine, overlays" style="max-width: 800px; width: 100%; border-radius: 12px;" />
+
+<h2 id="helm-concepts">1. Helm Core Concepts</h2>
+
+<p><strong>Helm</strong> là Kubernetes package manager. Nó đóng gói các Kubernetes manifests vào <strong>Charts</strong> và quản lý deployments dưới dạng <strong>Releases</strong>.</p>
+
+<pre><code class="language-text">Helm Architecture:
+
+  values.yaml          Chart templates
+       │                    │
+       ▼                    ▼
+  ┌──────────────────────────────┐
+  │   Helm Template Engine       │
+  │   Renders YAML manifests     │
+  └──────────────┬───────────────┘
+                 │
+                 ▼ kubectl apply
+         Kubernetes Cluster
+          (stored as Release)</code></pre>
+
+<table>
+<thead><tr><th>Term</th><th>Định nghĩa</th></tr></thead>
+<tbody>
+<tr><td><strong>Chart</strong></td><td>Package của Helm — bao gồm templates + default values</td></tr>
+<tr><td><strong>Release</strong></td><td>Instance của Chart đã được deploy lên cluster</td></tr>
+<tr><td><strong>Repository</strong></td><td>Nơi lưu trữ Charts (như artifact hub, bitnami)</td></tr>
+<tr><td><strong>Values</strong></td><td>Configuration parameters để customize Chart</td></tr>
+<tr><td><strong>Revision</strong></td><td>Mỗi install/upgrade tạo ra một revision mới</td></tr>
+</tbody>
+</table>
+
+<h2 id="helm-commands">2. Helm Commands</h2>
+
+<pre><code class="language-text"># Add repository
+helm repo add bitnami https://charts.bitnami.com/bitnami
+helm repo update
+
+# Search charts
+helm search repo bitnami/nginx
+helm search hub wordpress
+
+# Install chart
+helm install my-release bitnami/nginx
+helm install my-release bitnami/nginx --values custom-values.yaml
+helm install my-release bitnami/nginx --set image.tag=1.25
+
+# List releases
+helm list
+helm list -n production
+
+# Upgrade release
+helm upgrade my-release bitnami/nginx --set replicaCount=3
+
+# Rollback to previous revision
+helm rollback my-release 1   # rollback to revision 1
+helm rollback my-release     # rollback to previous revision
+
+# Uninstall
+helm uninstall my-release
+
+# View rendered templates (dry-run)
+helm template my-release bitnami/nginx
+helm install my-release bitnami/nginx --dry-run</code></pre>
+
+<blockquote><p><strong>Exam tip:</strong> CKAD thường test <code>helm install</code> với flag <code>--set</code> (override values trực tiếp) và <code>--values file.yaml</code> (override từ file). Cũng test <code>helm upgrade</code> và <code>helm rollback</code>. Nhớ rằng <code>--set</code> override trumps <code>--values</code> file.</p></blockquote>
+
+<h2 id="kustomize">3. Kustomize</h2>
+
+<p><strong>Kustomize</strong> là tool built vào kubectl cho phép customize Kubernetes manifests mà không cần templates hoặc parameters. Dùng overlay pattern.</p>
+
+<pre><code class="language-text">Kustomize Structure:
+  base/
+  ├── kustomization.yaml    # Base kustomization
+  ├── deployment.yaml
+  └── service.yaml
+
+  overlays/
+  ├── development/
+  │   ├── kustomization.yaml  # Patches for dev
+  │   └── replica-patch.yaml
+  └── production/
+      ├── kustomization.yaml  # Patches for prod
+      └── replica-patch.yaml</code></pre>
+
+<pre><code class="language-text"># base/kustomization.yaml
+apiVersion: kustomize.config.k8s.io/v1beta1
+kind: Kustomization
+resources:
+  - deployment.yaml
+  - service.yaml
+
+# overlays/production/kustomization.yaml
+apiVersion: kustomize.config.k8s.io/v1beta1
+kind: Kustomization
+bases:
+  - ../../base
+patches:
+  - path: replica-patch.yaml
+images:
+  - name: myapp
+    newTag: "2.0"</code></pre>
+
+<pre><code class="language-text"># Apply với kustomize
+kubectl apply -k overlays/production/
+
+# Preview rendered output
+kubectl kustomize overlays/production/</code></pre>
+
+<h2 id="comparison">4. Helm vs Kustomize</h2>
+
+<table>
+<thead><tr><th>Tiêu chí</th><th>Helm</th><th>Kustomize</th></tr></thead>
+<tbody>
+<tr><td>Approach</td><td>Template-based (Go templates)</td><td>Overlay/patching (plain YAML)</td></tr>
+<tr><td>Learning curve</td><td>Cao hơn (template syntax)</td><td>Thấp hơn (YAML patches)</td></tr>
+<tr><td>Package mgmt</td><td>Có (charts, repos, versioning)</td><td>Không</td></tr>
+<tr><td>Release history</td><td>Có (upgrade/rollback)</td><td>Không built-in</td></tr>
+<tr><td>Built into kubectl</td><td>Không (separate binary)</td><td>Có (<code>kubectl apply -k</code>)</td></tr>
+<tr><td>Best for</td><td>Phân phối (distribute) apps</td><td>Env-specific customization</td></tr>
+</tbody>
+</table>
+
+<h2 id="cheatsheet">5. Cheat Sheet</h2>
+
+<table>
+<thead><tr><th>Task</th><th>Command</th></tr></thead>
+<tbody>
+<tr><td>Install chart với custom values</td><td><code>helm install rel chart --values f.yaml</code></td></tr>
+<tr><td>Override một value</td><td><code>helm install rel chart --set key=val</code></td></tr>
+<tr><td>Rollback Helm release</td><td><code>helm rollback release-name 2</code></td></tr>
+<tr><td>Apply kustomize overlay</td><td><code>kubectl apply -k overlays/prod/</code></td></tr>
+<tr><td>Preview kustomize output</td><td><code>kubectl kustomize overlays/prod/</code></td></tr>
+</tbody>
+</table>
+
+<h2 id="practice">6. Practice Questions</h2>
+
+<p><strong>Q1:</strong> You need to deploy a Helm chart from the "stable" repo with a custom replica count of 5. Which command accomplishes this?</p>
+<ul>
+<li>A) <code>helm deploy myapp stable/nginx --replicas=5</code></li>
+<li>B) <code>helm install myapp stable/nginx --set replicaCount=5</code> ✓</li>
+<li>C) <code>helm install myapp stable/nginx -e replicaCount=5</code></li>
+<li>D) <code>helm apply myapp stable/nginx --values replicaCount=5</code></li>
+</ul>
+<p><em>Explanation: helm install uses --set flag to override values. The syntax is --set key=value. The exact key name (replicaCount) depends on the chart's values.yaml, but --set is the correct flag for inline value overrides.</em></p>
+
+<p><strong>Q2:</strong> A team uses Kustomize with a base configuration and production/staging overlays. Which command applies the production overlay?</p>
+<ul>
+<li>A) <code>kubectl apply -f overlays/production/</code></li>
+<li>B) <code>kubectl kustomize overlays/production/ | kubectl apply -f -</code></li>
+<li>C) <code>kubectl apply -k overlays/production/</code> ✓</li>
+<li>D) <code>kustomize apply overlays/production/</code></li>
+</ul>
+<p><em>Explanation: kubectl apply -k (note -k not -f) is the built-in way to apply a kustomization directory. Option B also works but is more verbose. The -k flag tells kubectl to process the directory as a Kustomize configuration.</em></p>
+
+<p><strong>Q3:</strong> After a Helm upgrade introduces a bug, you need to revert to the previous working state. What is the correct approach?</p>
+<ul>
+<li>A) kubectl rollout undo deployment/myapp</li>
+<li>B) helm install --replace myapp stable/nginx</li>
+<li>C) helm rollback myapp ✓</li>
+<li>D) helm upgrade myapp --version=previous</li>
+</ul>
+<p><em>Explanation: helm rollback reverts a release to a previous revision. Without specifying a revision number, it rolls back to the previous one. This undoes all the changes made by the failed upgrade, including ConfigMaps, Secrets, and other resources managed by the chart.</em></p>

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>