diff --git a/.github/settings.yml b/.github/settings.yml
index c9e9f86f17..f123924262 100644
--- a/.github/settings.yml
+++ b/.github/settings.yml
@@ -223,13 +223,13 @@ collaborators:
   - username: aliok
     permission: push
 
-  - username: symys
+  - username: canogluonur
     permission: push
 
-  - username: rwxdash
+  - username: mertssmnoglu
     permission: push
 
-  - username: eminalemdar
+  - username: alianait
     permission: push
 
   # l10n ru approvers
@@ -527,9 +527,9 @@ branches:
         # tr approvers
         users:
          - aliok
-         - symys
-         - rwxdash
-         - eminalemdar
+         - canogluonur
+         - mertssmnoglu
+         - alianait
         teams: []
       enforce_admins: null
       required_linear_history: null
diff --git a/.github/workflows/es-spellcheck.yml b/.github/workflows/es-spellcheck.yml
index 1030637b1c..5bb5534066 100644
--- a/.github/workflows/es-spellcheck.yml
+++ b/.github/workflows/es-spellcheck.yml
@@ -29,6 +29,6 @@ jobs:
           set -o errexit
           diff content/es/.wordlist.txt <(LC_ALL= sort -f content/es/.wordlist.txt)
       - name: GitHub Spellcheck Action
-        uses: rojopolis/spellcheck-github-actions@0.49.0
+        uses: rojopolis/spellcheck-github-actions@0.51.0
         with:
           config_path: content/es/.spellcheck.yml
diff --git a/.github/workflows/post-outdated-content-report.yaml b/.github/workflows/post-outdated-content-report.yaml
index 30cca8368d..ccb63c47ef 100644
--- a/.github/workflows/post-outdated-content-report.yaml
+++ b/.github/workflows/post-outdated-content-report.yaml
@@ -50,7 +50,7 @@ jobs:
 #     - name: Download output
 #       uses: actions/download-artifact@v3
     - name: Download output
-      uses: dawidd6/action-download-artifact@v9
+      uses: dawidd6/action-download-artifact@v11
       with:
         github_token: ${{secrets.GITHUB_TOKEN}}
         workflow: check-outdated-content.yaml
diff --git a/.github/workflows/spellcheck.yml b/.github/workflows/spellcheck.yml
index 7c1464a849..e675f366c2 100644
--- a/.github/workflows/spellcheck.yml
+++ b/.github/workflows/spellcheck.yml
@@ -25,4 +25,4 @@ jobs:
       - uses: actions/checkout@v4
 
       - name: GitHub Spellcheck Action
-        uses: rojopolis/spellcheck-github-actions@0.49.0
+        uses: rojopolis/spellcheck-github-actions@0.51.0
diff --git a/CODEOWNERS b/CODEOWNERS
index 17f4888e8d..25ecd5e1b6 100644
--- a/CODEOWNERS
+++ b/CODEOWNERS
@@ -63,8 +63,8 @@
 /i18n/ru.toml @shurup @kirkonru @tym83
 
 # Approvers for Turkish contents
-/content/tr/ @aliok @symys @rwxdash @eminalemdar
-/i18n/tr.toml @aliok @symys @rwxdash @eminalemdar
+/content/tr/ @aliok @canogluonur @mertssmnoglu @alianait
+/i18n/tr.toml @aliok @canogluonur @mertssmnoglu @alianait
 
 # Approvers for Urdu contents
 /content/ur/ @Saim-Safdar @waleed318
diff --git a/content/en/operator.md b/content/en/operator.md
new file mode 100644
index 0000000000..a9108bfcbb
--- /dev/null
+++ b/content/en/operator.md
@@ -0,0 +1,40 @@
+---
+title: Kubernetes Operator
+status: Completed
+category: concept
+tags: ["infrastructure"]
+---
+
+A Kubernetes Operator is a helper program that runs inside a Kubernetes cluster 
+and extends its capabilities without modifying the core code, 
+enabling the automated installation and management of complex applications and resources.
+
+## Problem it addresses
+
+When we want to run a complex [stateful](/stateful-apps/) application like a database cluster for instance, 
+we need to take care of a lot of operational tasks in order to keep it up and running. 
+This is especially true for properties like the high availability and the zero downtime. 
+How does the cluster behave in case of an update or failure? 
+How can we securely scale it up or down? 
+These are things that are very specific to the type of technology, 
+because not every database cluster for instance behaves the same way in case of scaling or failure. 
+That is why Kubernetes cannot provide a general handling of these scenarios. 
+Also, this knowledge is usually known and executed by a human administrator or also called operator.  
+But in the highly automated cloud native world we cannot always afford to be dependent on manual interactions of a person to do these critical operations. 
+
+## How it helps
+
+The Kubernetes Operator is basically an abstraction, a model, 
+that allows us to build resources that can be used to help us with the above mentioned problems. 
+Typically, existing operators provide a set of new resources - known as CRDs (Custom Resource Definition) - 
+as well as components that are responsible for keeping the actual state of the cluster in sync with the desired state. 
+If we take a database cluster operator for instance, 
+these components know exactly how to scale this cluster up and down 
+and what to do if it crashes etc. 
+This way we don't need to be experts in that specific technology in order to use it in our Kubernetes cluster and make use of scaling or other specific features. 
+
+## Related terms
+
+* [Stateless applications](/stateless-apps/)
+* [Stateful applications](/stateful-apps/)
+* [Clusters](/cluster/)
\ No newline at end of file
diff --git a/content/vi/_index.md b/content/vi/_index.md
index d4bfe33648..d371be82af 100755
--- a/content/vi/_index.md
+++ b/content/vi/_index.md
@@ -48,7 +48,7 @@ và [Junya Okabe](https://www.linkedin.com/in/junya-okabe/).
 là những Maintainer Danh dự, và chúng tôi vô cùng biết ơn
 những đóng góp quý báu của họ trong suốt những năm qua.
 
-Bản dịch tiếng Việt của Cloud Native Glossary đã được khởi xướng nhờ sự đóng góp của [The Anh Nguyen](https://www.linkedin.com/in/ntheanh201/), [Thuan Pham Tien](https://www.linkedin.com/in/tienthuan05082002/), [Phuong Thao Nguyen](https://www.linkedin.com/in/nguyenphuongthao0/), [trieungoctam](https://www.linkedin.com/in/trieungoctam/), [Huan Nguyen Danh](https://www.linkedin.com/in/huannd2301/). Nếu bạn quan tâm đến việc dịch và bản địa hóa Cloud Native Glossary sang tiếng Việt, vui lòng tham gia kênh [#glossary-localization-vietnamese](https://cloud-native.slack.com/archives/C08NAHYA6KX).
+Bản dịch tiếng Việt của Cloud Native Glossary đã được khởi xướng nhờ sự đóng góp của [The Anh Nguyen](https://www.linkedin.com/in/ntheanh201/), [Thuan Pham Tien](https://www.linkedin.com/in/tienthuan05082002/), [Phuong Thao Nguyen](https://www.linkedin.com/in/nguyenphuongthao0/), [trieungoctam](https://www.linkedin.com/in/trieungoctam/), [Huan Nguyen Danh](https://www.linkedin.com/in/huannd2301/), [Trung Thi Phuong](https://www.linkedin.com/in/phuong-trung-thi-9bba12215/). Nếu bạn quan tâm đến việc dịch và bản địa hóa Cloud Native Glossary sang tiếng Việt, vui lòng tham gia kênh [#glossary-localization-vietnamese](https://cloud-native.slack.com/archives/C08NAHYA6KX).
 
 ## Giấy phép
 
diff --git a/content/vi/auto-scaling.md b/content/vi/auto-scaling.md
new file mode 100644
index 0000000000..2aa9688070
--- /dev/null
+++ b/content/vi/auto-scaling.md
@@ -0,0 +1,21 @@
+---
+title: Tự động mở rộng (Autoscaling)
+status: Completed
+category: property
+tags: ["infrastructure", "", ""]
+---
+
+Tự động mở rộng là khả năng của một hệ thống có thể [mở rộng](/scalability/) tự động, thường là về mặt tài nguyên tính toán. Với một hệ thống có khả năng tự động mở rộng, tài nguyên sẽ được bổ sung tự động khi cần và có thể mở rộng để đáp ứng sự biến động về lượng nhu cầu người dùng.
+Quy trình tự động mở rộng có thể khác nhau và có thể cấu hình để mở rộng dựa trên các chỉ số khác biệt, chẳng hạn như bộ nhớ hoặc thời gian xử lý. Các dịch vụ đám mây được quản lý thường đi kèm với chức năng tự động mở rộng vì có nhiều lựa chọn và cách triển khai hơn so với hầu hết các hệ thống triển khai tại chỗ (on-premise deployments).
+
+Trước đây, hạ tầng và ứng dụng được thiết kế để tính đến mức sử dụng hệ thống cao nhất. Kiến trúc này khiến nhiều tài nguyên bị sử dụng không hiệu quả và thiếu khả năng co giãn trước sự thay đổi lượng nhu cầu người dùng. Sự thiếu linh hoạt này dẫn đến chi phí cao hơn cho doanh nghiệp và mất doanh thu do hệ thống ngừng hoạt động khi vượt quá tải.
+
+Bằng cách tận dụng điện toán đám mây, [ảo hoá](/virtualization/) và [container hóa](/containerization/) các ứng dụng cùng các phần phụ thuộc, các tổ chức có thể xây dựng ứng dụng có khả năng mở rộng theo nhu cầu người dùng. Họ có thể theo dõi nhu cầu sử dụng ứng dụng và tự động mở rộng, mang lại trải nghiệm người dùng tối ưu.
+Lấy ví dụ về sự gia tăng lượt xem mà Netflix ghi nhận vào mỗi tối thứ Sáu. Mở rộng theo chiều ngang (autoscaling out) có nghĩa là tự động bổ sung thêm tài nguyên: ví dụ, tăng số lượng máy chủ để cho phép phát video nhiều hơn, và thu hẹp lại khi mức sử dụng trở về bình thường.
+
+## Thuật ngữ liên quan
+
+* [Mở rộng theo chiều ngang](/horizontal-scaling/)
+* [Mở rộng theo chiều dọc](/vertical-scaling/)
+
+{{% sign-language-section cGONmC1smaM %}}
\ No newline at end of file
diff --git a/content/vi/continuous-delivery.md b/content/vi/continuous-delivery.md
new file mode 100644
index 0000000000..012cc74d66
--- /dev/null
+++ b/content/vi/continuous-delivery.md
@@ -0,0 +1,35 @@
+---
+title: Phân phối liên tục (Continuous Delivery - CD)
+status: Completed
+category: concept
+tags: ["methodology", "application", ""]
+---
+
+Phân phối liên tục (Continuous delivery), thường được viết tắt là CD, là một tập hợp các phương pháp
+trong đó các thay đổi mã nguồn được tự động triển khai vào môi trường kiểm thử (acceptance environment)
+(hoặc, trong trường hợp triển khai liên tục, vào môi trường sản xuất).
+CD bao gồm các quy trình quan trọng để đảm bảo phần mềm được kiểm thử đầy đủ
+trước khi triển khai và cung cấp cách thức để hoàn tác các thay đổi nếu cần thiết.
+[Tích hợp liên tục](/continuous-integration/) (CI) là bước đầu tiên hướng tới
+phân phối liên tục (tức là, các thay đổi phải được hợp nhất một cách sạch sẽ trước khi được kiểm thử và
+triển khai).
+
+## Vấn đề nó giải quyết
+
+Triển khai các bản cập nhật [đáng tin cậy](/reliability/) trở thành vấn đề khi mở rộng quy mô.
+Lý tưởng nhất, chúng ta nên triển khai thường xuyên hơn để mang lại giá trị tốt hơn cho người dùng cuối.
+Tuy nhiên, thực hiện thủ công dẫn đến chi phí giao dịch cao cho mỗi thay đổi.
+Trong quá khứ, để tránh những chi phí này, các tổ chức đã phát hành ít thường xuyên hơn,
+triển khai nhiều thay đổi cùng một lúc và làm tăng nguy cơ xảy ra sự cố.
+
+## Lợi ích mang lại
+
+Các chiến lược CD tạo ra một lối đi hoàn toàn tự động đến môi trường sản xuất
+để kiểm thử và triển khai phần mềm bằng cách sử dụng các chiến lược triển khai khác nhau
+như [canary](/canary-deployment/) hoặc [blue-green](/blue-green-deployment/).
+Điều này cho phép các nhà phát triển triển khai mã nguồn thường xuyên, giúp họ yên tâm rằng phiên bản mới đã được kiểm thử.
+
+## Thuật ngữ liên quan
+
+* [Tích hợp liên tục](/continuous-integration/)
+* [Triển khai liên tục](/continuous-deployment/)
diff --git a/content/vi/continuous-deployment.md b/content/vi/continuous-deployment.md
new file mode 100644
index 0000000000..233ab32cc1
--- /dev/null
+++ b/content/vi/continuous-deployment.md
@@ -0,0 +1,33 @@
+---
+title: Triển khai liên tục (Continuous Deployment - CD)
+status: Completed
+category: concept
+tags: ["application", "methodology", ""]
+---
+
+Triển khai liên tục (Continuous Deployment), thường được viết tắt là CD, là một bước xa hơn của [phân phối liên tục](/continuous-delivery/)
+bằng cách triển khai phần mềm hoàn chỉnh trực tiếp vào môi trường sản xuất.
+Triển khai liên tục (CD) đi đôi với [tích hợp liên tục](/continuous-integration/) (CI),
+và thường được gọi là CI/CD.
+Quy trình CI kiểm tra xem các thay đổi đối với một ứng dụng nhất định có hợp lệ hay không,
+và quy trình CD tự động triển khai các thay đổi mã nguồn qua các môi trường của tổ chức từ kiểm thử đến production.
+
+## Vấn đề nó giải quyết
+
+Phát hành các phiên bản phần mềm mới có thể là một quá trình tốn nhiều công sức và dễ xảy ra lỗi.
+Đây cũng thường là điều mà các tổ chức chỉ muốn thực hiện không thường xuyên để tránh các sự cố trên môi trường production
+và giảm số lượng thời gian kỹ sư cần phải làm việc ngoài giờ làm việc thông thường.
+Các mô hình triển khai phần mềm truyền thống khiến các tổ chức rơi vào một vòng luẩn quẩn
+trong đó quy trình phát hành phần mềm không đáp ứng được nhu cầu của tổ chức về cả tính ổn định và tốc độ phát triển tính năng.
+
+## Lợi ích mang lại
+
+Bằng cách tự động hóa chu kỳ phát hành và buộc các tổ chức phải phát hành lên môi trường sản xuất thường xuyên hơn,
+CD mang lại cho các nhóm vận hành những lợi ích tương tự như CI đã mang lại cho các nhóm phát triển.
+Cụ thể, nó buộc các nhóm vận hành phải tự động hóa các phần triển khai trên môi trường production khó khăn và dễ xảy ra lỗi, giảm rủi ro tổng thể.
+Nó cũng giúp các tổ chức chấp nhận và thích ứng tốt hơn với các thay đổi trên môi trường production, dẫn đến tính ổn định cao hơn.
+
+## Thuật ngữ liên quan
+
+* [Tích hợp liên tục](/continuous-integration/)
+* [Phân phối liên tục](/continuous-delivery/)
diff --git a/content/vi/continuous-integration.md b/content/vi/continuous-integration.md
new file mode 100644
index 0000000000..f1eff48372
--- /dev/null
+++ b/content/vi/continuous-integration.md
@@ -0,0 +1,31 @@
+---
+title: Tích hợp liên tục (Continuous integration - CI)
+status: Completed 
+category: concept
+tags: ["application", "methodology", ""]
+---
+
+Tích hợp liên tục (Continuous integration), thường được viết tắt là CI, là phương pháp tích hợp các thay đổi mã nguồn thường xuyên nhất có thể.
+CI là điều kiện tiên quyết cho [phân phối liên tục](/continuous-delivery/) (CD).
+Thông thường, quy trình CI bắt đầu khi các thay đổi mã nguồn được commit vào hệ thống kiểm soát mã nguồn (Git, Mercurial, hoặc Subversion)
+và kết thúc với một sản phẩm đã được kiểm thử sẵn sàng để được sử dụng bởi hệ thống CD.
+
+## Vấn đề nó giải quyết
+
+Các hệ thống phần mềm thường lớn và phức tạp, với nhiều nhà phát triển bảo trì và cập nhật chúng.
+Làm việc song song trên các phần khác nhau của hệ thống,
+các nhà phát triển này có thể tạo ra các thay đổi xung đột và vô tình phá vỡ công việc của nhau.
+Ngoài ra, với nhiều nhà phát triển làm việc trên cùng một dự án,
+bất kỳ công việc hàng ngày nào như kiểm thử và đánh giá chất lượng mã nguồn đều cần được lặp lại bởi mỗi nhà phát triển, lãng phí thời gian.
+
+## Lợi ích mang lại
+
+Phần mềm CI tự động kiểm tra xem các thay đổi mã nguồn có được hợp nhất một cách sạch sẽ hay không mỗi khi nhà phát triển commit một thay đổi.
+Đó là một phương pháp gần như phổ biến để sử dụng máy chủ CI để chạy đánh giá chất lượng mã nguồn, kiểm thử, và thậm chí là triển khai.
+Do đó, nó trở thành một cách triển khai cụ thể của quy trình kiểm soát chất lượng trong các nhóm.
+CI cho phép các nhóm phần mềm biến mỗi lần commit mã nguồn thành một thất bại rõ ràng hoặc một bản phát hành khả thi.
+
+## Thuật ngữ liên quan
+
+* [Phân phối liên tục](/continuous-delivery/)
+* [Triển khai liên tục](/continuous-deployment/)
diff --git a/content/vi/distributed-apps.md b/content/vi/distributed-apps.md
new file mode 100644
index 0000000000..4dcba592a6
--- /dev/null
+++ b/content/vi/distributed-apps.md
@@ -0,0 +1,16 @@
+---
+title: Ứng dụng phân tán
+status: Completed
+category: concept
+tags: ["architecture", "", ""]
+---
+
+Một distributed application (ứng dụng phân tán) là ứng dụng mà chức năng được chia nhỏ thành nhiều thành phần độc lập. Các ứng dụng phân tán thường được cấu thành từ các [microservice](/microservices-architecture/), mỗi microservice đảm nhận một chức năng riêng biệt trong tổng thể ứng dụng. Trong môi trường cloud native, các thành phần này thường chạy dưới dạng [container](/container/) trên một [cluster](/cluster/).
+
+## Vấn đề nó giải quyết
+
+Một ứng dụng chạy trên một máy đơn lẻ sẽ trở thành single point of failure — nếu máy đó gặp sự cố, toàn bộ ứng dụng sẽ không thể truy cập được. Distributed application thường được so sánh với [monolithic application](/monolithic-apps/) (ứng dụng nguyên khối). Một ứng dụng monolithic thường khó mở rộng hơn vì các thành phần bên trong không thể mở rộng một cách độc lập. Ngoài ra, khi ứng dụng phát triển lớn dần, việc phát triển cũng trở nên chậm hơn do nhiều lập trình viên phải cùng làm việc trên một shared codebase (mã nguồn dùng chung) mà không nhất thiết phải có các rằng buộc được định nghĩa rõ ràng 
+
+## Lợi ích mang lại
+
+Khi tách một ứng dụng thành nhiều thành phần khác nhau và chạy chúng ở nhiều nơi, hệ thống tổng thể có thể chịu được nhiều lỗi hơn. Cách tiếp cận này cũng cho phép ứng dụng tận dụng các khả năng scaling mà một phiên bản đơn lẻ không có, đặc biệt là khả năng [horizontal scaling](/horizontal-scaling/) (mở rộng theo chiều ngang). Tuy nhiên, điều này cũng đi kèm với cái giá phải trả: độ phức tạp và gánh nặng vận hành tăng lên — thay vì chỉ chạy một ứng dụng duy nhất, bạn giờ phải quản lý nhiều thành phần ứng dụng riêng biệt. 
diff --git a/content/vi/immutable-infrastructure.md b/content/vi/immutable-infrastructure.md
new file mode 100644
index 0000000000..f174bc6fba
--- /dev/null
+++ b/content/vi/immutable-infrastructure.md
@@ -0,0 +1,10 @@
+---
+title: Hạ tầng bất biến (Immutable Infrastructure)
+status: Completed
+category: property
+tags: ["infrastructure", "property", ""]
+---
+
+Hạ tầng bất biến (Immutable Infrastructure) đề cập đến hạ tầng máy tính (như [máy ảo](/virtual-machine/), [containers](/container/), thiết bị mạng) không thể thay đổi sau khi đã được triển khai. Điều này có thể đạt được thông qua thực thi một quy trình tự động ghi đè các thay đổi không được phép hoặc thông qua một hệ thống không cho phép thay đổi ngay từ đầu. Containers là một ví dụ điển hình của Immutable Infrastructure vì mọi thay đổi bền vững lên container chỉ có thể thực hiện bằng cách tạo một phiên bản mới của container hoặc khởi tạo lại container hiện tại từ image của nó.
+
+Bằng cách ngăn chặn hoặc phát hiện các thay đổi trái phép, Immutable Infrastructure giúp việc nhận diện và giảm thiểu rủi ro bảo mật trở nên dễ dàng hơn. Việc vận hành hệ thống này cũng trở nên đơn giản hơn vì quản trị viên có thể đưa ra các giả định về hệ thống, bởi họ biết rằng không ai thực hiện thay đổi hoặc mắc lỗi mà quên thông báo. Immutable Infrastructure thường đi đôi với [infrastructure as code](/infrastructure-as-code/), nơi toàn bộ tự động hoá cần thiết để tạo ra hạ tầng đều được lưu trữ trong version control (ví dụ: Git). Sự kết hợp giữa tính bất biến và version control này đảm bảo rằng luôn có một audit log bền vững cho mọi thay đổi được phép trên hệ thống.
diff --git a/content/vi/infrastructure-as-a-service.md b/content/vi/infrastructure-as-a-service.md
new file mode 100644
index 0000000000..6addfbdeb5
--- /dev/null
+++ b/content/vi/infrastructure-as-a-service.md
@@ -0,0 +1,18 @@
+---
+title: Dịch vụ cơ sở hạ tầng (IaaS)
+status: Completed
+category: Technology
+tags: ["infrastructure", "", ""]
+---
+
+Dịch vụ cơ sở hạ tầng (Infrastructure as a Service), hay IaaS, là một mô hình dịch vụ [điện toán đám mây](/cloud-computing/) cung cấp các tài nguyên tính toán, lưu trữ và mạng (có thể là [vật lý](/bare-metal-machine/) hoặc [ảo hóa](/virtualization/)) theo nhu cầu và thanh toán theo mức sử dụng thực tế. Các nhà cung cấp điện toán đám mây sở hữu và vận hành phần cứng, phần mềm, cung cấp cho khách hàng dưới dạng đám mây công khai (public), riêng tư (private) hoặc linh hoạt (hybrid).
+
+## Vấn đề mà nó giải quyết
+
+Trong các hệ thống on-premise truyền thống, tổ chức thường gặp khó khăn trong việc sử dụng hiệu quả tài nguyên tính toán. Các trung tâm dữ liệu phải được xây dựng để đáp ứng nhu cầu tiềm năng cực đại , dù chỉ sử dụng 1% thời gian. Khi nhu cầu thấp, tài nguyên bị bỏ phí. Nếu khối lượng công việc tăng đột biến vượt dự đoán, sẽ thiếu tài nguyên để xử lý. Việc này dẫn đến chi phí tăng cao và sử dụng tài nguyên không hiệu quả do thiếu sự linh hoạt khi mở rộng.
+
+## Lợi ích mang lại
+
+Với IaaS, tổ chức không cần mua sắm và duy trì máy chủ hay không gian trung tâm dữ liệu cho ứng dụng. Hạ tầng theo nhu cầu cho phép thuê tài nguyên khi cần thiết, trì hoãn các khoản đầu tư lớn ban đầu (CAPEX), đồng thời mang lại sự linh hoạt để mở rộng hoặc thu hẹp quy mô.
+
+IaaS giúp giảm chi phí khởi đầu khi thử nghiệm hoặc phát triển ứng dụng mới, đồng thời cung cấp khả năng triển khai hạ tầng nhanh chóng. Điện toán đám mây là lựa chọn lý tưởng cho môi trường phát triển hoặc kiểm thử, giúp lập trình viên dễ dàng thử nghiệm và đổi mới.
diff --git a/content/vi/infrastructure-as-code.md b/content/vi/infrastructure-as-code.md
new file mode 100644
index 0000000000..2c8a4c2f42
--- /dev/null
+++ b/content/vi/infrastructure-as-code.md
@@ -0,0 +1,24 @@
+---
+title: Cở sở hạ tầng bằng Code (Infrastructure as Code) (IaC)
+status: Completed
+category: concept
+tags: ["infrastructure", "methodology", ""]
+---
+
+Infrastructure as code(IaC) các quản lý lưu trữ định nghĩa hạ tầng dưới dạng một hoặc nhiều file.
+Điều này thay thế mô hình truyền thống, nơi infrastructure as a service được cấp phát thủ công,
+thường thông qua các shell script hoặc công cụ cấu hình khác.
+
+## Vấn đề mà nó giải quyết
+
+Việc xây dựng ứng dụng theo hướng cloud native đòi hỏi hạ tầng phải có khả năng có thể loại bỏ (disposable) và reproducible (có thể tái tạo).
+Hạ tầng cũng cần để [mở rộng](/scalability/) theo nhu cầu một cách tự động và lặp lại, thậm chí không cần sự can thiệp của con người.
+Việc cấp phát thủ công không đáp ứng được yêu cầu về tốc độ phản hồi và nhu cầu mở rộng của [cloud native applications](/cloud-native-apps/).
+Các thay đổi hạ tầng thủ công không thể tái tạo, nhanh chóng gặp giới hạn về quy mô và dễ gây ra lỗi cấu hình.
+
+## Lợi ích mang lại
+
+Bằng cách biểu diễn các tài nguyên trung tâm dữ liệu như server, load balancer, subnet dưới dạng code,
+đội ngũ hạ tầng có thể có một nguồn cấu hình duy nhất (single source of truth) cho toàn bộ hệ thống,
+và có thể quản lý trung tâm dữ liệu trong quy trình [CI](/continuous-integration/)/[CD](/continuous-delivery/),
+áp dụng kiểm soát phiên bản và chiến lược triển khai tự động.
diff --git a/content/vi/loosely-coupled-architecture.md b/content/vi/loosely-coupled-architecture.md
new file mode 100644
index 0000000000..3e9d9dcee3
--- /dev/null
+++ b/content/vi/loosely-coupled-architecture.md
@@ -0,0 +1,19 @@
+---
+title: Kiến Trúc Liên Kết Lỏng Lẻo
+status: Completed
+category: Property
+tags: ["fundamental", "architecture", "property"]
+---
+
+Kiến trúc liên kết lỏng lẻo là một phong cách kiến trúc
+trong đó các thành phần riêng lẻ của một ứng dụng được xây dựng độc lập với nhau
+(đối lập với mô hình [kiến trúc liên kết chặt chẽ](/tightly-coupled-architecture/)).
+Mỗi thành phần, đôi khi được gọi là [microservice](/microservices-architecture/), được xây dựng để thực hiện một chức năng cụ thể
+theo cách có thể được sử dụng bởi bất kỳ số lượng dịch vụ khác nào.
+Mẫu thiết kế này thường chậm hơn để triển khai so với kiến trúc liên kết chặt chẽ
+nhưng mang lại nhiều lợi ích, đặc biệt khi ứng dụng mở rộng quy mô.
+
+Các ứng dụng liên kết lỏng lẻo cho phép các nhóm phát triển tính năng, triển khai và mở rộng một cách độc lập,
+điều này giúp các tổ chức có thể lặp lại nhanh chóng trên từng thành phần riêng lẻ.
+Việc phát triển ứng dụng trở nên nhanh hơn và các nhóm có thể được cấu trúc dựa trên năng lực của họ,
+tập trung vào ứng dụng cụ thể của mình.
diff --git a/content/vi/platform-as-a-service.md b/content/vi/platform-as-a-service.md
new file mode 100644
index 0000000000..5df8929b7e
--- /dev/null
+++ b/content/vi/platform-as-a-service.md
@@ -0,0 +1,23 @@
+---
+title: Platform as a Service (PaaS)
+status: Deprecated
+category: Technology
+draft: true
+tags: ["fundamental", "platform", ""]
+---
+
+Platform as a Service, hay PaaS, là một nền tảng bên ngoài dành cho các đội phát triển ứng dụng để triển khai và chạy ứng dụng của họ.
+Heroku, Cloud Foundry, App Engine là những ví dụ về các dịch vụ PaaS.
+
+## Vấn đề nó giải quyết
+
+Để tận dụng các mô hình cloud native như [kiến trúc microservices](/microservices-architecture/) hoặc [ứng dụng phân tán](/distributed-apps/),
+các đội vận hành và nhà phát triển cần có khả năng giảm bớt đáng kể công việc vận hành và bảo trì.
+Những công việc này bao gồm các nhiệm vụ như cung cấp cơ sở hạ tầng,
+quản lý [khám phá dịch vụ](/service-discovery/) (việc các dịch vụ tự động tìm và kết nối với nhau) và cân bằng tải, cũng như [mở rộng quy mô](/scalability/) ứng dụng.
+
+## Lợi ích mang lại
+
+Một dịch vụ PaaS cung cấp các công cụ cơ sở hạ tầng cho các nhà phát triển ứng dụng một cách hoàn toàn tự động.
+Nó cho phép họ hiểu và lo lắng ít hơn về bản thân cơ sở hạ tầng và dành nhiều thời gian và công sức hơn để viết mã ứng dụng.
+Nó cũng cung cấp nền tảng khả năng theo dõi và [giám sát](/observability/) để giúp các đội ứng dụng đảm bảo rằng ứng dụng của họ hoạt động tốt.
diff --git a/content/vi/policy-as-code.md b/content/vi/policy-as-code.md
new file mode 100644
index 0000000000..b50e950ea0
--- /dev/null
+++ b/content/vi/policy-as-code.md
@@ -0,0 +1,24 @@
+---
+title: Policy as Code (PaC)
+status: Completed
+category: Concept
+tags: ["methodology", "", ""]
+---
+
+Policy as Code là cách lưu trữ và áp dụng các quy định kỹ thuật của hệ thống bằng mã hoặc file cấu hình mà máy tính có thể đọc và xử lý tự động.
+Phương pháp này thay thế mô hình truyền thống, nơi các chính sách được ghi lại dưới dạng con người có thể đọc được trong các tài liệu riêng biệt.
+
+## Vấn đề nó giải quyết
+
+Việc xây dựng ứng dụng và cơ sở hạ tầng thường bị ràng buộc bởi nhiều chính sách mà một tổ chức đặt ra, 
+ví dụ như các chính sách bảo mật cấm lưu trữ thông tin bí mật trong mã nguồn, chạy container với quyền superuser, 
+hoặc lưu trữ dữ liệu bên ngoài một khu vực địa lý cụ thể.
+Việc kiểm tra thủ công các ứng dụng và cơ sở hạ tầng so với các chính sách đã được ghi lại rất tốn công sức và dễ xảy ra lỗi đối với các nhà phát triển và người đánh giá. 
+Các quy trình thủ công không thể đáp ứng các yêu cầu về khả năng phản hồi và quy mô của các ứng dụng cloud native.
+
+## Lợi ích mang lại
+
+Mô tả các chính sách thông qua code cho phép lặp lại và giảm lỗi (không giống như khi thực hiện thủ công). 
+Một lợi ích khác của Policy as Code là mã có thể được quản lý bởi hệ thống kiểm soát phiên bản như Git.
+Git tạo ra lịch sử nhật ký thay đổi, điều này đặc biệt hữu ích khi có điều gì đó không hoạt động như mong đợi.
+Nó cho phép người dùng xác định ai đã thực hiện thay đổi và quay trở lại phiên bản trước đó.
diff --git a/content/vi/stateful-apps.md b/content/vi/stateful-apps.md
new file mode 100644
index 0000000000..63616259b0
--- /dev/null
+++ b/content/vi/stateful-apps.md
@@ -0,0 +1,16 @@
+---
+title: Ứng dụng có trạng thái (Stateful Apps)
+status: Completed
+category: Property
+tags: ["fundamental", "application", "property"]
+---
+
+Khi chúng ta nói về ứng dụng có trạng thái (stateful) (và [không có trạng thái](/stateless-apps/)),
+trạng thái (state) ở đây đề cập đến bất kỳ dữ liệu nào mà ứng dụng cần lưu trữ để hoạt động đúng như đã được thiết kế.
+Ví dụ, bất kỳ cửa hàng trực tuyến nào ghi nhớ giỏ hàng của bạn đều là một ứng dụng có trạng thái.
+
+Ngày nay, hầu hết các ứng dụng chúng ta sử dụng đều có ít nhất một phần stateful. Tuy nhiên, trong môi trường cloud native,
+các ứng dụng có trạng thái là một thách thức. Điều này là do [ứng dụng cloud native](/cloud-native-apps/) rất linh hoạt.
+Chúng có thể được mở rộng lên hoặc thu nhỏ lại, khởi động lại, và di chuyển xung quanh nhưng vẫn cần có khả năng truy cập vào trạng thái của chúng.
+
+Do đó, các ứng dụng có trạng thái cần một loại lưu trữ nào đó có thể truy cập từ bất kỳ đâu, như cơ sở dữ liệu.
diff --git a/content/vi/stateless-apps.md b/content/vi/stateless-apps.md
new file mode 100644
index 0000000000..314858910f
--- /dev/null
+++ b/content/vi/stateless-apps.md
@@ -0,0 +1,14 @@
+---
+title: Ứng dụng không có trạng thái (Stateless Apps)
+status: Completed
+category: Property
+tags: ["fundamental", "application", "property"]
+---
+
+Ứng dụng không có trạng thái xử lý mỗi yêu cầu một cách độc lập mà không ghi nhớ bất kỳ tương tác trước đó hoặc dữ liệu người dùng nào.
+Dữ liệu từ các tương tác trước đây được gọi là trạng thái (state), và vì dữ liệu này không được lưu trữ ở bất kỳ đâu, nên các ứng dụng này được gọi là không có trạng thái (state*less*).
+Đây là một ví dụ:
+Khi bạn sử dụng công cụ tìm kiếm, và quá trình tìm kiếm đó bị gián đoạn (ví dụ: cửa sổ bị đóng), các kết quả tìm kiếm đó sẽ bị mất.
+Bạn sẽ cần phải bắt đầu lại từ đầu.
+
+Mặt khác, các ứng dụng xử lý yêu cầu trong khi xem xét các tương tác trước đó được gọi là [ứng dụng có trạng thái](/stateful-apps/).
diff --git a/content/vi/zero-trust-architecture.md b/content/vi/zero-trust-architecture.md
new file mode 100644
index 0000000000..0f5745042a
--- /dev/null
+++ b/content/vi/zero-trust-architecture.md
@@ -0,0 +1,34 @@
+---
+title: Kiến trúc Zero Trust
+status: Completed
+category: Concept
+tags: ["security", "", ""]
+---
+
+Kiến trúc Zero Trust tuân theo một phương pháp tiếp cận trong thiết kế và triển khai các hệ thống IT
+mà trong đó sự tin tưởng bị loại bỏ hoàn toàn.
+Nguyên tắc cốt lõi là "không bao giờ tin tưởng, luôn xác minh", các thiết bị hoặc hệ thống,
+trong khi giao tiếp với các thành phần khác của hệ thống, luôn phải tự xác minh mình trước khi làm điều đó.
+Trong nhiều mạng ngày nay, trong mạng nội bộ của doanh nghiệp, các hệ thống và thiết bị bên trong có thể tự do giao tiếp với nhau
+vì chúng nằm trong ranh giới tin cậy của phạm vi mạng doanh nghiệp.
+Kiến trúc Zero Trust áp dụng phương pháp ngược lại, dù đang ở trong phạm vi mạng,
+các thành phần trong hệ thống trước tiên phải vượt qua xác minh trước khi bất kỳ giao tiếp nào được thực hiện.
+
+## Vấn đề nó giải quyết
+
+Với phương pháp tiếp cận dựa trên sự tin tưởng truyền thống, nơi các hệ thống và thiết bị tồn tại trong phạm vi mạng doanh nghiệp,
+giả định rằng vì có sự tin tưởng, nên không có vấn đề gì.
+Tuy nhiên, Kiến trúc Zero Trust nhận ra rằng sự tin tưởng là một lỗ hổng.
+Trong trường hợp kẻ tấn công đã có quyền truy cập vào thiết bị đáng tin cậy,
+tùy thuộc vào mức độ tin tưởng và quyền truy cập đã được cấp cho thiết bị đó,
+hệ thống hiện đang dễ bị tấn công
+vì kẻ tấn công đã ở trong phạm vi mạng "đáng tin cậy" và có thể di chuyển theo chiều ngang trong toàn bộ hệ thống.
+Trong Kiến trúc Zero Trust, sự tin tưởng bị loại bỏ, do đó giảm bề mặt tấn công
+khi kẻ tấn công giờ đây buộc phải xác minh trước khi đi sâu hơn vào hệ thống.
+
+## Lợi ích mang lại
+
+Áp dụng Kiến trúc Zero Trust mang lại lợi ích chính là tăng cường bảo mật
+với việc giảm bề mặt tấn công.
+Loại bỏ sự tin tưởng khỏi hệ thống doanh nghiệp của bạn giờ đây làm tăng số lượng và sức mạnh của các hàng rào bảo mật
+mà kẻ tấn công phải vượt qua để có thể truy cập vào các khu vực khác của hệ thống.
diff --git a/wordlist.txt b/wordlist.txt
index df6cc8f8b1..e2f835d5c1 100644
--- a/wordlist.txt
+++ b/wordlist.txt
@@ -248,3 +248,4 @@ CLI
 CLIs
 SDK
 SDKs
+CRDs
\ No newline at end of file