What is the difference between `kubectl cordon`, `kubectl drain`, and `kubectl uncordon`?

`kubectl cordon `: Marks the node as `SchedulingDisabled` (`spec.unschedulable: true`) so no new Pods will be scheduled onto it, while leaving existing Pods running untouched. `kubectl drain --ignore-daemonsets --delete-emptydir-data`: Cordons the node AND gracefully evicts all running Pods (respecting `PodDisruptionBudgets`) so they reschedule onto other healthy nodes. `kubectl uncordon `: Marks the node schedulable again after maintenance.

Compare `Role` vs. `ClusterRole` and `RoleBinding` vs. `ClusterRoleBinding` in Kubernetes RBAC.

`Role`: Namespaced object defining permissions (`verbs` on `resources`/`apiGroups`) within a single namespace. `ClusterRole`: Cluster-scoped object defining permissions on cluster-wide resources (like `nodes`, `persistentvolumes`, `namespaces`), non-resource URLs (`/healthz`), OR namespaced resources across all namespaces. `RoleBinding`: Grants a `Role` OR a `ClusterRole` to subjects (`User`, `Group`, `ServiceAccount`), scoped strictly to the RoleBinding's single namespace. `ClusterRoleBinding`: Grants a `ClusterRole` across the entire cluster.

Why might a Kubernetes Service fail to route traffic to running Pods even when both the Service and Pods exist without errors?

1. Selector mismatch: Compare `kubectl get svc -o yaml` (`spec.selector`) against `kubectl get pods --show-labels`; verify with `kubectl get endpointslices -l kubernetes.io/service-name= ` (or `kubectl get ep `)—if `ENDPOINTS` is ` `, the selector labels don't match or the Pods are failing their `readinessProbe`! 2. Port mismatch: `Service.spec.ports[].targetPort` does not match the actual port the application process listens on inside the container (`ss -tulpn`). 3. A `NetworkPolicy` is blocking Ingress/Egress.

What is Helm in Kubernetes, and what is the structure of a Helm Chart (`Chart.yaml`, `values.yaml`, `templates/`)?

Helm is the package manager and templating engine for Kubernetes. A Helm Chart contains: `Chart.yaml` (chart metadata, version, `appVersion`, and subchart `dependencies`), `values.yaml` (default configuration variables), `templates/` (Go-templated Kubernetes YAML manifests using `{{ .Values.foo }}` and `_helpers.tpl` named templates), and `charts/` (vendored subcharts).

What does setting `immutable: true` on a Kubernetes `ConfigMap` or `Secret` accomplish?

Marking a `ConfigMap` or `Secret` as `immutable: true` prevents any future modifications to its `data` (to change values, you must create a new uniquely named `ConfigMap`/`Secret` v2 and update the Deployment). This protects against accidental bad config rollouts AND dramatically improves cluster scalability because `kubelet` stops polling/watching the `kube-apiserver` for changes to that resource across thousands of nodes.

What happens when a `PersistentVolume` with `persistentVolumeReclaimPolicy: Retain` has its `PersistentVolumeClaim` deleted, and how do you reuse that PV?

When the PVC is deleted, the PV transitions from `Bound` to `Released` (NOT `Available`!). A `Released` PV cannot be bound by any new PVC because it still holds the previous claimant's `spec.claimRef` pointer and old data. To make the existing PV `Available` again for a new PVC without deleting the PV, edit the PV (`kubectl edit pv `) and delete the `spec.claimRef` block.

Compare the four PersistentVolume Access Modes (`RWO`, `ROX`, `RWX`, `RWOP`) and three Reclaim Policies (`Retain`, `Delete`, `Recycle`).

Access Modes: `ReadWriteOnce` (`RWO`: mounted read-write by a single Node—multiple Pods on that same node can share it); `ReadOnlyMany` (`ROX`: mounted read-only by many Nodes); `ReadWriteMany` (`RWX`: mounted read-write by many Nodes simultaneously, e.g., NFS, CephFS, Azure Files, EFS); `ReadWriteOncePod` (`RWOP`: mounted read-write by only a single Pod in the whole cluster). Reclaim Policies (when PVC is deleted): `Retain` (keeps PV and data for manual recovery; default for manual PVs), `Delete` (deletes PV and cloud disk; default for dynamic StorageClasses).

How do Node `Taints` and Pod `Tolerations` work together, and what are the three Taint effects (`NoSchedule`, `PreferNoSchedule`, `NoExecute`)?

Taints are applied to Nodes (`kubectl taint nodes node1 key=value:Effect`) to repel Pods, while Tolerations are applied in `PodSpec` to allow (but NOT force!) a Pod to schedule onto a tainted node. Effects: 1. `NoSchedule`: New Pods without a matching toleration will not be scheduled onto the node (existing running Pods stay). 2. `PreferNoSchedule`: Soft version of `NoSchedule`. 3. `NoExecute`: New untolerated Pods are not scheduled AND any currently running Pods on the node without a matching toleration are immediately EVICTED (or evicted after `tolerationSeconds`).

What is a `PodDisruptionBudget` (PDB) and how does it protect high availability during `kubectl drain` or cluster upgrades?

A `PodDisruptionBudget` limits the number of Pods of a replicated application that can be down simultaneously due to VOLUNTARY disruptions (such as `kubectl drain`, node upgrades, or cluster autoscaler scale-down; does not affect involuntary hardware crashes). You configure either `minAvailable` (e.g., `2` or `80%`) or `maxUnavailable` (e.g., `1`) alongside a `selector`. During `kubectl drain`, the Eviction API blocks draining a node if evicting its Pod would violate the PDB.

What are the core `helm` CLI commands for installing, upgrading, rendering templates locally, and rolling back a release?

`helm repo add && helm repo update` manages chart repos; `helm install -n --create-namespace -f custom-values.yaml --set replicaCount=3` installs a release; `helm upgrade --install --atomic` upgrades (or installs if missing) and automatically rolls back if deployment fails; `helm template ` renders YAML manifests locally to stdout without touching a cluster; `helm list -A` lists releases; `helm rollback ` rolls back to a previous revision.

Why do you need BOTH Taints/Tolerations AND Node Affinity to dedicate a group of GPU nodes exclusively to GPU Pods?

A Taint (`gpu=true:NoSchedule`) on the GPU nodes + a Toleration on the GPU Pods prevents non-GPU Pods from landing on the GPU nodes, BUT a Toleration alone does NOT stop the GPU Pods from being scheduled onto regular non-GPU CPU nodes! Conversely, Node Affinity alone pulls GPU Pods to GPU nodes, but doesn't stop regular non-GPU Pods from filling up the GPU nodes. Combining Taint+Toleration WITH Node Affinity guarantees strict 1-to-1 dedicated node isolation.

Explain the lifecycle and binding relationship between `PersistentVolume` (PV), `PersistentVolumeClaim` (PVC), and `StorageClass` (SC).

A `PersistentVolume` (PV) is a cluster-scoped piece of storage provisioned either statically by an admin or dynamically by a `StorageClass` CSI provisioner. A `PersistentVolumeClaim` (PVC) is a namespaced request by a user for storage (`accessModes`, `resources.requests.storage`, `storageClassName`). When a PVC is created with a `StorageClass`, the CSI driver dynamically creates the underlying cloud disk and binds the PV 1-to-1 (`Bound`) to the PVC. Setting `volumeBindingMode: WaitForFirstConsumer` delays disk creation until the Pod is scheduled to a specific Availability Zone!

What security settings can be configured in a Pod or Container `securityContext`, and what are Pod Security Standards (PSS)?

`securityContext` settings include: `runAsNonRoot: true`, `runAsUser: 10001`, `runAsGroup: 10001`, `fsGroup: 2000` (Pod-level: sets group ownership on mounted volumes), `readOnlyRootFilesystem: true`, `allowPrivilegeEscalation: false`, `capabilities: { drop: ["ALL"] }`, and `seccompProfile: { type: RuntimeDefault }`. Pod Security Admission enforces three built-in Pod Security Standards via namespace labels (`pod-security.kubernetes.io/enforce`): `privileged`, `baseline`, and `restricted`.

What are CustomResourceDefinitions (CRDs) and the Kubernetes Operator Pattern?

A `CustomResourceDefinition` (CRD) extends the Kubernetes API server by registering a new custom resource schema (e.g., `kind: PostgresCluster`, `kind: Certificate`, `kind: Application`) stored in `etcd`. An Operator pairs a CRD with a custom Controller (running as a Pod watching the API server) that embeds domain-specific operational knowledge in a reconciliation loop (comparing `spec` desired state vs `status` actual state) to automate complex stateful tasks like database backups, leader failover, and TLS renewal.

What are the ways to inject a `ConfigMap` or `Secret` into a Pod, and which methods automatically update when the `ConfigMap`/`Secret` is modified?

1. Environment Variables (`env.valueFrom.configMapKeyRef`/`secretKeyRef` or `envFrom`): Injected only at container startup; does NOT update dynamically if the ConfigMap/Secret changes (requires Pod restart). 2. Volume Mount (`volumes[].configMap`/`secret`): `kubelet` periodically syncs changes and atomically swaps symlinked files inside the running container! EXCEPTION: If the `volumeMount` uses `subPath` (to mount a single file without hiding the target directory), it does NOT receive automatic updates!

Compare Resource `requests` and `limits` for CPU and Memory in a Kubernetes Pod.

`requests`: The minimum guaranteed amount of CPU (`millicores`, e.g., `500m` = 0.5 vCPU) and Memory (`Mi`/`Gi`) reserved for the container; `kube-scheduler` uses ONLY `requests` to decide which node has enough allocatable capacity to place the Pod. `limits`: The maximum ceiling a container is allowed to consume on the node. If a container exceeds its CPU `limit`, the kernel CFS scheduler THROTTLES its CPU cycles; if a container exceeds its Memory `limit`, the kernel OOM Killer terminates it (`OOMKilled`, exit code `137`).

How have Kubernetes `ServiceAccount` tokens changed since Kubernetes v1.22 / v1.24 (TokenRequest API)?

Prior to v1.24, creating a `ServiceAccount` automatically generated a non-expiring Secret containing a static JWT token. In modern Kubernetes (v1.24+), no long-lived Secret token is auto-created; instead, `kubelet` uses the `TokenRequest` API and projected volumes to mount a time-bound (e.g., 1-hour auto-rotating), audience-bound JWT token into the Pod at `/var/run/secrets/kubernetes.io/serviceaccount/token` (can be disabled via `automountServiceAccountToken: false`).

What are the three Pod Quality of Service (QoS) classes in Kubernetes, how are they assigned, and in what order are Pods evicted under Node Memory Pressure?

1. `Guaranteed`: Every container in the Pod has BOTH `requests` and `limits` set for CPU and Memory, and `requests == limits` for each. 2. `Burstable`: At least one container has a CPU or Memory `request` or `limit` set, but doesn't meet `Guaranteed` criteria. 3. `BestEffort`: NO container in the Pod has any CPU or Memory `requests` or `limits` set at all. Under Node Memory Pressure, `kubelet` evicts Pods in order: `BestEffort` first -> `Burstable` exceeding requests -> `Guaranteed` last.

Where does Helm v3 store release state inside a Kubernetes cluster, and how does it differ from Kustomize (`kubectl apply -k`)?

Helm v3 is client-only (removed the legacy Helm v2 `Tiller` server pod) and stores release history and state as compressed, base64-encoded Kubernetes `Secret` objects (`type: helm.sh/release.v1`) directly inside the release's target namespace! Whereas Helm uses Go templating (`{{ ... }}`) and manages release lifecycles/hooks, Kustomize (built natively into `kubectl apply -k`) uses template-free declarative YAML overlays (`kustomization.yaml`, `base/` + `overlays/prod/` with Strategic Merge Patches and JSON 6902 patches).

Compare `podAffinity` and `podAntiAffinity`, and explain how `topologyKey` works.

`podAffinity` co-locates a Pod in the same topology domain as other Pods matching a label selector (e.g., placing a web Pod on the same node/zone as its Redis cache Pod). `podAntiAffinity` spreads Pods apart so they do NOT land in the same topology domain (e.g., preventing two replicas of the same database or web deployment from landing on the same physical host: `topologyKey: kubernetes.io/hostname`, or same Availability Zone: `topologyKey: topology.kubernetes.io/zone`).

What is the difference between a `ResourceQuota` and a `LimitRange` in a Kubernetes Namespace?

`ResourceQuota`: Enforces an aggregate ceiling across the ENTIRE Namespace (e.g., total sum of all Pods in `dev` cannot exceed `20` vCPUs, `64Gi` RAM, or `10` PVCs). Note: When a CPU/Memory `ResourceQuota` is active in a namespace, every Pod created in that namespace MUST specify CPU/Memory requests/limits or the API server rejects it! `LimitRange`: Solves this by automatically injecting default `requests`/`limits` (`default`, `defaultRequest`) and enforcing min/max bounds per individual Pod/Container.

Compare `nodeName`, `nodeSelector`, and `nodeAffinity` for scheduling Pods onto specific Kubernetes nodes.

`nodeName`: Bypasses `kube-scheduler` completely and forces `kubelet` on that exact node to run the Pod. `nodeSelector`: Simplest scheduler filter requiring exact equality on node labels (e.g., `disktype: ssd`). `nodeAffinity`: Expressive scheduling rules supporting `In`, `NotIn`, `Exists`, `DoesNotExist`, `Gt`, `Lt` operators and two modes: `requiredDuringSchedulingIgnoredDuringExecution` (hard requirement: Pod stays `Pending` if unmatched) vs `preferredDuringSchedulingIgnoredDuringExecution` (soft weighted preference).

What is the exact procedure to safely upgrade a `kubeadm` Kubernetes cluster from `v1.30.x` to `v1.31.x` (CKA Exam core task)?

Always upgrade ONE minor version at a time! On Control Plane node: 1. Upgrade `kubeadm` package (`apt-mark unhold kubeadm && apt-get update && apt-get install -y kubeadm=1.31.x-* && apt-mark hold kubeadm`); 2. Run `kubeadm upgrade plan` then `sudo kubeadm upgrade apply v1.31.x`; 3. Drain control plane: `kubectl drain controlplane --ignore-daemonsets`; 4. Upgrade `kubelet` and `kubectl` packages, then `systemctl daemon-reload && systemctl restart kubelet`; 5. `kubectl uncordon controlplane`. On each Worker Node: Upgrade `kubeadm` -> `kubectl drain --ignore-daemonsets` -> `sudo kubeadm upgrade node` -> upgrade `kubelet`/`kubectl` & restart `kubelet` -> `kubectl uncordon `.

How do you diagnose and fix a Pod stuck in `Pending` vs. `ImagePullBackOff` vs. `CrashLoopBackOff`?

1. `Pending` (not yet scheduled to a node): Run `kubectl describe pod ` and check `Events:` at the bottom—usually insufficient CPU/Memory on nodes, untolerated Taints, unmatched `nodeAffinity`, or an unbound `PersistentVolumeClaim`. 2. `ImagePullBackOff` / `ErrImagePull`: Typo in image name/tag, private registry missing `imagePullSecrets`, or node lacks internet/DNS to reach the registry. 3. `CrashLoopBackOff`: Container starts and exits repeatedly; run `kubectl logs --previous` (`-p`) to view the crash logs of the previous terminated instance, and check entrypoint/args, missing ConfigMap/Secret env vars, failing `livenessProbe`, or `OOMKilled` (`Exit Code 137`).

How do you troubleshoot a Worker Node that is in `NotReady` status?

1. Run `kubectl describe node ` and check the `Conditions` (`MemoryPressure`, `DiskPressure`, `PIDPressure`, `Ready`). 2. SSH to the worker node and check `kubelet` status: `systemctl status kubelet` and `journalctl -u kubelet -xe` (common causes: `kubelet` stopped/disabled, swap enabled on host `swapoff -a`, misconfigured `/var/lib/kubelet/config.yaml` or CA cert path, expired client certificate, or `containerd` runtime stopped `systemctl status containerd`). 3. Check CNI plugin pods in `kube-system` (`kubectl get pods -n kube-system`).

How do MutatingAdmissionWebhook and ValidatingAdmissionWebhook controllers work in the `kube-apiserver` request pipeline?

After Authentication and RBAC Authorization—but BEFORE an object is persisted to `etcd`—the request passes through Admission Control in two phases: 1. Mutating Admission Webhooks run first and can modify the incoming object via JSONPatch (e.g., Istio injecting an Envoy sidecar container, or `LimitRange` injecting default resource requests); 2. Object schema validation runs; 3. Validating Admission Webhooks (and CEL `ValidatingAdmissionPolicy` in K8s 1.30+) run last to accept or reject the final mutated object (e.g., OPA Gatekeeper / Kyverno blocking `:latest` image tags).

How do you check for and renew expired TLS certificates on a `kubeadm` Control Plane node?

Run `sudo kubeadm certs check-expiration` to inspect the expiration dates of all control plane PKI certificates in `/etc/kubernetes/pki/` (`apiserver`, `etcd`, `front-proxy-client`, `admin.conf`). To renew all certificates at once: run `sudo kubeadm certs renew all`, then restart the Control Plane static pods (by moving `/etc/kubernetes/manifests/*.yaml` out and back in, or restarting containers) and copy the updated `/etc/kubernetes/admin.conf` to `~/.kube/config`.

Why are Kubernetes `Secret` objects NOT secure by default, and how do you secure them in production?

By default, Kubernetes `Secrets` are merely Base64-encoded strings (`echo -n 'pass' | base64`), NOT encrypted, and are stored in plain text inside `etcd`! Anyone with RBAC `get`/`list`/`watch` on `secrets` (or access to an `etcd` snapshot) can read them. To secure Secrets: 1. Enable Encryption at Rest on `kube-apiserver` (`--encryption-provider-config` using `aescbc`, `secretbox`, or KMS provider v2); 2. Restrict RBAC `watch`/`list` on Secrets; 3. Use External Secrets Operator or CSI Secret Store Driver with Vault/Cloud KMS.

What `kubectl` JSONPath and sorting commands are essential for filtering cluster objects quickly?

Sort objects by any field: `kubectl get pods --sort-by=.status.startTime` or `kubectl get pv --sort-by=.spec.capacity.storage`. Extract fields with JSONPath: `kubectl get nodes -o jsonpath='{.items[*].status.addresses[?(@.type=="InternalIP")].address}'` prints all node internal IPs; `kubectl get secret my-secret -o jsonpath='{.data.password}' | base64 -d` decodes a secret key directly; `kubectl top pods -A --sort-by=cpu` (or `memory`) shows highest resource consumers.

How do you test RBAC permissions in Kubernetes using `kubectl auth can-i` and impersonation?

Check your own permissions: `kubectl auth can-i create deployments -n prod`. Check what a specific ServiceAccount or User can do using `--as`: `kubectl auth can-i delete pods --as=system:serviceaccount:dev:backend-sa -n dev`, or list everything a principal is allowed to do with `kubectl auth can-i --list --as=jane`.

Compare HorizontalPodAutoscaler (HPA), VerticalPodAutoscaler (VPA), and KEDA in Kubernetes.

HPA (`autoscaling/v2`): Scales the number of Pod `replicas` in a Deployment/StatefulSet based on observed CPU/Memory utilization (`metrics-server` required) or custom metrics ($DesiredReplicas = \lceil CurrentReplicas \times (CurrentMetric / DesiredMetric) \rceil$). VPA: Adjusts the CPU and Memory `requests` and `limits` of Pods vertically (often recreating Pods when resizing, though In-Place Pod Vertical Scaling is emerging). KEDA (Kubernetes Event-driven Autoscaling): Scales deployments from `0` to $N$ replicas based on external event sources like Kafka lag, SQS queue length, or Prometheus queries.

Why is binding a `ClusterRole` using a `RoleBinding` (instead of a `ClusterRoleBinding`) a powerful RBAC design pattern?

It allows cluster administrators to define standard reusable permission templates once at the cluster level (such as the built-in `admin`, `edit`, or `view` `ClusterRoles`) and then bind them via a namespaced `RoleBinding` in `namespace: team-a`. The subject receives those permissions ONLY inside `team-a`, avoiding having to duplicate identical `Role` definitions in every namespace.

Kubernetes ConfigMaps, Secrets, RBAC, PersistentVolumes, Helm & Troubleshooting

Intermediate-to-advanced Kubernetes administration and security covering ConfigMaps and Secrets, RBAC (Roles/ClusterRoles/ServiceAccounts), SecurityContexts, CSI Storage (PV/PVC/StorageClass), Advanced Scheduling (Affinity, Taints/Tolerations, QoS classes, HPA/VPA), Helm charts, and CKA cluster troubleshooting.

Level: intermediate
Languages: en → en
Cards: 32
Markdown: Kubernetes ConfigMaps, Secrets, RBAC, PersistentVolumes, Helm & Troubleshooting (.md)

Flashcards (32)

#	Front (Term / Question)	Back (Definition / Answer)
1	What is the difference between `kubectl cordon`, `kubectl drain`, and `kubectl uncordon`?	`kubectl cordon <node>`: Marks the node as `SchedulingDisabled` (`spec.unschedulable: true`) so no new Pods will be scheduled onto it, while leaving existing Pods running untouched. `kubectl drain <node> --ignore-daemonsets --delete-emptydir-data`: Cordons the node AND gracefully evicts all running Pods (respecting `PodDisruptionBudgets`) so they reschedule onto other healthy nodes. `kubectl uncordon <node>`: Marks the node schedulable again after maintenance.
2	Compare `Role` vs. `ClusterRole` and `RoleBinding` vs. `ClusterRoleBinding` in Kubernetes RBAC.	`Role`: Namespaced object defining permissions (`verbs` on `resources`/`apiGroups`) within a single namespace. `ClusterRole`: Cluster-scoped object defining permissions on cluster-wide resources (like `nodes`, `persistentvolumes`, `namespaces`), non-resource URLs (`/healthz`), OR namespaced resources across all namespaces. `RoleBinding`: Grants a `Role` OR a `ClusterRole` to subjects (`User`, `Group`, `ServiceAccount`), scoped strictly to the RoleBinding's single namespace. `ClusterRoleBinding`: Grants a `ClusterRole` across the entire cluster.
3	Why might a Kubernetes Service fail to route traffic to running Pods even when both the Service and Pods exist without errors?	1. Selector mismatch: Compare `kubectl get svc <name> -o yaml` (`spec.selector`) against `kubectl get pods --show-labels`; verify with `kubectl get endpointslices -l kubernetes.io/service-name=<name>` (or `kubectl get ep <name>`)—if `ENDPOINTS` is `<none>`, the selector labels don't match or the Pods are failing their `readinessProbe`! 2. Port mismatch: `Service.spec.ports[].targetPort` does not match the actual port the application process listens on inside the container (`ss -tulpn`). 3. A `NetworkPolicy` is blocking Ingress/Egress.
4	What is Helm in Kubernetes, and what is the structure of a Helm Chart (`Chart.yaml`, `values.yaml`, `templates/`)?	Helm is the package manager and templating engine for Kubernetes. A Helm Chart contains: `Chart.yaml` (chart metadata, version, `appVersion`, and subchart `dependencies`), `values.yaml` (default configuration variables), `templates/` (Go-templated Kubernetes YAML manifests using `{{ .Values.foo }}` and `_helpers.tpl` named templates), and `charts/` (vendored subcharts).
5	What does setting `immutable: true` on a Kubernetes `ConfigMap` or `Secret` accomplish?	Marking a `ConfigMap` or `Secret` as `immutable: true` prevents any future modifications to its `data` (to change values, you must create a new uniquely named `ConfigMap`/`Secret` v2 and update the Deployment). This protects against accidental bad config rollouts AND dramatically improves cluster scalability because `kubelet` stops polling/watching the `kube-apiserver` for changes to that resource across thousands of nodes.
6	What happens when a `PersistentVolume` with `persistentVolumeReclaimPolicy: Retain` has its `PersistentVolumeClaim` deleted, and how do you reuse that PV?	When the PVC is deleted, the PV transitions from `Bound` to `Released` (NOT `Available`!). A `Released` PV cannot be bound by any new PVC because it still holds the previous claimant's `spec.claimRef` pointer and old data. To make the existing PV `Available` again for a new PVC without deleting the PV, edit the PV (`kubectl edit pv <name>`) and delete the `spec.claimRef` block.
7	Compare the four PersistentVolume Access Modes (`RWO`, `ROX`, `RWX`, `RWOP`) and three Reclaim Policies (`Retain`, `Delete`, `Recycle`).	Access Modes: `ReadWriteOnce` (`RWO`: mounted read-write by a single Node—multiple Pods on that same node can share it); `ReadOnlyMany` (`ROX`: mounted read-only by many Nodes); `ReadWriteMany` (`RWX`: mounted read-write by many Nodes simultaneously, e.g., NFS, CephFS, Azure Files, EFS); `ReadWriteOncePod` (`RWOP`: mounted read-write by only a single Pod in the whole cluster). Reclaim Policies (when PVC is deleted): `Retain` (keeps PV and data for manual recovery; default for manual PVs), `Delete` (deletes PV and cloud disk; default for dynamic StorageClasses).
8	How do Node `Taints` and Pod `Tolerations` work together, and what are the three Taint effects (`NoSchedule`, `PreferNoSchedule`, `NoExecute`)?	Taints are applied to Nodes (`kubectl taint nodes node1 key=value:Effect`) to repel Pods, while Tolerations are applied in `PodSpec` to allow (but NOT force!) a Pod to schedule onto a tainted node. Effects: 1. `NoSchedule`: New Pods without a matching toleration will not be scheduled onto the node (existing running Pods stay). 2. `PreferNoSchedule`: Soft version of `NoSchedule`. 3. `NoExecute`: New untolerated Pods are not scheduled AND any currently running Pods on the node without a matching toleration are immediately EVICTED (or evicted after `tolerationSeconds`).
9	What is a `PodDisruptionBudget` (PDB) and how does it protect high availability during `kubectl drain` or cluster upgrades?	A `PodDisruptionBudget` limits the number of Pods of a replicated application that can be down simultaneously due to VOLUNTARY disruptions (such as `kubectl drain`, node upgrades, or cluster autoscaler scale-down; does not affect involuntary hardware crashes). You configure either `minAvailable` (e.g., `2` or `80%`) or `maxUnavailable` (e.g., `1`) alongside a `selector`. During `kubectl drain`, the Eviction API blocks draining a node if evicting its Pod would violate the PDB.
10	What are the core `helm` CLI commands for installing, upgrading, rendering templates locally, and rolling back a release?	`helm repo add <name> <url> && helm repo update` manages chart repos; `helm install <release> <chart> -n <ns> --create-namespace -f custom-values.yaml --set replicaCount=3` installs a release; `helm upgrade --install <release> <chart> --atomic` upgrades (or installs if missing) and automatically rolls back if deployment fails; `helm template <release> <chart>` renders YAML manifests locally to stdout without touching a cluster; `helm list -A` lists releases; `helm rollback <release> <revision>` rolls back to a previous revision.
11	Why do you need BOTH Taints/Tolerations AND Node Affinity to dedicate a group of GPU nodes exclusively to GPU Pods?	A Taint (`gpu=true:NoSchedule`) on the GPU nodes + a Toleration on the GPU Pods prevents non-GPU Pods from landing on the GPU nodes, BUT a Toleration alone does NOT stop the GPU Pods from being scheduled onto regular non-GPU CPU nodes! Conversely, Node Affinity alone pulls GPU Pods to GPU nodes, but doesn't stop regular non-GPU Pods from filling up the GPU nodes. Combining Taint+Toleration WITH Node Affinity guarantees strict 1-to-1 dedicated node isolation.
12	Explain the lifecycle and binding relationship between `PersistentVolume` (PV), `PersistentVolumeClaim` (PVC), and `StorageClass` (SC).	A `PersistentVolume` (PV) is a cluster-scoped piece of storage provisioned either statically by an admin or dynamically by a `StorageClass` CSI provisioner. A `PersistentVolumeClaim` (PVC) is a namespaced request by a user for storage (`accessModes`, `resources.requests.storage`, `storageClassName`). When a PVC is created with a `StorageClass`, the CSI driver dynamically creates the underlying cloud disk and binds the PV 1-to-1 (`Bound`) to the PVC. Setting `volumeBindingMode: WaitForFirstConsumer` delays disk creation until the Pod is scheduled to a specific Availability Zone!
13	What security settings can be configured in a Pod or Container `securityContext`, and what are Pod Security Standards (PSS)?	`securityContext` settings include: `runAsNonRoot: true`, `runAsUser: 10001`, `runAsGroup: 10001`, `fsGroup: 2000` (Pod-level: sets group ownership on mounted volumes), `readOnlyRootFilesystem: true`, `allowPrivilegeEscalation: false`, `capabilities: { drop: ["ALL"] }`, and `seccompProfile: { type: RuntimeDefault }`. Pod Security Admission enforces three built-in Pod Security Standards via namespace labels (`pod-security.kubernetes.io/enforce`): `privileged`, `baseline`, and `restricted`.
14	What are CustomResourceDefinitions (CRDs) and the Kubernetes Operator Pattern?	A `CustomResourceDefinition` (CRD) extends the Kubernetes API server by registering a new custom resource schema (e.g., `kind: PostgresCluster`, `kind: Certificate`, `kind: Application`) stored in `etcd`. An Operator pairs a CRD with a custom Controller (running as a Pod watching the API server) that embeds domain-specific operational knowledge in a reconciliation loop (comparing `spec` desired state vs `status` actual state) to automate complex stateful tasks like database backups, leader failover, and TLS renewal.
15	What are the ways to inject a `ConfigMap` or `Secret` into a Pod, and which methods automatically update when the `ConfigMap`/`Secret` is modified?	1. Environment Variables (`env.valueFrom.configMapKeyRef`/`secretKeyRef` or `envFrom`): Injected only at container startup; does NOT update dynamically if the ConfigMap/Secret changes (requires Pod restart). 2. Volume Mount (`volumes[].configMap`/`secret`): `kubelet` periodically syncs changes and atomically swaps symlinked files inside the running container! EXCEPTION: If the `volumeMount` uses `subPath` (to mount a single file without hiding the target directory), it does NOT receive automatic updates!
16	Compare Resource `requests` and `limits` for CPU and Memory in a Kubernetes Pod.	`requests`: The minimum guaranteed amount of CPU (`millicores`, e.g., `500m` = 0.5 vCPU) and Memory (`Mi`/`Gi`) reserved for the container; `kube-scheduler` uses ONLY `requests` to decide which node has enough allocatable capacity to place the Pod. `limits`: The maximum ceiling a container is allowed to consume on the node. If a container exceeds its CPU `limit`, the kernel CFS scheduler THROTTLES its CPU cycles; if a container exceeds its Memory `limit`, the kernel OOM Killer terminates it (`OOMKilled`, exit code `137`).
17	How have Kubernetes `ServiceAccount` tokens changed since Kubernetes v1.22 / v1.24 (TokenRequest API)?	Prior to v1.24, creating a `ServiceAccount` automatically generated a non-expiring Secret containing a static JWT token. In modern Kubernetes (v1.24+), no long-lived Secret token is auto-created; instead, `kubelet` uses the `TokenRequest` API and projected volumes to mount a time-bound (e.g., 1-hour auto-rotating), audience-bound JWT token into the Pod at `/var/run/secrets/kubernetes.io/serviceaccount/token` (can be disabled via `automountServiceAccountToken: false`).
18	What are the three Pod Quality of Service (QoS) classes in Kubernetes, how are they assigned, and in what order are Pods evicted under Node Memory Pressure?	1. `Guaranteed`: Every container in the Pod has BOTH `requests` and `limits` set for CPU and Memory, and `requests == limits` for each. 2. `Burstable`: At least one container has a CPU or Memory `request` or `limit` set, but doesn't meet `Guaranteed` criteria. 3. `BestEffort`: NO container in the Pod has any CPU or Memory `requests` or `limits` set at all. Under Node Memory Pressure, `kubelet` evicts Pods in order: `BestEffort` first -> `Burstable` exceeding requests -> `Guaranteed` last.
19	Where does Helm v3 store release state inside a Kubernetes cluster, and how does it differ from Kustomize (`kubectl apply -k`)?	Helm v3 is client-only (removed the legacy Helm v2 `Tiller` server pod) and stores release history and state as compressed, base64-encoded Kubernetes `Secret` objects (`type: helm.sh/release.v1`) directly inside the release's target namespace! Whereas Helm uses Go templating (`{{ ... }}`) and manages release lifecycles/hooks, Kustomize (built natively into `kubectl apply -k`) uses template-free declarative YAML overlays (`kustomization.yaml`, `base/` + `overlays/prod/` with Strategic Merge Patches and JSON 6902 patches).
20	Compare `podAffinity` and `podAntiAffinity`, and explain how `topologyKey` works.	`podAffinity` co-locates a Pod in the same topology domain as other Pods matching a label selector (e.g., placing a web Pod on the same node/zone as its Redis cache Pod). `podAntiAffinity` spreads Pods apart so they do NOT land in the same topology domain (e.g., preventing two replicas of the same database or web deployment from landing on the same physical host: `topologyKey: kubernetes.io/hostname`, or same Availability Zone: `topologyKey: topology.kubernetes.io/zone`).
21	What is the difference between a `ResourceQuota` and a `LimitRange` in a Kubernetes Namespace?	`ResourceQuota`: Enforces an aggregate ceiling across the ENTIRE Namespace (e.g., total sum of all Pods in `dev` cannot exceed `20` vCPUs, `64Gi` RAM, or `10` PVCs). Note: When a CPU/Memory `ResourceQuota` is active in a namespace, every Pod created in that namespace MUST specify CPU/Memory requests/limits or the API server rejects it! `LimitRange`: Solves this by automatically injecting default `requests`/`limits` (`default`, `defaultRequest`) and enforcing min/max bounds per individual Pod/Container.
22	Compare `nodeName`, `nodeSelector`, and `nodeAffinity` for scheduling Pods onto specific Kubernetes nodes.	`nodeName`: Bypasses `kube-scheduler` completely and forces `kubelet` on that exact node to run the Pod. `nodeSelector`: Simplest scheduler filter requiring exact equality on node labels (e.g., `disktype: ssd`). `nodeAffinity`: Expressive scheduling rules supporting `In`, `NotIn`, `Exists`, `DoesNotExist`, `Gt`, `Lt` operators and two modes: `requiredDuringSchedulingIgnoredDuringExecution` (hard requirement: Pod stays `Pending` if unmatched) vs `preferredDuringSchedulingIgnoredDuringExecution` (soft weighted preference).
23	What is the exact procedure to safely upgrade a `kubeadm` Kubernetes cluster from `v1.30.x` to `v1.31.x` (CKA Exam core task)?	Always upgrade ONE minor version at a time! On Control Plane node: 1. Upgrade `kubeadm` package (`apt-mark unhold kubeadm && apt-get update && apt-get install -y kubeadm=1.31.x-* && apt-mark hold kubeadm`); 2. Run `kubeadm upgrade plan` then `sudo kubeadm upgrade apply v1.31.x`; 3. Drain control plane: `kubectl drain controlplane --ignore-daemonsets`; 4. Upgrade `kubelet` and `kubectl` packages, then `systemctl daemon-reload && systemctl restart kubelet`; 5. `kubectl uncordon controlplane`. On each Worker Node: Upgrade `kubeadm` -> `kubectl drain <node> --ignore-daemonsets` -> `sudo kubeadm upgrade node` -> upgrade `kubelet`/`kubectl` & restart `kubelet` -> `kubectl uncordon <node>`.
24	How do you diagnose and fix a Pod stuck in `Pending` vs. `ImagePullBackOff` vs. `CrashLoopBackOff`?	1. `Pending` (not yet scheduled to a node): Run `kubectl describe pod <name>` and check `Events:` at the bottom—usually insufficient CPU/Memory on nodes, untolerated Taints, unmatched `nodeAffinity`, or an unbound `PersistentVolumeClaim`. 2. `ImagePullBackOff` / `ErrImagePull`: Typo in image name/tag, private registry missing `imagePullSecrets`, or node lacks internet/DNS to reach the registry. 3. `CrashLoopBackOff`: Container starts and exits repeatedly; run `kubectl logs <pod> --previous` (`-p`) to view the crash logs of the previous terminated instance, and check entrypoint/args, missing ConfigMap/Secret env vars, failing `livenessProbe`, or `OOMKilled` (`Exit Code 137`).
25	How do you troubleshoot a Worker Node that is in `NotReady` status?	1. Run `kubectl describe node <node>` and check the `Conditions` (`MemoryPressure`, `DiskPressure`, `PIDPressure`, `Ready`). 2. SSH to the worker node and check `kubelet` status: `systemctl status kubelet` and `journalctl -u kubelet -xe` (common causes: `kubelet` stopped/disabled, swap enabled on host `swapoff -a`, misconfigured `/var/lib/kubelet/config.yaml` or CA cert path, expired client certificate, or `containerd` runtime stopped `systemctl status containerd`). 3. Check CNI plugin pods in `kube-system` (`kubectl get pods -n kube-system`).
26	How do MutatingAdmissionWebhook and ValidatingAdmissionWebhook controllers work in the `kube-apiserver` request pipeline?	After Authentication and RBAC Authorization—but BEFORE an object is persisted to `etcd`—the request passes through Admission Control in two phases: 1. Mutating Admission Webhooks run first and can modify the incoming object via JSONPatch (e.g., Istio injecting an Envoy sidecar container, or `LimitRange` injecting default resource requests); 2. Object schema validation runs; 3. Validating Admission Webhooks (and CEL `ValidatingAdmissionPolicy` in K8s 1.30+) run last to accept or reject the final mutated object (e.g., OPA Gatekeeper / Kyverno blocking `:latest` image tags).
27	How do you check for and renew expired TLS certificates on a `kubeadm` Control Plane node?	Run `sudo kubeadm certs check-expiration` to inspect the expiration dates of all control plane PKI certificates in `/etc/kubernetes/pki/` (`apiserver`, `etcd`, `front-proxy-client`, `admin.conf`). To renew all certificates at once: run `sudo kubeadm certs renew all`, then restart the Control Plane static pods (by moving `/etc/kubernetes/manifests/*.yaml` out and back in, or restarting containers) and copy the updated `/etc/kubernetes/admin.conf` to `~/.kube/config`.
28	Why are Kubernetes `Secret` objects NOT secure by default, and how do you secure them in production?	By default, Kubernetes `Secrets` are merely Base64-encoded strings (`echo -n 'pass' \| base64`), NOT encrypted, and are stored in plain text inside `etcd`! Anyone with RBAC `get`/`list`/`watch` on `secrets` (or access to an `etcd` snapshot) can read them. To secure Secrets: 1. Enable Encryption at Rest on `kube-apiserver` (`--encryption-provider-config` using `aescbc`, `secretbox`, or KMS provider v2); 2. Restrict RBAC `watch`/`list` on Secrets; 3. Use External Secrets Operator or CSI Secret Store Driver with Vault/Cloud KMS.
29	What `kubectl` JSONPath and sorting commands are essential for filtering cluster objects quickly?	Sort objects by any field: `kubectl get pods --sort-by=.status.startTime` or `kubectl get pv --sort-by=.spec.capacity.storage`. Extract fields with JSONPath: `kubectl get nodes -o jsonpath='{.items[*].status.addresses[?(@.type=="InternalIP")].address}'` prints all node internal IPs; `kubectl get secret my-secret -o jsonpath='{.data.password}' \| base64 -d` decodes a secret key directly; `kubectl top pods -A --sort-by=cpu` (or `memory`) shows highest resource consumers.
30	How do you test RBAC permissions in Kubernetes using `kubectl auth can-i` and impersonation?	Check your own permissions: `kubectl auth can-i create deployments -n prod`. Check what a specific ServiceAccount or User can do using `--as`: `kubectl auth can-i delete pods --as=system:serviceaccount:dev:backend-sa -n dev`, or list everything a principal is allowed to do with `kubectl auth can-i --list --as=jane`.
31	Compare HorizontalPodAutoscaler (HPA), VerticalPodAutoscaler (VPA), and KEDA in Kubernetes.	HPA (`autoscaling/v2`): Scales the number of Pod `replicas` in a Deployment/StatefulSet based on observed CPU/Memory utilization (`metrics-server` required) or custom metrics ($DesiredReplicas = \lceil CurrentReplicas \times (CurrentMetric / DesiredMetric) \rceil$). VPA: Adjusts the CPU and Memory `requests` and `limits` of Pods vertically (often recreating Pods when resizing, though In-Place Pod Vertical Scaling is emerging). KEDA (Kubernetes Event-driven Autoscaling): Scales deployments from `0` to $N$ replicas based on external event sources like Kafka lag, SQS queue length, or Prometheus queries.
32	Why is binding a `ClusterRole` using a `RoleBinding` (instead of a `ClusterRoleBinding`) a powerful RBAC design pattern?	It allows cluster administrators to define standard reusable permission templates once at the cluster level (such as the built-in `admin`, `edit`, or `view` `ClusterRoles`) and then bind them via a namespaced `RoleBinding` in `namespace: team-a`. The subject receives those permissions ONLY inside `team-a`, avoiding having to duplicate identical `Role` definitions in every namespace.