Kubernetes and Cloud Native Associate (KCNA) #8: Exam Tips and Common Mistakes
From #2 through #7 we covered all five domains. This post is a condensed recap to read one more time right before you walk in to take the exam. There are no new domains here; instead it gathers, in one place, the patterns where candidates lose the most points across the series, how to avoid them, and the pairs of easily confused concepts. Keep in mind that KCNA is a multiple-choice exam — 60 questions in 90 minutes with a 75% passing score — and that it is offered only via online proctoring (PSI).
A 90-minute game plan #
Time allocation #
You have to answer 60 questions in 90 minutes. The naive math is 1 minute 30 seconds per question on average, but here is how to actually run it.
| Phase | Time | Action |
|---|---|---|
| First pass | 55 min (≈ 55 sec/question) | Answer only the questions you can solve without getting stuck. If you stall, immediately Flag for Review |
| Second pass | 25 min | Revisit only the flagged questions |
| Review | 10 min | Confirm every question has an answer. Recheck the answer count on multiple-response questions |
KCNA’s domain weighting is heavily skewed. Kubernetes Fundamentals is 46% and Container Orchestration is 22%, so those two domains make up 68%. Landing the questions from these two domains solidly on the first pass is the key to clearing the passing line.
The first rule of time management #
Never spend more than 3 minutes on a single question. Once 3 minutes pass, mark the most plausible answer and move on. Since 45 of 60 correct clears the passing score, you can afford to give up on a question or two you do not know. The biggest loss is getting stuck on one hard question and failing to reach the easy last five.
Account for it being an English-only exam #
KCNA is offered in English only. Unlike CLF, there is no Korean toggle, so you can’t route around a tough question by switching languages. That said, the wording is formulaic and the technical terms appear exactly as written in this series, so if you’ve learned the terms in English the reading load isn’t heavy. Just focus on not missing instructions like “Choose TWO” at the end of a question.
Question formats people often trip over #
1) Multiple Response #
A “Choose TWO” or “Choose THREE” label is stated, but it does not look visually much different from single-choice. Always check the last line of the question text.
There is no partial credit, so getting only one of two correct answers right still counts as wrong. If the two correct answers aren’t obvious, finish with the one you’re most certain of plus the most plausible second.
2) Double negatives or negative phrasing #
Forms like “Which of the following is NOT a control plane component?” show up fairly often. If you’ve only memorized “control plane components,” it’s easy to answer backwards when a negative is introduced. When a negative appears, mark the word NOT or EXCEPT and double-check.
3) “BEST” / “MOST appropriate” best-answer #
Phrased as “Which is the most appropriate?” Several options all look correct, but in most cases one is the best fit. Here, grab the keyword the question emphasizes (state retention, zero-downtime rollout, sensitive data, concurrent access, and so on) and narrow the options.
4) Trap keywords in scenarios #
| Trap keyword | The answer it should trigger |
|---|---|
| “stable network ID, ordering guarantees” | StatefulSet |
| “one per node” | DaemonSet |
| “run once and exit” | Job (CronJob if recurring) |
| “store sensitive data” | Secret (not ConfigMap) |
| “zero-downtime rolling update, rollback” | Deployment |
| “route traffic once ready” | readiness probe |
| “restart a hung container” | liveness probe |
| “route multiple Services by host or path” | Ingress |
Pairs of easily confused concepts #
These are the tables that decide questions where two or more of them appear as options together. Memorize just the one-line difference. A large share of KCNA’s multiple-choice questions come straight from these comparisons.
Workload resources #
| Comparison | One-line difference |
|---|---|
| ReplicaSet vs Deployment | Keeps the replica count only vs manages ReplicaSets with rolling updates and rollbacks |
| Deployment vs StatefulSet | Stateless, interchangeable replacement vs stable names, ordering, persistent volumes |
| Job vs CronJob | Run once then exit vs creates Jobs repeatedly on a schedule |
| DaemonSet | One Pod per (all or selected) node (log collection, monitoring agents) |
Configuration and sensitive data #
| Comparison | One-line difference |
|---|---|
| ConfigMap vs Secret | General configuration values vs for sensitive data |
A Secret is by default just Base64-encoded, not encrypted. An option saying “using a Secret encrypts the data” is a trap. Remember that encryption at rest has to be configured separately at the etcd level.
Probes #
| Comparison | One-line difference |
|---|---|
| liveness probe | On failure, restarts the container |
| readiness probe | On failure, removes from Service routing (not a restart) |
| startup probe | Holds off the other probes while a slow-starting app comes up |
Networking #
| Comparison | One-line difference |
|---|---|
| ClusterIP vs NodePort vs LoadBalancer | Cluster-internal only vs exposes a port on each node vs provisions an external load balancer |
| Service vs Ingress | L4 traffic distribution vs L7 host/path-based HTTP routing |
Interfaces (CRI / CNI / CSI) #
| Comparison | One-line difference |
|---|---|
| CRI | Container Runtime Interface. Connects runtimes (containerd, CRI-O) |
| CNI | Container Network Interface. Pod networking plugins |
| CSI | Container Storage Interface. Storage plugins |
Matching the three interfaces to the runtime, network, and storage boundaries respectively is a recurring question.
Scaling #
| Comparison | One-line difference |
|---|---|
| HPA | Increases and decreases the number of Pods (horizontal) |
| VPA | Adjusts a Pod’s CPU/memory requests (vertical) |
| Cluster Autoscaler | Increases and decreases the number of nodes |
Cluster component roles #
| Component | Role |
|---|---|
| kube-apiserver | The entry point for all requests. The front door of the control plane |
| etcd | The key-value store that holds cluster state |
| kube-scheduler | Decides which node a new Pod goes on |
| kube-controller-manager | Runs the controller loops that maintain desired state |
| kubelet | Actually starts and manages Pods on each worker node |
| kube-proxy | Service networking and traffic forwarding on each node |
Observability #
| Comparison | One-line difference |
|---|---|
| metrics vs logs vs traces | Numeric indicators vs event records vs distributed tracing of a request’s path |
| SLI vs SLO vs SLA | A measured metric vs an internal target vs a contract with the customer and its penalties |
Community governance (CNCF project maturity) #
| Stage | Meaning |
|---|---|
| Sandbox | Early experimental-stage projects |
| Incubating | A growth stage where adoption is underway |
| Graduated | Mature and stable stage (Kubernetes, Prometheus, Envoy, etc.) |
Techniques for narrowing the options #
1) Eliminate antipattern options first #
Options that are almost always wrong should be ruled out first.
- “Using a Secret automatically encrypts the data”
- “Connect directly into the Pod and fix the container by hand”
- “Just deploy a stateful database as a plain Deployment”
- “A failing readiness probe restarts the container”
- “SSH directly into the node and start containers without kubectl”
Options like these are almost automatically eliminated.
2) Managed vs self-operated #
Across multiple domains, answers that favor managed and automated approaches that reduce operational burden are often the correct ones. For example, an option that automates autoscaling with HPA tends to be closer to correct than one that adjusts it by hand, and an option that uses GitOps for declarative synchronization tends to beat one that applies deployments manually.
3) Declarative tends to be correct #
Kubernetes’s philosophy is declarative. Options along the lines of “declare the desired state and the system converges to it” are correct more often than imperative options that say “run commands directly in sequence.” This tendency is especially strong in questions about GitOps, Deployments, and controller loops.
Compact per-domain pre-exam checklist #
Domain 1: Kubernetes Fundamentals (46%) #
- control plane: kube-apiserver / etcd / kube-scheduler / kube-controller-manager
- worker node: kubelet / kube-proxy / container runtime
- core resources: Pod / ReplicaSet / Deployment / StatefulSet / DaemonSet / Job / CronJob
- Service types: ClusterIP / NodePort / LoadBalancer, plus Ingress
- ConfigMap vs Secret (Base64-encoded, not encrypted)
- the three probes: liveness / readiness / startup
- the Kubernetes API and the declarative model, Namespace, Label/Selector
- scheduling: taint/toleration, node affinity, requests/limits
Domain 2: Container Orchestration (22%) #
- container runtimes: containerd / CRI-O and CRI
- interface categories: CRI (runtime) / CNI (network) / CSI (storage)
- security: RBAC / NetworkPolicy / security context / ServiceAccount
- storage: PV / PVC / StorageClass
- networking: CNI / Service / cluster DNS
- the role of a Service Mesh (traffic management, observability, security sidecar)
Domain 3: Cloud Native Architecture (16%) #
- autoscaling: HPA (horizontal) / VPA (vertical) / Cluster Autoscaler (nodes)
- serverless: Knative / FaaS concepts
- community and governance: Sandbox / Incubating / Graduated
- open standards: OCI / OpenTelemetry, etc.
- self-healing, rollout, declarative operations concepts
Domain 4: Cloud Native Observability (8%) #
- the three pillars of telemetry: metrics / logs / traces
- Prometheus and metric collection (pull model)
- the difference between SLI / SLO / SLA
- cost management (FinOps) concepts
Domain 5: Cloud Native Application Delivery (8%) #
- GitOps principles (Git as the single source, declarative, automatic synchronization)
- GitOps tools: ArgoCD / Flux
- CI/CD pipeline stages
- why declarative deployment is preferred over imperative
Pre-exam check for online proctoring (PSI) #
KCNA has no in-person test center; it runs only via online proctoring. You take it on your own PC and webcam, with a proctor checking your screen and surroundings in real time. Confirm the following right before you start.
ID #
- Prepare an ID with Latin-script name (passport recommended)
- Confirm that the name in your registration exactly matches the name on your ID
Tidy the testing environment #
- Clear everything off your desk (no notepads, phone, earphones, or watch allowed)
- Use only one monitor if you have a dual-monitor setup
- Block family and roommates from entering; secure a quiet room
- You cannot leave your seat for 90 minutes, so use the bathroom beforehand
System check #
- Enter 30 minutes before the start and close all browser extensions and background apps
- A stable wired network is recommended; verify the webcam and microphone work
- Locate the Flag for Review button and the remaining time display
- Set your pace with the first five questions (too fast or too slow are both bad)
Wrap-up #
What this post nailed down:
- Time management. First pass in 55 minutes (55 sec/question), flag immediately when stuck. Second pass in 25 minutes (flagged questions). Review in 10 minutes. Never cling to a single question for more than 3 minutes
- Formats people trip over. Multiple-response (Choose TWO) counts, negatives (NOT/EXCEPT), best-answer (BEST/MOST), scenario trap keywords
- Easily confused concept pairs. Memorize the one-line difference for Deployment vs StatefulSet, ConfigMap vs Secret (not encrypted), liveness vs readiness, CRI vs CNI vs CSI, HPA vs VPA vs Cluster Autoscaler, and more
- Narrowing the options. Eliminate antipatterns / prefer managed / declarative tends to be correct
- A compact per-domain checklist and a pre-exam check for online proctoring
Next: the mock multiple-choice exam #
We’ve now nailed down the recap too. Now for the real thing.
In #9 Mock Multiple-Choice Exam (All Domains + Explanations), we work through multiple-choice questions across all domains with detailed explanations, matched to the real exam’s domain distribution (46/22/16/8/8%). It’s the final step: solve it like the exam environment, measure your score, and shore up your weak domains one more time.