CKA Exam Tips

Explanation

In the CKA exam, time is your most precious resource. You only have two hours to complete 15-20 tasks, and writing YAML from scratch for every object will burn through your clock fast. Imperative commands like kubectl run, kubectl create, and kubectl expose let you spin up pods, deployments, services, and other resources in seconds rather than minutes. You should memorize the key flags: --image, --port, --replicas, --dry-run=client, and -o yaml. The --dry-run=client -o yaml pattern is especially powerful because it generates a valid YAML manifest that you can redirect to a file and then edit for more complex configurations. Practice chaining these commands so that creating a deployment and exposing it as a service becomes muscle memory. This alone can save you 20-30 minutes across the entire exam.

Explanation

Etcd is the backbone of every Kubernetes cluster — it stores all cluster state, configuration, and secrets. The CKA exam almost always includes a question on backing up and restoring etcd, and it carries significant weight. You need to know how to use etcdctl snapshot save to create a backup and etcdctl snapshot restore to restore from one. The critical detail most candidates miss is that you must set ETCDCTL_API=3 as an environment variable, because etcdctl defaults to API version 2 in some distributions. You also need to provide the correct TLS certificates: the CA certificate, the server certificate, and the server key. These are typically found in /etc/kubernetes/pki/etcd/ on kubeadm-based clusters. After restoring, you must update the etcd manifest to point to the new data directory and restart the etcd pod. Practice this workflow until you can do it confidently in under five minutes.

Explanation

RBAC (Role-Based Access Control) is a core security mechanism in Kubernetes and a frequent topic on the CKA exam. You need to be able to create ServiceAccounts, Roles, and RoleBindings quickly and correctly. A Role defines what actions (verbs) are allowed on which resources within a specific namespace, while a RoleBinding associates that Role with a user or ServiceAccount. For cluster-wide permissions, you use ClusterRole and ClusterRoleBinding instead. The imperative approach is fastest: use kubectl create serviceaccount, kubectl create role, and kubectl create rolebinding with the correct flags. Pay careful attention to the namespace — Roles and RoleBindings are namespaced objects, so you must specify the namespace explicitly. Also know the difference between a RoleBinding that references a Role versus one that references a ClusterRole, as the latter grants cluster-level permissions scoped to a namespace. Practice until you can complete the full RBAC chain in under three minutes.

Explanation

NetworkPolicy is one of the most challenging topics on the CKA exam because it requires understanding both Kubernetes networking concepts and YAML policy structure. The best strategy is to always start with a default deny policy that blocks all ingress and/or egress traffic to pods in a namespace, then create additional policies that explicitly allow only the traffic you need. This defense-in-depth approach matches real-world security practices and is exactly what exam questions expect. Remember that NetworkPolicies are additive — if any policy allows traffic, it is permitted, and there is no way to explicitly deny traffic that another policy allows. The podSelector field determines which pods the policy applies to, while ingress.from and egress.to define the allowed sources and destinations using podSelector, namespaceSelector, or ipBlock. An empty podSelector ({}) selects all pods in the namespace. Practice writing these policies from memory, because you will not have time to look up every field during the exam.

Explanation

On Kubernetes certification exams, time is your biggest constraint. Writing YAML from scratch is too slow. The fastest method is to use imperative `kubectl` commands with `--dry-run=client -o yaml` to generate a valid manifest. Redirect this output to a file, make the necessary edits with `vi`, and then apply it. Memorize the key generator flags for `kubectl create deployment` (`--image`, `--replicas`), `kubectl create service` (`--port`, `--target-port`, `--type`), and `kubectl create configmap/secret` (`--from-literal`, `--from-file`). For quick modifications, `kubectl set image` and `kubectl scale` are faster than editing the file again. **Exam Trap**: Always use `--dry-run=client`. The `--dry-run=server` flag still communicates with the API server and can fail on RBAC checks or other validations, wasting time. Also, be aware that `kubectl run` is now primarily for creating temporary debugging pods; use `kubectl create deployment` for creating deployments. A useful shortcut is to set `alias k=kubectl` at the start of your exam.

Explanation

Etcd backup is a critical, high-value CKA task. First, SSH to the control plane node. Before running any `etcdctl` commands, you must `export ETCDCTL_API=3`. The required TLS certificate paths are not secret; find them by inspecting the etcd static pod manifest at `/etc/kubernetes/manifests/etcd.yaml`. Copy the values for `--cacert`, `--cert`, `--key`, and `--endpoints` directly from the manifest's command arguments. For backup, use `etcdctl snapshot save`. For restore, the process is more involved: first, stop the kube-apiserver to prevent it from interfering. Then, run `etcdctl snapshot restore` to a *new* data directory. Finally, edit the `etcd.yaml` manifest to update the `hostPath` volume to point to your new restored data directory. The kubelet will detect the change and restart the etcd pod. **Exam Trap**: Forgetting to stop the API server before restore, or restoring over the live data directory instead of a new one.

Explanation

A systematic approach is key for troubleshooting tasks. Follow this order: 1. **`kubectl describe pod <name>`**: This is your most important command. The `Events` section at the bottom will tell you the root cause of most issues like `ImagePullBackOff`, `CrashLoopBackOff`, failed volume mounts, or failed probes. 2. **`kubectl logs <pod>`**: If the pod is running but misbehaving, check its logs. For a pod in a crash loop, use `kubectl logs <pod> --previous` to see the logs from the last failed container instance. 3. **`kubectl get events`**: If the issue is not obvious from the pod description (e.g., a pod is stuck in `Pending`), check cluster-wide events with `kubectl get events --sort-by='.lastTimestamp'`. This can reveal node resource pressure or scheduling failures. 4. **`kubectl exec`**: If the pod is running but has network issues, `exec` into it to run `curl`, `wget`, or `ping` to test connectivity to other services. **Exam Trap**: Ignoring `Init:Error` status. If an init container fails, the main containers will never start. Check their logs specifically with `kubectl logs <pod> -c <init-container-name>`.

Explanation

Many exam tasks begin with `Use the clusterX context...`. Failing to switch context is the easiest way to get zero points for a perfectly solved problem. Before starting any task, read the context-switching command provided and execute it. Then, set the namespace for that context so you don't have to type `-n <namespace>` on every command. Always verify your current context and namespace before applying any resources. **Exam Trap**: The question will provide the exact command like `kubectl config use-context cluster-2`. Copy and paste it. Do not guess or assume. A common mistake is solving the entire problem in the `default` namespace when the question specified a different one. Get in the habit of running `kubectl config set-context --current --namespace=<ns>` immediately after switching clusters.