diff --git a/pages/03-Cloud-Native/008-Best-Practice-for-App-Deployments.md b/pages/03-Cloud-Native/008-Best-Practice-for-App-Deployments.md
index f7d5d5d..fa42a06 100755
--- a/pages/03-Cloud-Native/008-Best-Practice-for-App-Deployments.md
+++ b/pages/03-Cloud-Native/008-Best-Practice-for-App-Deployments.md
@@ -19,7 +19,7 @@ Refers to the status of the application and ensuring the expected behavior to ta
 
 Measures the performance of an application.
 - include statistics collected on the services 
-- number of logins, number of active users, number of reqeusts handled, CPU utilization, memory, etc.
+- number of logins, number of active users, number of requests handled, CPU utilization, memory, etc.
 - usually  returned via an HTTP endpoint such as <code>/metrics</code>.
 
 ## Logs
diff --git a/pages/04-Kubernetes/028-Kubernetes-Security-authorization-mechanisms.md b/pages/04-Kubernetes/028-Kubernetes-Security-authorization-mechanisms.md
index bb00663..442834a 100755
--- a/pages/04-Kubernetes/028-Kubernetes-Security-authorization-mechanisms.md
+++ b/pages/04-Kubernetes/028-Kubernetes-Security-authorization-mechanisms.md
@@ -179,7 +179,7 @@ As an example, if the modes are specified in this order:
 Then any API requests will go through Node authorizer first, then RBAC, then Webhook. 
 
 - If the first one denies, it forwards the request to the second mode. 
-- As soon as one mode approves, no additional checks are done and reqeust is granted.
+- As soon as one mode approves, no additional checks are done and request is granted.
 - If none of the mode approves, then the request is denied
 
 
diff --git a/pages/04-Kubernetes/028-Use-audit-logs-to-monitor-access.md b/pages/04-Kubernetes/028-Use-audit-logs-to-monitor-access.md
index cafa063..19d59e4 100755
--- a/pages/04-Kubernetes/028-Use-audit-logs-to-monitor-access.md
+++ b/pages/04-Kubernetes/028-Use-audit-logs-to-monitor-access.md
@@ -15,7 +15,7 @@ Kubernetes provides auditing and it is handled by the kube-apiserver. However, w
 1. Request is sent to kube-apiserver.
 2. It goes through **RequestReceived** stage. In this stage, events are generated regardless if requests are approved or not.
 3. For requests that take some time to complete, they go through **RequestStarted.**
-4. Once reqeust is completed, it goes through **RequestComplete.** In this stage, a response body is returned.
+4. Once request is completed, it goes through **RequestComplete.** In this stage, a response body is returned.
 5. For invalid requests or errors, the request goes through **Panic** stage.
 
 If we record all events generated for every stage, we would end up with thousands of logs within no time. TO record specific events, we can create a **Policy** object.