@xdev-asia/xdev-knowledge-mcp 1.0.52 → 1.0.53

package/data/quizzes/cka.json

@@ -0,0 +1,319 @@
+{
+    "id": "cka",
+    "title": "CKA — Certified Kubernetes Administrator",
+    "slug": "cka",
+    "description": "Practice exam for CKA — 20 questions covering all 5 domains",
+    "icon": "award",
+    "provider": "CNCF",
+    "level": "Professional",
+    "duration_minutes": 45,
+    "passing_score": 66,
+    "questions_count": 20,
+    "tags": ["Kubernetes", "CKA", "CNCF", "DevOps", "Linux Foundation"],
+    "series_slug": "luyen-thi-cka",
+    "domains": [
+        {
+            "name": "Domain 1: Cluster Architecture, Installation & Configuration",
+            "weight": 25,
+            "lessons": [
+                { "title": "Bài 1: Kubernetes Architecture & kubeadm Cluster Setup", "slug": "01-kien-truc-cka-kubeadm" },
+                { "title": "Bài 2: Cluster Upgrade với kubeadm", "slug": "02-cluster-upgrade-kubeadm" },
+                { "title": "Bài 3: RBAC — Role-Based Access Control", "slug": "03-rbac-cka" }
+            ]
+        },
+        {
+            "name": "Domain 2: Workloads & Scheduling",
+            "weight": 15,
+            "lessons": [
+                { "title": "Bài 4: Deployments, DaemonSets & StatefulSets", "slug": "04-deployments-daemonsets-statefulsets" },
+                { "title": "Bài 5: Scheduling — Taints, Tolerations & Affinity", "slug": "05-scheduling-taints-affinity" }
+            ]
+        },
+        {
+            "name": "Domain 3: Services & Networking",
+            "weight": 20,
+            "lessons": [
+                { "title": "Bài 6: Services, Endpoints & CoreDNS", "slug": "06-services-endpoints-coredns" },
+                { "title": "Bài 7: Ingress, Network Policies & CNI", "slug": "07-ingress-networkpolicies-cni" }
+            ]
+        },
+        {
+            "name": "Domain 4: Storage",
+            "weight": 10,
+            "lessons": [
+                { "title": "Bài 8: Persistent Volumes, PVCs & StorageClass", "slug": "08-persistent-volumes-storageclass" }
+            ]
+        },
+        {
+            "name": "Domain 5: Troubleshooting",
+            "weight": 30,
+            "lessons": [
+                { "title": "Bài 9: etcd Backup & Restore", "slug": "09-etcd-backup-restore" },
+                { "title": "Bài 10: Troubleshooting Nodes & Cluster", "slug": "10-troubleshooting-nodes" },
+                { "title": "Bài 11: Troubleshooting Workloads", "slug": "11-troubleshooting-workloads" }
+            ]
+        }
+    ],
+    "questions": [
+        {
+            "id": 1,
+            "domain": "Domain 1: Cluster Architecture, Installation & Configuration",
+            "question": "You need to upgrade a Kubernetes cluster from v1.29 to v1.30 using kubeadm. What is the CORRECT order of operations?",
+            "options": [
+                "Upgrade worker nodes first, then upgrade control plane",
+                "Upgrade kubeadm on control plane, run kubeadm upgrade plan/apply, upgrade kubelet and kubectl, then upgrade worker nodes",
+                "Upgrade kubelet on all nodes simultaneously",
+                "Upgrade kubectl first, then kubeadm, then kubelet"
+            ],
+            "correct": 1,
+            "explanation": "The correct upgrade order is: upgrade kubeadm → run kubeadm upgrade plan → kubeadm upgrade apply on the control plane → upgrade kubelet and kubectl on control plane → then repeat for each worker node (drain, upgrade kubeadm/kubelet, uncordon)."
+        },
+        {
+            "id": 2,
+            "domain": "Domain 1: Cluster Architecture, Installation & Configuration",
+            "question": "Which kubectl command checks if a user has permission to create deployments in the 'production' namespace?",
+            "options": [
+                "kubectl get roles -n production",
+                "kubectl auth can-i create deployments -n production",
+                "kubectl describe clusterrole admin",
+                "kubectl check-access deployments -n production"
+            ],
+            "correct": 1,
+            "explanation": "kubectl auth can-i checks whether an action is allowed. 'kubectl auth can-i create deployments -n production' checks if the current user can create deployments in the production namespace."
+        },
+        {
+            "id": 3,
+            "domain": "Domain 1: Cluster Architecture, Installation & Configuration",
+            "question": "A RoleBinding binds a ClusterRole to a user in namespace 'dev'. What is the scope of the permissions?",
+            "options": [
+                "Cluster-wide, because ClusterRole is cluster-scoped",
+                "Limited to the 'dev' namespace only",
+                "All namespaces except 'dev'",
+                "It will result in an error — ClusterRole cannot be used with RoleBinding"
+            ],
+            "correct": 1,
+            "explanation": "When a RoleBinding references a ClusterRole, the permissions are scoped to the RoleBinding's namespace only. This is a common pattern to reuse a set of permissions defined in a ClusterRole across multiple namespaces."
+        },
+        {
+            "id": 4,
+            "domain": "Domain 1: Cluster Architecture, Installation & Configuration",
+            "question": "What is the Kubernetes version skew policy for kubelet relative to kube-apiserver?",
+            "options": [
+                "kubelet must be the exact same version as kube-apiserver",
+                "kubelet can be up to 3 minor versions older than kube-apiserver",
+                "kubelet can be up to 2 minor versions older than kube-apiserver, but not newer",
+                "There is no version requirement between kubelet and kube-apiserver"
+            ],
+            "correct": 2,
+            "explanation": "kubelet may be up to two minor versions older than kube-apiserver but must not be newer. For example, kube-apiserver 1.30 supports kubelet 1.28, 1.29, and 1.30."
+        },
+        {
+            "id": 5,
+            "domain": "Domain 2: Workloads & Scheduling",
+            "question": "A pod is in 'Pending' state. kubectl describe shows 'insufficient cpu'. What is the MOST likely cause?",
+            "options": [
+                "The container image is too large",
+                "No node has enough allocatable CPU to satisfy the pod's resource requests",
+                "The pod has a failed liveness probe",
+                "The pod's service account doesn't have sufficient permissions"
+            ],
+            "correct": 1,
+            "explanation": "When a pod is Pending with 'insufficient cpu', it means the scheduler cannot find a node with enough available CPU resources to satisfy the pod's resource requests. Solutions include adding nodes, reducing requests, or removing resource-heavy pods."
+        },
+        {
+            "id": 6,
+            "domain": "Domain 2: Workloads & Scheduling",
+            "question": "How do you ensure a pod is scheduled ONLY on nodes with the label 'disk=ssd'?",
+            "options": [
+                "Use a taint on the nodes with disk=ssd",
+                "Use nodeSelector with disk: ssd in the pod spec",
+                "Use a PodDisruptionBudget",
+                "Use podAntiAffinity"
+            ],
+            "correct": 1,
+            "explanation": "nodeSelector is the simplest way to constrain pods to nodes with specific labels. Adding 'nodeSelector: { disk: ssd }' to the pod spec ensures the pod is only scheduled on nodes with that label."
+        },
+        {
+            "id": 7,
+            "domain": "Domain 2: Workloads & Scheduling",
+            "question": "What is the effect of adding a taint 'key=value:NoSchedule' to a node?",
+            "options": [
+                "All existing pods without a matching toleration are evicted immediately",
+                "No new pods will be scheduled on the node unless they have a matching toleration",
+                "The node is removed from the cluster",
+                "All pods on the node are restarted"
+            ],
+            "correct": 1,
+            "explanation": "NoSchedule prevents new pods without a matching toleration from being scheduled on the node. Existing pods are NOT affected. Use NoExecute to also evict existing non-tolerating pods."
+        },
+        {
+            "id": 8,
+            "domain": "Domain 3: Services & Networking",
+            "question": "What is the DNS format for resolving a Service named 'my-svc' in namespace 'my-ns'?",
+            "options": [
+                "my-svc.my-ns",
+                "my-svc.my-ns.svc.cluster.local",
+                "my-ns.my-svc.cluster.local",
+                "svc.my-svc.my-ns.cluster.local"
+            ],
+            "correct": 1,
+            "explanation": "Kubernetes DNS follows the format: <service-name>.<namespace>.svc.cluster.local. Within the same namespace, you can use just the service name. Across namespaces, use <service-name>.<namespace>."
+        },
+        {
+            "id": 9,
+            "domain": "Domain 3: Services & Networking",
+            "question": "An Ingress resource routes traffic to a backend service. The Ingress controller pod is running but rules are not taking effect. What should you check FIRST?",
+            "options": [
+                "Whether the Ingress has the correct ingressClassName",
+                "Whether etcd is healthy",
+                "Whether the node has enough memory",
+                "Whether kube-scheduler is running"
+            ],
+            "correct": 0,
+            "explanation": "If Ingress rules are not working despite the controller running, the first check should be ingressClassName. In Kubernetes 1.22+, Ingress resources need to specify the correct IngressClass to be picked up by the right controller."
+        },
+        {
+            "id": 10,
+            "domain": "Domain 3: Services & Networking",
+            "question": "You created a NetworkPolicy with an empty podSelector {}. What is the effect?",
+            "options": [
+                "It selects no pods in the namespace",
+                "It selects all pods in the namespace",
+                "It causes a validation error",
+                "It applies to the entire cluster"
+            ],
+            "correct": 1,
+            "explanation": "An empty podSelector {} selects ALL pods in the namespace. A NetworkPolicy with spec.podSelector: {} and no ingress/egress rules effectively creates a default-deny policy for all pods in that namespace."
+        },
+        {
+            "id": 11,
+            "domain": "Domain 3: Services & Networking",
+            "question": "Which kube-proxy mode is MOST performant for large clusters with many Services?",
+            "options": [
+                "userspace mode",
+                "iptables mode",
+                "IPVS mode",
+                "nftables mode"
+            ],
+            "correct": 2,
+            "explanation": "IPVS (IP Virtual Server) mode uses hash tables for Service-to-Pod mapping, providing O(1) lookup performance regardless of the number of Services, making it much more efficient than iptables for large clusters."
+        },
+        {
+            "id": 12,
+            "domain": "Domain 4: Storage",
+            "question": "A PersistentVolume has reclaimPolicy set to 'Retain'. What happens when the associated PVC is deleted?",
+            "options": [
+                "The PV and its data are automatically deleted",
+                "The PV remains with its data intact but it becomes 'Released' and cannot be bound to a new PVC without manual intervention",
+                "The PV is immediately available for a new PVC to claim",
+                "The data is archived to an object store"
+            ],
+            "correct": 1,
+            "explanation": "With Retain policy, when the PVC is deleted, the PV enters 'Released' state. The data is preserved, but the PV cannot be rebound automatically. An admin must manually clean up and reconfigure the PV for reuse."
+        },
+        {
+            "id": 13,
+            "domain": "Domain 4: Storage",
+            "question": "Which access mode allows a PersistentVolume to be mounted as read-write by multiple nodes simultaneously?",
+            "options": [
+                "ReadWriteOnce (RWO)",
+                "ReadOnlyMany (ROX)",
+                "ReadWriteMany (RWX)",
+                "ReadWriteOncePod (RWOP)"
+            ],
+            "correct": 2,
+            "explanation": "ReadWriteMany (RWX) allows the volume to be mounted as read-write by many nodes simultaneously. This is commonly supported by network file systems like NFS, CephFS, and cloud-native shared file storage."
+        },
+        {
+            "id": 14,
+            "domain": "Domain 5: Troubleshooting",
+            "question": "You need to take a snapshot of etcd for backup. Which tool and flags are required?",
+            "options": [
+                "kubectl backup etcd --output=/backup/snapshot.db",
+                "etcdctl snapshot save /backup/snapshot.db --endpoints --cacert --cert --key",
+                "kubeadm backup etcd --snapshot-dir=/backup",
+                "etcdctl backup --data-dir=/var/lib/etcd"
+            ],
+            "correct": 1,
+            "explanation": "etcdctl snapshot save is the correct command. It requires TLS flags: --endpoints (etcd address), --cacert (CA certificate), --cert (server certificate), and --key (server key), all found in the etcd pod manifest."
+        },
+        {
+            "id": 15,
+            "domain": "Domain 5: Troubleshooting",
+            "question": "A node shows 'NotReady' status. Which is the FIRST thing to check?",
+            "options": [
+                "Check if kube-proxy is running",
+                "Check if kubelet is running on the node (systemctl status kubelet)",
+                "Check if CoreDNS pods are healthy",
+                "Check if the container images are cached"
+            ],
+            "correct": 1,
+            "explanation": "A NotReady node typically means kubelet is not communicating with the API server. The first step is to SSH into the node and check kubelet status with 'systemctl status kubelet', then check logs with 'journalctl -u kubelet'."
+        },
+        {
+            "id": 16,
+            "domain": "Domain 5: Troubleshooting",
+            "question": "A pod is in CrashLoopBackOff state. Which command is MOST useful to diagnose the issue?",
+            "options": [
+                "kubectl get events",
+                "kubectl logs <pod-name> --previous",
+                "kubectl describe node",
+                "kubectl top pod"
+            ],
+            "correct": 1,
+            "explanation": "kubectl logs <pod-name> --previous shows logs from the previous crashed container instance. This reveals the actual error (e.g., application error, missing config) that caused the crash."
+        },
+        {
+            "id": 17,
+            "domain": "Domain 5: Troubleshooting",
+            "question": "A Deployment's pods cannot reach a ClusterIP Service. The Service has endpoints. What should you check?",
+            "options": [
+                "Whether the Service has the correct selector matching the pod labels",
+                "Whether there's a NetworkPolicy blocking traffic between the source pods and the Service",
+                "Whether the Deployment has enough replicas",
+                "Whether the node has sufficient disk space"
+            ],
+            "correct": 1,
+            "explanation": "If the Service has endpoints (backends are matched), but pods can't reach it, a NetworkPolicy may be blocking traffic. Check for NetworkPolicies in both the source and destination namespaces that could restrict ingress or egress."
+        },
+        {
+            "id": 18,
+            "domain": "Domain 5: Troubleshooting",
+            "question": "After restoring etcd from a snapshot, the API server shows stale data. What is the MOST likely cause?",
+            "options": [
+                "The snapshot file was corrupted",
+                "The etcd data-dir was not updated to point to the restored snapshot location",
+                "kube-apiserver needs a version upgrade",
+                "CoreDNS needs to be restarted"
+            ],
+            "correct": 1,
+            "explanation": "After restoring, you must update the etcd pod manifest (or systemd unit) to point --data-dir to the new restored directory. If the old data-dir is still being used, etcd will serve stale data."
+        },
+        {
+            "id": 19,
+            "domain": "Domain 5: Troubleshooting",
+            "question": "A pod is stuck in 'ImagePullBackOff' state. Which is NOT a possible cause?",
+            "options": [
+                "The image name or tag is incorrect",
+                "The container registry requires authentication and no imagePullSecret is configured",
+                "The node has insufficient CPU resources",
+                "Network connectivity to the registry is blocked"
+            ],
+            "correct": 2,
+            "explanation": "ImagePullBackOff indicates the kubelet cannot pull the container image. This can be due to wrong image name, missing registry credentials, or network issues — but NOT CPU resources. CPU issues cause Pending state, not ImagePullBackOff."
+        },
+        {
+            "id": 20,
+            "domain": "Domain 5: Troubleshooting",
+            "question": "How would you check which static pod manifests are being used on a node?",
+            "options": [
+                "kubectl get staticpods",
+                "Check the directory specified by kubelet's --pod-manifest-path flag (default: /etc/kubernetes/manifests/)",
+                "kubectl describe node | grep StaticPods",
+                "etcdctl get /registry/pods"
+            ],
+            "correct": 1,
+            "explanation": "Static pods are defined by manifest files in the directory configured via --pod-manifest-path (default /etc/kubernetes/manifests/). kubelet watches this directory and automatically creates/deletes pods based on these manifests."
+        }
+    ]
+}

package/data/quizzes/ckad.json

@@ -0,0 +1,318 @@
+{
+    "id": "ckad",
+    "title": "CKAD — Certified Kubernetes Application Developer",
+    "slug": "ckad",
+    "description": "Practice exam for CKAD — 20 questions covering all 5 domains",
+    "icon": "award",
+    "provider": "CNCF",
+    "level": "Professional",
+    "duration_minutes": 45,
+    "passing_score": 66,
+    "questions_count": 20,
+    "tags": ["Kubernetes", "CKAD", "CNCF", "DevOps", "Linux Foundation"],
+    "series_slug": "luyen-thi-ckad",
+    "domains": [
+        {
+            "name": "Domain 1: Application Design and Build",
+            "weight": 20,
+            "lessons": [
+                { "title": "Bài 1: Container Images & Multi-stage Builds", "slug": "01-container-images-multi-stage" },
+                { "title": "Bài 2: Pod Design — Labels, Selectors, Annotations", "slug": "02-pod-design-labels-selectors" }
+            ]
+        },
+        {
+            "name": "Domain 2: Application Deployment",
+            "weight": 20,
+            "lessons": [
+                { "title": "Bài 3: Deployments, Rolling Updates & Rollbacks", "slug": "03-deployments-rolling-updates" },
+                { "title": "Bài 4: Helm Basics — Charts, Releases, Repositories", "slug": "04-helm-basics" }
+            ]
+        },
+        {
+            "name": "Domain 3: Application Observability and Maintenance",
+            "weight": 15,
+            "lessons": [
+                { "title": "Bài 5: Probes — Liveness, Readiness, Startup", "slug": "05-probes-liveness-readiness" },
+                { "title": "Bài 6: Logging, Monitoring & Debugging", "slug": "06-logging-monitoring-debugging" }
+            ]
+        },
+        {
+            "name": "Domain 4: Application Environment, Configuration and Security",
+            "weight": 25,
+            "lessons": [
+                { "title": "Bài 7: ConfigMaps & Secrets", "slug": "07-configmaps-secrets" },
+                { "title": "Bài 8: ServiceAccounts & Security Contexts", "slug": "08-serviceaccounts-security" },
+                { "title": "Bài 9: Resource Requests, Limits & LimitRanges", "slug": "09-resource-requests-limits" }
+            ]
+        },
+        {
+            "name": "Domain 5: Services and Networking",
+            "weight": 20,
+            "lessons": [
+                { "title": "Bài 10: Services, Ingress & Network Policies", "slug": "10-services-ingress-networkpolicies" }
+            ]
+        }
+    ],
+    "questions": [
+        {
+            "id": 1,
+            "domain": "Domain 1: Application Design and Build",
+            "question": "Which Dockerfile instruction is used to set the command that runs when the container starts, and CAN be overridden by the user at runtime?",
+            "options": [
+                "ENTRYPOINT",
+                "CMD",
+                "RUN",
+                "EXPOSE"
+            ],
+            "correct": 1,
+            "explanation": "CMD sets the default command for the container, which can be overridden by passing arguments to docker run or in the Kubernetes pod spec's command/args fields. ENTRYPOINT sets the main executable and is harder to override."
+        },
+        {
+            "id": 2,
+            "domain": "Domain 1: Application Design and Build",
+            "question": "What is the benefit of a multi-stage Docker build?",
+            "options": [
+                "It allows running multiple containers in a single pod",
+                "It reduces the final image size by separating build-time dependencies from runtime",
+                "It enables horizontal pod autoscaling",
+                "It automatically creates Kubernetes manifests"
+            ],
+            "correct": 1,
+            "explanation": "Multi-stage builds use multiple FROM instructions. Build tools and dependencies stay in earlier stages while only the compiled artifact is copied to the final, minimal runtime image — significantly reducing image size."
+        },
+        {
+            "id": 3,
+            "domain": "Domain 1: Application Design and Build",
+            "question": "You want to select all pods with label 'app=web' AND 'tier=frontend'. Which label selector syntax is correct?",
+            "options": [
+                "app=web || tier=frontend",
+                "app=web,tier=frontend",
+                "app=web AND tier=frontend",
+                "app=web;tier=frontend"
+            ],
+            "correct": 1,
+            "explanation": "In Kubernetes, multiple label selectors are comma-separated. 'app=web,tier=frontend' selects pods that have BOTH labels. This is used in kubectl: 'kubectl get pods -l app=web,tier=frontend'."
+        },
+        {
+            "id": 4,
+            "domain": "Domain 1: Application Design and Build",
+            "question": "How do you create a CronJob that runs every day at 3:00 AM?",
+            "options": [
+                "schedule: '3 0 * * *'",
+                "schedule: '0 3 * * *'",
+                "schedule: '* * 3 * *'",
+                "schedule: 'daily 3:00'"
+            ],
+            "correct": 1,
+            "explanation": "Cron format is: minute hour day-of-month month day-of-week. '0 3 * * *' means at minute 0, hour 3 (3:00 AM), every day of month, every month, every day of week."
+        },
+        {
+            "id": 5,
+            "domain": "Domain 2: Application Deployment",
+            "question": "A Deployment with 4 replicas uses the RollingUpdate strategy with maxSurge=1 and maxUnavailable=0. How many pods exist during an update?",
+            "options": [
+                "Exactly 4 pods at all times",
+                "Up to 5 pods (4 desired + 1 surge)",
+                "Between 3 and 5 pods",
+                "Up to 8 pods (doubled)"
+            ],
+            "correct": 1,
+            "explanation": "maxSurge=1 allows one extra pod above the desired count (4+1=5). maxUnavailable=0 means all 4 desired pods must remain available. So Kubernetes creates a new pod first, waits for it to be ready, then terminates an old one."
+        },
+        {
+            "id": 6,
+            "domain": "Domain 2: Application Deployment",
+            "question": "How do you rollback a Deployment named 'web-app' to its previous version?",
+            "options": [
+                "kubectl rollback deployment web-app",
+                "kubectl rollout undo deployment web-app",
+                "kubectl revert deployment web-app",
+                "kubectl apply --previous deployment web-app"
+            ],
+            "correct": 1,
+            "explanation": "kubectl rollout undo deployment <name> rolls back to the previous revision. You can also specify a revision with --to-revision=N. Use 'kubectl rollout history' to view available revisions."
+        },
+        {
+            "id": 7,
+            "domain": "Domain 2: Application Deployment",
+            "question": "You installed a Helm chart with 'helm install my-release bitnami/nginx'. How do you update the release with new values?",
+            "options": [
+                "helm update my-release bitnami/nginx -f values.yaml",
+                "helm upgrade my-release bitnami/nginx -f values.yaml",
+                "helm apply my-release bitnami/nginx -f values.yaml",
+                "helm install --upgrade my-release bitnami/nginx -f values.yaml"
+            ],
+            "correct": 1,
+            "explanation": "helm upgrade is used to update an existing release with new chart versions or values. The -f flag specifies a custom values file. Use --install flag to install if the release doesn't exist yet."
+        },
+        {
+            "id": 8,
+            "domain": "Domain 2: Application Deployment",
+            "question": "What does a Blue-Green deployment strategy ensure?",
+            "options": [
+                "Traffic is gradually shifted from old to new version",
+                "Two complete environments exist, and traffic is switched entirely from one to the other",
+                "Only one pod is updated at a time",
+                "The deployment is paused until manually approved"
+            ],
+            "correct": 1,
+            "explanation": "Blue-Green deployment maintains two identical environments (Blue=current, Green=new). Once the Green environment is verified, traffic is switched entirely to Green. This enables instant rollback by switching back to Blue."
+        },
+        {
+            "id": 9,
+            "domain": "Domain 3: Application Observability and Maintenance",
+            "question": "A pod's readinessProbe fails. What is the consequence?",
+            "options": [
+                "The pod is restarted",
+                "The pod is removed from the Service's endpoints (stops receiving traffic)",
+                "The pod is deleted and a new one is created",
+                "The node is marked as NotReady"
+            ],
+            "correct": 1,
+            "explanation": "When a readinessProbe fails, the pod is removed from Service endpoints and stops receiving traffic. Unlike livenessProbe, a failed readinessProbe does NOT restart the pod — it just marks it as not ready to serve."
+        },
+        {
+            "id": 10,
+            "domain": "Domain 3: Application Observability and Maintenance",
+            "question": "Which probe type should you use for a container that takes a long time to start up?",
+            "options": [
+                "livenessProbe with a high initialDelaySeconds",
+                "readinessProbe with failureThreshold=100",
+                "startupProbe",
+                "execProbe"
+            ],
+            "correct": 2,
+            "explanation": "startupProbe is specifically designed for slow-starting containers. When defined, it disables liveness and readiness checks until the container starts successfully. This prevents premature restarts by the livenessProbe."
+        },
+        {
+            "id": 11,
+            "domain": "Domain 3: Application Observability and Maintenance",
+            "question": "How do you view real-time logs from multiple pods of a Deployment named 'api'?",
+            "options": [
+                "kubectl logs deployment/api --all",
+                "kubectl logs -l app=api --follow",
+                "kubectl exec deployment/api -- tail -f /var/log/app.log",
+                "kubectl describe deployment api | grep logs"
+            ],
+            "correct": 1,
+            "explanation": "kubectl logs -l <label-selector> streams logs from all pods matching the label. --follow (-f) enables real-time streaming. This is useful for debugging across multiple replicas simultaneously."
+        },
+        {
+            "id": 12,
+            "domain": "Domain 4: Application Environment, Configuration and Security",
+            "question": "How do you create a ConfigMap from a file named 'app.properties'?",
+            "options": [
+                "kubectl create configmap my-config --from-file=app.properties",
+                "kubectl apply configmap my-config --file=app.properties",
+                "kubectl create secret generic my-config --from-file=app.properties",
+                "kubectl create configmap my-config --data=app.properties"
+            ],
+            "correct": 0,
+            "explanation": "kubectl create configmap --from-file=<filename> creates a ConfigMap with the file's content. The key defaults to the filename. Use --from-file=<key>=<filename> to specify a custom key."
+        },
+        {
+            "id": 13,
+            "domain": "Domain 4: Application Environment, Configuration and Security",
+            "question": "What is the difference between a ConfigMap and a Secret in terms of data storage?",
+            "options": [
+                "Secrets are encrypted at rest by default, ConfigMaps are not",
+                "Secrets store data as base64-encoded strings, ConfigMaps store plain text",
+                "ConfigMaps can only store key-value pairs, Secrets can store files",
+                "There is no difference, they are interchangeable"
+            ],
+            "correct": 1,
+            "explanation": "Secrets store data as base64-encoded strings (not encrypted by default). etcd encryption at rest must be configured separately. ConfigMaps store plain text data. Both can be mounted as volumes or used as environment variables."
+        },
+        {
+            "id": 14,
+            "domain": "Domain 4: Application Environment, Configuration and Security",
+            "question": "A pod's SecurityContext has 'runAsNonRoot: true'. What happens if the container image runs as root by default?",
+            "options": [
+                "The container runs as root anyway",
+                "The pod fails to start with a security validation error",
+                "Kubernetes automatically assigns a random non-root UID",
+                "The runAsNonRoot setting is ignored"
+            ],
+            "correct": 1,
+            "explanation": "With runAsNonRoot: true, if the container's image is configured to run as root (UID 0) and no runAsUser is specified, the pod will fail to start. You must either set runAsUser to a non-root UID or use an image that runs as non-root."
+        },
+        {
+            "id": 15,
+            "domain": "Domain 4: Application Environment, Configuration and Security",
+            "question": "What happens when a container exceeds its memory LIMIT?",
+            "options": [
+                "The container is throttled to the limit",
+                "The container is OOMKilled (Out of Memory Killed)",
+                "A warning event is generated but the container continues",
+                "The pod is rescheduled to a node with more memory"
+            ],
+            "correct": 1,
+            "explanation": "When a container exceeds its memory limit, the kernel's OOM killer terminates it (OOMKilled). This is different from CPU limits, where the container is throttled rather than killed. Kubernetes then restarts the container based on restartPolicy."
+        },
+        {
+            "id": 16,
+            "domain": "Domain 4: Application Environment, Configuration and Security",
+            "question": "How do you mount a specific key from a ConfigMap as a file in a pod?",
+            "options": [
+                "Use volumeMounts with subPath matching the key name",
+                "Use env.valueFrom.configMapKeyRef",
+                "ConfigMaps can only be mounted as entire directories",
+                "Use configMap.items with key and path in the volume definition"
+            ],
+            "correct": 3,
+            "explanation": "In the volume definition, use configMap.items to specify which keys to include and their file paths. For example: items: [{key: 'app.conf', path: 'app.conf'}]. SubPath can also be used in volumeMounts for single-key mounting."
+        },
+        {
+            "id": 17,
+            "domain": "Domain 5: Services and Networking",
+            "question": "What is the difference between a ClusterIP and a NodePort Service?",
+            "options": [
+                "ClusterIP exposes the service externally, NodePort is internal only",
+                "ClusterIP is accessible only within the cluster, NodePort exposes the service on each node's IP at a static port",
+                "ClusterIP uses TCP, NodePort uses UDP",
+                "ClusterIP requires an Ingress, NodePort does not"
+            ],
+            "correct": 1,
+            "explanation": "ClusterIP (default) creates an internal-only virtual IP. NodePort exposes the service on each node's IP at a port in the range 30000-32767, making it accessible from outside the cluster via <NodeIP>:<NodePort>."
+        },
+        {
+            "id": 18,
+            "domain": "Domain 5: Services and Networking",
+            "question": "An Ingress resource routes '/api' to service 'api-svc' and '/web' to service 'web-svc'. Which annotation controls URL rewriting in nginx ingress?",
+            "options": [
+                "nginx.ingress.kubernetes.io/rewrite-target: /",
+                "nginx.ingress.kubernetes.io/url-rewrite: true",
+                "nginx.ingress.kubernetes.io/path-redirect: /",
+                "nginx.ingress.kubernetes.io/backend-path: /"
+            ],
+            "correct": 0,
+            "explanation": "nginx.ingress.kubernetes.io/rewrite-target controls the URL rewriting. Setting it to '/' rewrites the matched path to '/'. For example, a request to '/api/users' would be forwarded to the backend as '/users'."
+        },
+        {
+            "id": 19,
+            "domain": "Domain 5: Services and Networking",
+            "question": "A NetworkPolicy allows ingress only from pods with label 'role=frontend' on port 8080. A pod with label 'role=backend' tries to connect on port 8080. What happens?",
+            "options": [
+                "The connection is allowed because port 8080 is open",
+                "The connection is denied because the source pod doesn't match the ingress rule",
+                "The NetworkPolicy is ignored because it only affects egress",
+                "The connection times out only if the CNI plugin doesn't support NetworkPolicy"
+            ],
+            "correct": 1,
+            "explanation": "NetworkPolicy ingress rules specify both 'from' (source pods/namespaces) and 'ports'. Even though port 8080 matches, the source pod doesn't have label 'role=frontend', so the connection is denied."
+        },
+        {
+            "id": 20,
+            "domain": "Domain 5: Services and Networking",
+            "question": "Which Service type automatically provisions a cloud load balancer?",
+            "options": [
+                "ClusterIP",
+                "NodePort",
+                "LoadBalancer",
+                "ExternalName"
+            ],
+            "correct": 2,
+            "explanation": "LoadBalancer type automatically provisions an external load balancer (e.g., AWS ELB, GCP Load Balancer). It builds on NodePort, which builds on ClusterIP. ExternalName maps a Service to a DNS name without any proxy."
+        }
+    ]
+}