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

package/content/series/luyen-thi/luyen-thi-kcna/chapters/03-cloud-native-architecture/lessons/07-cloud-native-architecture.md

@@ -0,0 +1,143 @@
+---
+id: kcna-d3-l07
+title: 'Bài 7: Cloud Native Architecture & Design Patterns'
+slug: 07-cloud-native-architecture
+description: >-
+  Cloud native principles, microservices vs monolith, service mesh, 12-factor
+  app, immutable infrastructure và cloud native design patterns.
+duration_minutes: 55
+is_free: true
+video_url: null
+sort_order: 7
+section_title: "Domain 3: Cloud Native Architecture (16%)"
+course:
+  id: lt-kcna-series-001
+  title: 'Luyện thi KCNA — Kubernetes and Cloud Native Associate'
+  slug: luyen-thi-kcna
+---
+
+<img src="/storage/uploads/2026/04/k8s-cert-kcna-bai7-cloud-native.png" alt="Cloud Native Architecture — Microservices vs Monolith, 12-Factor App" style="max-width: 800px; width: 100%; border-radius: 12px;" />
+
+<h2 id="cloud-native">1. Cloud Native — Định nghĩa CNCF</h2>
+
+<p>Theo <strong>CNCF (Cloud Native Computing Foundation)</strong>, cloud native là cách build và run scalable applications trong dynamic environments như public, private, hybrid cloud, sử dụng: <strong>containers, microservices, declarative APIs, immutable infrastructure</strong>.</p>
+
+<table>
+<thead><tr><th>Principle</th><th>Ý nghĩa</th><th>Ví dụ</th></tr></thead>
+<tbody>
+<tr><td><strong>Containerized</strong></td><td>Đóng gói app + dependencies</td><td>Docker image</td></tr>
+<tr><td><strong>Dynamically orchestrated</strong></td><td>Automated scheduling, scaling, healing</td><td>Kubernetes</td></tr>
+<tr><td><strong>Microservices</strong></td><td>Loose coupling, single responsibility</td><td>Auth service, Payment service</td></tr>
+<tr><td><strong>Declarative APIs</strong></td><td>Describe desired state, not steps</td><td>kubectl apply -f deployment.yaml</td></tr>
+<tr><td><strong>Immutable infrastructure</strong></td><td>Never modify running; replace instead</td><td>New image version → rolling update</td></tr>
+</tbody>
+</table>
+
+<h2 id="microservices-vs-monolith">2. Microservices vs Monolith</h2>
+
+<pre><code class="language-text">MONOLITH                          MICROSERVICES
+─────────────────────             ──────────────────────────────
+┌──────────────────┐              ┌────────┐ ┌────────┐ ┌─────┐
+│  Auth    │  UI   │              │  Auth  │ │  Cart  │ │  UI │
+│  Cart    │  API  │              │Service │ │Service │ │Svc  │
+│  Payment │  DB   │              └────────┘ └────────┘ └─────┘
+└──────────────────┘                   │          │         │
+  Deploy as 1 unit                     └─── API Gateway ───┘
+                                            │
+                                       Client/Browser</code></pre>
+
+<table>
+<thead><tr><th>Aspect</th><th>Monolith</th><th>Microservices</th></tr></thead>
+<tbody>
+<tr><td>Deployment</td><td>All-or-nothing</td><td>Independent per service</td></tr>
+<tr><td>Scaling</td><td>Scale entire app</td><td>Scale only bottleneck service</td></tr>
+<tr><td>Complexity</td><td>Low (single codebase)</td><td>High (distributed)</td></tr>
+<tr><td>Fault isolation</td><td>One bug crashes all</td><td>Failure contained in service</td></tr>
+<tr><td>Technology</td><td>Single stack</td><td>Polyglot (best tool per service)</td></tr>
+</tbody>
+</table>
+
+<h2 id="12-factor">3. 12-Factor App</h2>
+
+<p>The <strong>12-factor app</strong> methodology định nghĩa best practices cho cloud native applications:</p>
+
+<table>
+<thead><tr><th>#</th><th>Factor</th><th>Cloud Native Practice</th></tr></thead>
+<tbody>
+<tr><td>1</td><td><strong>Codebase</strong></td><td>1 repo per app, many deploys</td></tr>
+<tr><td>2</td><td><strong>Dependencies</strong></td><td>Declare explicitly (package.json, go.mod)</td></tr>
+<tr><td>3</td><td><strong>Config</strong></td><td>Store in environment (ConfigMap, Secrets)</td></tr>
+<tr><td>4</td><td><strong>Backing services</strong></td><td>DB, cache = attached resources via URL</td></tr>
+<tr><td>5</td><td><strong>Build/Release/Run</strong></td><td>Strict separation (CI builds, CD deploys)</td></tr>
+<tr><td>6</td><td><strong>Processes</strong></td><td>Stateless processes, store state externally</td></tr>
+<tr><td>7</td><td><strong>Port binding</strong></td><td>Export service via port (no web server layer)</td></tr>
+<tr><td>8</td><td><strong>Concurrency</strong></td><td>Scale via process model (HPA)</td></tr>
+<tr><td>9</td><td><strong>Disposability</strong></td><td>Fast startup, graceful shutdown</td></tr>
+<tr><td>10</td><td><strong>Dev/Prod parity</strong></td><td>Same tools/services across environments</td></tr>
+<tr><td>11</td><td><strong>Logs</strong></td><td>Treat as event streams (stdout, not files)</td></tr>
+<tr><td>12</td><td><strong>Admin processes</strong></td><td>Run one-off admin tasks as Jobs</td></tr>
+</tbody>
+</table>
+
+<blockquote><p><strong>Exam tip:</strong> Factors 3, 6, 9, 11 hay xuất hiện trong câu hỏi KCNA. Factor 3 (config in env) → ConfigMap/Secret. Factor 6 (stateless) → lý do dùng external storage. Factor 11 (logs as streams) → stdout → log aggregator.</p></blockquote>
+
+<h2 id="service-mesh">4. Service Mesh</h2>
+
+<p>Khi microservices nhiều lên, cần quản lý: mTLS, retry, circuit breaker, observability. <strong>Service Mesh</strong> giải quyết điều này bằng cách inject <strong>sidecar proxy</strong> vào mỗi Pod.</p>
+
+<pre><code class="language-text">Without Service Mesh:          With Service Mesh (Istio):
+  App A ──────────────► App B    App A ──► [Envoy] ──► [Envoy] ──► App B
+  (manual TLS, retry code)         sidecar           sidecar
+                                 (auto mTLS, metrics, retry, tracing)</code></pre>
+
+<table>
+<thead><tr><th>Tính năng</th><th>Service Mesh cung cấp</th></tr></thead>
+<tbody>
+<tr><td>mTLS mutual authentication</td><td>Auto-encrypt traffic giữa services</td></tr>
+<tr><td>Traffic management</td><td>Canary, A/B, weighted routing</td></tr>
+<tr><td>Observability</td><td>Auto metrics, tracing, access logs</td></tr>
+<tr><td>Resilience</td><td>Retry, timeout, circuit breaker</td></tr>
+</tbody>
+</table>
+
+<h2 id="cheatsheet">5. Cheat Sheet</h2>
+
+<table>
+<thead><tr><th>Câu hỏi exam</th><th>Đáp án</th></tr></thead>
+<tbody>
+<tr><td>CNCF định nghĩa cloud native bao gồm?</td><td>Containers, microservices, declarative APIs, immutable infra</td></tr>
+<tr><td>Config nên lưu ở đâu theo 12-factor?</td><td>Environment variables (không hardcode)</td></tr>
+<tr><td>Logs theo 12-factor?</td><td>Treat as streams (stdout/stderr)</td></tr>
+<tr><td>Service mesh inject gì vào Pod?</td><td><strong>Sidecar proxy</strong> (Envoy)</td></tr>
+<tr><td>Microservices scale phần nào?</td><td>Chỉ service có bottleneck</td></tr>
+</tbody>
+</table>
+
+<h2 id="practice">6. Practice Questions</h2>
+
+<p><strong>Q1:</strong> According to the 12-factor app methodology, how should an application store its database connection string?</p>
+<ul>
+<li>A) Hardcoded in the source code</li>
+<li>B) In a configuration file committed to the repository</li>
+<li>C) As an environment variable (Kubernetes ConfigMap or Secret) ✓</li>
+<li>D) In the container image as a build argument</li>
+</ul>
+<p><em>Explanation: Factor 3 (Config) states: "Store config in the environment." In Kubernetes, this means using ConfigMaps for non-sensitive config and Secrets for sensitive values, injected as environment variables.</em></p>
+
+<p><strong>Q2:</strong> What is the primary benefit of using a Service Mesh in a microservices architecture?</p>
+<ul>
+<li>A) Replace Kubernetes for container orchestration</li>
+<li>B) Provide infrastructure-level networking features (mTLS, retry, observability) without changing application code ✓</li>
+<li>C) Store application configuration</li>
+<li>D) Persist application state across container restarts</li>
+</ul>
+<p><em>Explanation: Service mesh moves cross-cutting concerns (security, observability, resilience) to the infrastructure layer via sidecar proxies. Developers don't need to implement retry logic or mTLS in each service.</em></p>
+
+<p><strong>Q3:</strong> Which characteristic distinguishes "immutable infrastructure" from traditional infrastructure?</p>
+<ul>
+<li>A) Servers are never rebooted</li>
+<li>B) Running systems are replaced rather than modified in-place ✓</li>
+<li>C) Configuration changes require manual approval</li>
+<li>D) Infrastructure is defined using only YAML files</li>
+</ul>
+<p><em>Explanation: Immutable infrastructure means you never update/patch a running container — you build a new image, deploy it, replace old containers. This eliminates configuration drift and improves repeatability.</em></p>

package/content/series/luyen-thi/luyen-thi-kcna/chapters/04-observability-delivery/lessons/08-observability.md

@@ -0,0 +1,143 @@
+---
+id: kcna-d4-l08
+title: 'Bài 8: Cloud Native Observability'
+slug: 08-observability
+description: >-
+  Ba trụ cột của Observability: Metrics, Logs, Traces. Prometheus, Grafana,
+  OpenTelemetry, Jaeger, Loki và observability trong Kubernetes.
+duration_minutes: 55
+is_free: true
+video_url: null
+sort_order: 8
+section_title: "Domain 4: Cloud Native Observability & Security (16%)"
+course:
+  id: lt-kcna-series-001
+  title: 'Luyện thi KCNA — Kubernetes and Cloud Native Associate'
+  slug: luyen-thi-kcna
+---
+
+<img src="/storage/uploads/2026/04/k8s-cert-kcna-bai8-observability.png" alt="Three Pillars of Observability — Metrics, Logs, Traces" style="max-width: 800px; width: 100%; border-radius: 12px;" />
+
+<h2 id="three-pillars">1. Ba Trụ Cột của Observability</h2>
+
+<p>Observability là khả năng hiểu trạng thái nội tại của một hệ thống qua các signals từ bên ngoài. Gồm 3 trụ cột:</p>
+
+<table>
+<thead><tr><th>Pillar</th><th>Là gì</th><th>Trả lời câu hỏi</th><th>Tool</th></tr></thead>
+<tbody>
+<tr><td><strong>Metrics</strong></td><td>Số liệu tổng hợp theo thời gian</td><td>"Hệ thống đang ở trạng thái nào?"</td><td>Prometheus + Grafana</td></tr>
+<tr><td><strong>Logs</strong></td><td>Dòng text event từ từng service</td><td>"Điều gì đã xảy ra?"</td><td>Loki, Elasticsearch, Fluentd</td></tr>
+<tr><td><strong>Traces</strong></td><td>Luồng request qua nhiều services</td><td>"Request đi qua đâu và mất bao lâu?"</td><td>Jaeger, Zipkin, Tempo</td></tr>
+</tbody>
+</table>
+
+<pre><code class="language-text">User request fails → Use 3 pillars:
+
+  METRICS: CPU spike at 14:05?
+  LOGS: Error "DB timeout" in service B  
+  TRACES: Request A→B→C, step B took 8s  
+
+  → Root cause: Service B DB connection pool exhausted</code></pre>
+
+<blockquote><p><strong>Exam tip:</strong> KCNA thường hỏi "welche tool" cho từng pillar. Prometheus = metrics. Grafana = visualization. Jaeger = distributed tracing. Loki = log aggregation.</p></blockquote>
+
+<h2 id="prometheus">2. Prometheus & Metrics</h2>
+
+<p><strong>Prometheus</strong> là CNCF graduated project cho monitoring và alerting. Pull-based: Prometheus scrapes metrics từ targets.</p>
+
+<pre><code class="language-text">Prometheus Architecture:
+  App (exposes /metrics)
+       ↑ scrape
+  Prometheus Server ──► Alert Manager ──► Slack/PagerDuty
+       │
+  Grafana (query PromQL → charts)</code></pre>
+
+<table>
+<thead><tr><th>Metric Type</th><th>Ý nghĩa</th><th>Ví dụ</th></tr></thead>
+<tbody>
+<tr><td><strong>Counter</strong></td><td>Chỉ tăng (reset khi restart)</td><td>http_requests_total</td></tr>
+<tr><td><strong>Gauge</strong></td><td>Tăng/giảm tự do</td><td>memory_usage_bytes</td></tr>
+<tr><td><strong>Histogram</strong></td><td>Distribution, quantile</td><td>request_duration_seconds</td></tr>
+<tr><td><strong>Summary</strong></td><td>Pre-computed quantiles</td><td>response_size_summary</td></tr>
+</tbody>
+</table>
+
+<h2 id="opentelemetry">3. OpenTelemetry (OTel)</h2>
+
+<p><strong>OpenTelemetry</strong> là CNCF standard cho thu thập telemetry (metrics, logs, traces) với vendor-neutral SDK và Collector.</p>
+
+<pre><code class="language-text">OpenTelemetry Flow:
+  App (instrumented with OTel SDK)
+       │ OTLP (protocol)
+  OTel Collector (receive, process, export)
+       │
+  ┌────┴────┐
+ Jaeger   Prometheus   Loki
+(traces)  (metrics)   (logs)</code></pre>
+
+<blockquote><p><strong>Exam tip:</strong> OpenTelemetry tách vendor-specific code ra khỏi apps — chỉ cần thay đổi OTel Collector config để switch từ Jaeger sang Zipkin mà không cần sửa app code.</p></blockquote>
+
+<h2 id="k8s-observability">4. Observability trong Kubernetes</h2>
+
+<table>
+<thead><tr><th>Component</th><th>Cung cấp</th></tr></thead>
+<tbody>
+<tr><td><strong>kubelet /metrics</strong></td><td>Node resource metrics cho Prometheus</td></tr>
+<tr><td><strong>metrics-server</strong></td><td>CPU/Memory cho kubectl top, HPA</td></tr>
+<tr><td><strong>kube-state-metrics</strong></td><td>Kubernetes object state (Pod, Deployment status)</td></tr>
+<tr><td><strong>Prometheus Operator</strong></td><td>Deploy Prometheus stack với CRDs (ServiceMonitor)</td></tr>
+<tr><td><strong>Loki + Promtail</strong></td><td>Log aggregation (Promtail thu thập logs từ nodes)</td></tr>
+</tbody>
+</table>
+
+<h3 id="kubectl-debug">kubectl debugging commands</h3>
+
+<pre><code class="language-text">kubectl logs pod-name              # Current container logs
+kubectl logs pod-name --previous   # Last crashed container logs
+kubectl logs -f pod-name           # Stream live logs
+kubectl describe pod pod-name      # Events + status details
+kubectl top pod                    # CPU/Memory (needs metrics-server)
+kubectl top node                   # Node resource usage</code></pre>
+
+<h2 id="cheatsheet">5. Cheat Sheet</h2>
+
+<table>
+<thead><tr><th>Câu hỏi exam</th><th>Đáp án</th></tr></thead>
+<tbody>
+<tr><td>3 pillars of observability?</td><td><strong>Metrics, Logs, Traces</strong></td></tr>
+<tr><td>Distributed tracing tool?</td><td><strong>Jaeger</strong>, Zipkin, Tempo</td></tr>
+<tr><td>Kubernetes metrics collection?</td><td><strong>Prometheus</strong></td></tr>
+<tr><td>Visualization dashboard?</td><td><strong>Grafana</strong></td></tr>
+<tr><td>Vendor-neutral telemetry standard?</td><td><strong>OpenTelemetry</strong></td></tr>
+<tr><td>kubectl top cần gì?</td><td><strong>metrics-server</strong></td></tr>
+</tbody>
+</table>
+
+<h2 id="practice">6. Practice Questions</h2>
+
+<p><strong>Q1:</strong> A team needs to trace how a single HTTP request flows through 5 microservices to find which service adds the most latency. Which observability tool should they use?</p>
+<ul>
+<li>A) Prometheus</li>
+<li>B) Grafana</li>
+<li>C) Jaeger ✓</li>
+<li>D) Loki</li>
+</ul>
+<p><em>Explanation: Distributed tracing (Jaeger, Zipkin) tracks a request's entire flow across multiple services, showing each hop's latency and relationships. Prometheus shows aggregate metrics; Loki shows logs; Grafana is visualization.</em></p>
+
+<p><strong>Q2:</strong> What type of Prometheus metric would you use to track the total number of HTTP requests served since startup?</p>
+<ul>
+<li>A) Gauge</li>
+<li>B) Histogram</li>
+<li>C) Counter ✓</li>
+<li>D) Summary</li>
+</ul>
+<p><em>Explanation: Counter is a monotonically increasing metric — it only goes up (or resets to 0 on restart). Perfect for tracking cumulative events like requests, errors, or bytes transferred. Gauge is for values that go up and down (like memory usage).</em></p>
+
+<p><strong>Q3:</strong> Which framework allows developers to instrument their application once and export telemetry to multiple backends (Jaeger, Prometheus, etc.) without code changes?</p>
+<ul>
+<li>A) Prometheus client libraries</li>
+<li>B) OpenTelemetry ✓</li>
+<li>C) Kubernetes metrics-server</li>
+<li>D) Grafana Agent</li>
+</ul>
+<p><em>Explanation: OpenTelemetry provides vendor-neutral APIs and SDKs for generating traces, metrics, and logs. The OTel Collector routes telemetry to different backends. Switching backends requires only Collector config changes, not application code.</em></p>

package/content/series/luyen-thi/luyen-thi-kcna/chapters/04-observability-delivery/lessons/09-helm-gitops-cicd.md

@@ -0,0 +1,162 @@
+---
+id: kcna-d4-l09
+title: 'Bài 9: Helm, GitOps & CI/CD'
+slug: 09-helm-gitops-cicd
+description: >-
+  Helm package manager, GitOps với Argo CD, CI/CD pipelines cho Kubernetes.
+  Deployment strategies: rolling update, canary, blue-green.
+duration_minutes: 60
+is_free: true
+video_url: null
+sort_order: 9
+section_title: "Domain 4: Cloud Native Observability & Security (16%)"
+course:
+  id: lt-kcna-series-001
+  title: 'Luyện thi KCNA — Kubernetes and Cloud Native Associate'
+  slug: luyen-thi-kcna
+---
+
+<img src="/storage/uploads/2026/04/k8s-cert-kcna-bai9-helm-gitops.png" alt="GitOps Workflow với Helm và Argo CD" style="max-width: 800px; width: 100%; border-radius: 12px;" />
+
+<h2 id="helm">1. Helm — Kubernetes Package Manager</h2>
+
+<p><strong>Helm</strong> là package manager cho Kubernetes. Charts là template YAML có thể reuse và parameterize.</p>
+
+<pre><code class="language-text">Helm Concepts:
+  Chart     = Package (templates + default values)
+  Release   = Installed instance of a chart in a cluster
+  Repository = Collection of charts (ArtifactHub.io)
+  Values    = Parameters to customize a chart
+
+$ helm install my-nginx bitnami/nginx --set service.type=LoadBalancer
+  └── Release: my-nginx
+      ├── templates/deployment.yaml
+      ├── templates/service.yaml
+      └── values.yaml (overridden)</code></pre>
+
+<table>
+<thead><tr><th>Helm Command</th><th>Chức năng</th></tr></thead>
+<tbody>
+<tr><td><code>helm install</code></td><td>Deploy chart mới (tạo release)</td></tr>
+<tr><td><code>helm upgrade</code></td><td>Update release với chart mới/values mới</td></tr>
+<tr><td><code>helm rollback</code></td><td>Khôi phục về revision trước</td></tr>
+<tr><td><code>helm list</code></td><td>Liệt kê tất cả releases</td></tr>
+<tr><td><code>helm uninstall</code></td><td>Xóa release</td></tr>
+<tr><td><code>helm template</code></td><td>Render templates mà không deploy</td></tr>
+</tbody>
+</table>
+
+<blockquote><p><strong>Exam tip:</strong> Helm lưu release history trong Kubernetes Secrets (không phải ConfigMap). Điều này cho phép <code>helm rollback</code> hoạt động. History mặc định giữ 10 revisions.</p></blockquote>
+
+<h2 id="gitops">2. GitOps</h2>
+
+<p><strong>GitOps</strong> là operational framework dùng Git làm <strong>single source of truth</strong> cho cả code lẫn infrastructure config.</p>
+
+<pre><code class="language-text">GitOps Flow:
+  Developer ──push──► Git Repo (desired state)
+                          │
+                    GitOps Operator (Argo CD / Flux)
+                    - Watches Git repo
+                    - Compares with cluster state
+                    - Syncs if diff found
+                          │
+                       K8s Cluster (actual state)</code></pre>
+
+<table>
+<thead><tr><th>GitOps Principle</th><th>Ý nghĩa</th></tr></thead>
+<tbody>
+<tr><td><strong>Declarative</strong></td><td>System state mô tả bằng YAML trong Git</td></tr>
+<tr><td><strong>Versioned & immutable</strong></td><td>Git history = audit trail</td></tr>
+<tr><td><strong>Pulled automatically</strong></td><td>Agent pull changes, không cần push access vào cluster</td></tr>
+<tr><td><strong>Continuously reconciled</strong></td><td>Drift detection — auto-correct nếu cluster khác Git</td></tr>
+</tbody>
+</table>
+
+<h3 id="argo-cd">Argo CD</h3>
+
+<p><strong>Argo CD</strong> là GitOps controller phổ biến nhất cho Kubernetes (CNCF Incubating → Graduated 2022).</p>
+
+<blockquote><p><strong>Exam tip:</strong> GitOps dùng <strong>pull-based</strong> deployment thay vì push. Lợi ích: cluster không cần expose API ra bên ngoài, CI pipeline không cần kubeconfig credentials.</p></blockquote>
+
+<h2 id="cicd">3. CI/CD cho Kubernetes</h2>
+
+<pre><code class="language-text">CI/CD Pipeline:
+  Code Push
+      │
+  ┌───▼───┐  CI Phase (Build)
+  │ Build  │── Unit tests ── Integration tests
+  │ Image  │── Security scan (Trivy, Snyk)
+  └───┬───┘── Push to Registry (ECR, GCR)
+      │
+  ┌───▼───┐  CD Phase (Deploy)
+  │ Update │── Update Helm values / K8s manifest
+  │ Manifest│── Push to GitOps repo
+  └───┬───┘── Argo CD picks up and syncs
+      │
+  ┌───▼────────────────────┐
+  │ Kubernetes Cluster     │
+  │  Rolling Update        │
+  └────────────────────────┘</code></pre>
+
+<h2 id="deployment-strategies">4. Deployment Strategies</h2>
+
+<table>
+<thead><tr><th>Strategy</th><th>Cách hoạt động</th><th>Downtime</th><th>Rollback</th><th>Dùng khi</th></tr></thead>
+<tbody>
+<tr><td><strong>Rolling Update</strong></td><td>Replace pods gradually (default)</td><td>Không</td><td>kubectl rollout undo</td><td>Stateless apps, gradual</td></tr>
+<tr><td><strong>Recreate</strong></td><td>Kill all v1, then deploy v2</td><td>Có</td><td>Redeploy v1</td><td>Breaking changes, simple</td></tr>
+<tr><td><strong>Blue-Green</strong></td><td>Run v1 (blue) + v2 (green) side by side, switch traffic</td><td>Không</td><td>Switch back instantly</td><td>Kritisch apps, fast rollback</td></tr>
+<tr><td><strong>Canary</strong></td><td>Route small % traffic to new version</td><td>Không</td><td>Redirect traffic</td><td>Staged rollout, A/B testing</td></tr>
+</tbody>
+</table>
+
+<pre><code class="language-text">Canary in Kubernetes (Ingress weight):
+  ┌─────────────────────────────────┐
+  │  Ingress (canary annotation)     │
+  │  90% ──────► Deployment v1.0    │
+  │  10% ──────► Deployment v1.1    │
+  └─────────────────────────────────┘
+  → Monitor v1.1 errors → promote to 100% or rollback</code></pre>
+
+<h2 id="cheatsheet">5. Cheat Sheet</h2>
+
+<table>
+<thead><tr><th>Câu hỏi exam</th><th>Đáp án</th></tr></thead>
+<tbody>
+<tr><td>Helm lưu release history ở đâu?</td><td><strong>Kubernetes Secrets</strong></td></tr>
+<tr><td>GitOps single source of truth?</td><td><strong>Git repository</strong></td></tr>
+<tr><td>GitOps dùng pull hay push?</td><td><strong>Pull-based</strong> (agent pulls)</td></tr>
+<tr><td>Deployment không có downtime?</td><td><strong>Rolling</strong> hoặc <strong>Blue-Green</strong></td></tr>
+<tr><td>Test new version với 5% traffic?</td><td><strong>Canary</strong> deployment</td></tr>
+<tr><td>Fast rollback khi có issue?</td><td><strong>Blue-Green</strong> (instant switch)</td></tr>
+</tbody>
+</table>
+
+<h2 id="practice">6. Practice Questions</h2>
+
+<p><strong>Q1:</strong> A team wants to deploy a new version of their app to 10% of users first, monitor for errors, then gradually increase traffic. Which deployment strategy should they use?</p>
+<ul>
+<li>A) Recreate</li>
+<li>B) Rolling Update</li>
+<li>C) Blue-Green</li>
+<li>D) Canary ✓</li>
+</ul>
+<p><em>Explanation: Canary deployment routes a small percentage of traffic to the new version, allowing teams to validate it with real traffic before full rollout. This minimizes blast radius if the new version has bugs.</em></p>
+
+<p><strong>Q2:</strong> Which of the following best describes the GitOps model?</p>
+<ul>
+<li>A) CI/CD pipeline pushes directly to Kubernetes after tests pass</li>
+<li>B) Git repository is the single source of truth; a controller continuously reconciles cluster state with Git ✓</li>
+<li>C) Developers manually apply kubectl commands from their workstations</li>
+<li>D) Infrastructure is defined in a relational database for consistency</li>
+</ul>
+<p><em>Explanation: GitOps uses a pull-based model where a controller (Argo CD, Flux) watches a Git repository and ensures the cluster matches what's declared in Git. This provides audit trail, drift detection, and secure deployments.</em></p>
+
+<p><strong>Q3:</strong> Where does Helm store release history to enable rollback capability?</p>
+<ul>
+<li>A) Helm's local filesystem (~/.helm)</li>
+<li>B) ConfigMap in the target namespace</li>
+<li>C) Secret in the target namespace ✓</li>
+<li>D) A separate etcd database</li>
+</ul>
+<p><em>Explanation: Since Helm v3, release metadata (history, values, chart info) is stored as Secrets in the release's namespace. This enables helm rollback by reading previous revision data, and allows multiple users/systems to manage the same release.</em></p>

package/content/series/luyen-thi/luyen-thi-kcna/index.md

@@ -0,0 +1,168 @@
+---
+id: lt-kcna-series-001
+title: "Luyện thi KCNA — Kubernetes and Cloud Native Associate"
+slug: luyen-thi-kcna
+description: >-
+  Lộ trình ôn tập toàn diện cho kỳ thi KCNA (Kubernetes and Cloud Native Associate).
+  Bao phủ đầy đủ 5 domain: Kubernetes Fundamentals (46%), Container Orchestration (22%),
+  Cloud Native Architecture (16%), Observability (8%), Application Delivery (8%).
+  9 bài học chuyên sâu kèm bài tập trắc nghiệm tiếng Anh.
+
+featured_image: images/blog/luyen-thi-kcna-banner.png
+level: beginner
+duration_hours: 20
+lesson_count: 9
+price: '0.00'
+is_free: true
+view_count: 0
+average_rating: '0.00'
+review_count: 0
+enrollment_count: 0
+meta: null
+published_at: '2026-04-05T10:00:00.000000Z'
+created_at: '2026-04-05T10:00:00.000000Z'
+
+author:
+  id: 019c9616-d2b4-713f-9b2c-40e2e92a05cf
+  name: Duy Tran
+  avatar: avatars/7e8eb5c6-4cac-455b-a701-4060f085d501.jpeg
+
+category:
+  id: 019c9616-cat9-7009-a009-000000000009
+  name: Luyện thi chứng chỉ
+  slug: luyen-thi
+
+tags:
+
+- name: Kubernetes
+  slug: kubernetes
+- name: CNCF
+  slug: cncf
+- name: Cloud Native
+  slug: cloud-native
+- name: Chứng chỉ
+  slug: chung-chi
+- name: DevOps
+    slug: devops
+
+quiz_slug: kcna
+
+ctions:
+
+- id: kcna-section-01
+    title: "Domain 1: Kubernetes Fundamentals (46%)"
+    description: Kiến trúc K8s, core objects, networking, storage, RBAC
+sort_order: 1
+    lessons:
+  - id: kcna-d1-l01
+        title: "Bài 1: Kubernetes Architecture & Core Components"
+        slug: 01-kien-truc-kubernetes
+        description: >-
+          Control plane vs Worker node. kube-apiserver, etcd, kube-scheduler,
+          controller-manager, kubelet, kube-proxy. Kubernetes objects overview.
+        duration_minutes: 55
+        is_free: true
+    sort_order: 1
+        video_url: null
+  - id: kcna-d1-l02
+        title: "Bài 2: Pods, Workloads & Controllers"
+        slug: 02-pods-workloads-controllers
+        description: >-
+          Pod lifecycle. Deployments, ReplicaSets, StatefulSets, DaemonSets,
+          Jobs, CronJobs. Labels, selectors, annotations.
+        duration_minutes: 55
+        is_free: true
+    sort_order: 2
+        video_url: null
+  - id: kcna-d1-l03
+        title: "Bài 3: Services, Networking & Storage"
+        slug: 03-services-networking-storage
+        description: >-
+          ClusterIP, NodePort, LoadBalancer. CoreDNS, Service discovery.
+          PersistentVolume, PVC, StorageClass. ConfigMaps & Secrets.
+        duration_minutes: 55
+        is_free: true
+    sort_order: 3
+        video_url: null
+  - id: kcna-d1-l04
+        title: "Bài 4: RBAC & Security Basics"
+        slug: 04-rbac-security
+        description: >-
+          Role, ClusterRole, RoleBinding, ClusterRoleBinding. ServiceAccounts.
+          Pod Security Standards. Network Policies overview.
+        duration_minutes: 50
+        is_free: true
+        sort_order: 4
+      video_url: null
+
+- id: kcna-section-02
+    title: "Domain 2: Container Orchestration (22%)"
+    description: Container runtimes, OCI, container lifecycle, orchestration patterns
+sort_order: 2
+    lessons:
+  - id: kcna-d2-l01
+        title: "Bài 5: Container Runtimes & OCI Standards"
+        slug: 05-container-runtimes-oci
+        description: >-
+          Docker vs containerd vs CRI-O. OCI Image Spec, OCI Runtime Spec.
+          Container lifecycle. Image layers và registry.
+        duration_minutes: 50
+        is_free: true
+    sort_order: 5
+        video_url: null
+  - id: kcna-d2-l02
+        title: "Bài 6: Container Orchestration Patterns"
+        slug: 06-orchestration-patterns
+        description: >-
+          Scheduling, resource management, high availability.
+          Multi-tenancy. Namespace isolation. Resource quotas.
+          Horizontal Pod Autoscaler, Vertical Pod Autoscaler.
+        duration_minutes: 50
+        is_free: true
+        sort_order: 6
+      video_url: null
+
+- id: kcna-section-03
+    title: "Domain 3: Cloud Native Architecture (16%)"
+    description: 12-factor app, microservices, service mesh, serverless
+sort_order: 3
+    lessons:
+  - id: kcna-d3-l01
+        title: "Bài 7: Cloud Native Architecture & Design Patterns"
+        slug: 07-cloud-native-architecture
+        description: >-
+          12-factor app methodology. Microservices vs Monolith.
+          Immutable infrastructure. Service mesh (Istio, Linkerd overview).
+          Serverless computing. CNCF landscape.
+        duration_minutes: 55
+        is_free: true
+        sort_order: 7
+      video_url: null
+
+- id: kcna-section-04
+    title: "Domain 4 & 5: Observability & Application Delivery (16%)"
+    description: Logging, monitoring, tracing, Helm, GitOps, CI/CD
+sort_order: 4
+    lessons:
+  - id: kcna-d4-l01
+        title: "Bài 8: Cloud Native Observability"
+        slug: 08-observability
+        description: >-
+          Logging với Fluentd/Loki. Metrics với Prometheus & Grafana.
+          Distributed tracing với Jaeger/Zipkin. OpenTelemetry.
+          Alerting và SLO/SLI/SLA.
+        duration_minutes: 50
+        is_free: true
+    sort_order: 8
+        video_url: null
+  - id: kcna-d5-l01
+        title: "Bài 9: Application Delivery — Helm, GitOps & CI/CD"
+        slug: 09-helm-gitops-cicd
+        description: >-
+          Helm charts, values, templates. GitOps với ArgoCD & Flux.
+          CI/CD pipelines cho Kubernetes. Kustomize basics.
+          Progressive delivery (canary, blue-green).
+        duration_minutes: 50
+        is_free: true
+        sort_order: 9
+        video_url: null