Exam Day — Proctoring & Environment

Every credential on this ladder — KCNA, KCSA, CKA, CKAD, and CKS — is delivered the same way: from your own machine, wherever you can find a door that closes, watched live by a remote proctor through your webcam and microphone. That one fact means the two most common ways to lose an attempt have nothing to do with Kubernetes at all: an ID that doesn't quite match your registration, a second monitor still plugged in behind the desk, a system check run for the first time twenty minutes before the slot instead of a week before it. This page is the logistics half of your preparation — the system check, the ID rule, the room and desk scan, the check-in queue, and exactly how the environment behaves once you're in, because a multiple-choice screen (KCNA, KCSA) and a live terminal against a real cluster (CKA, CKAD, CKS) are proctored almost identically and then hand you completely different rooms. Read it once now, and again the week before you sit.

One proctoring script, two exam bodies

☺ Like you're 10: The security check before the clock starts is nearly the same for all five exams. What happens after the proctor lets you in is not.

The Linux Foundation runs its whole Kubernetes certification catalogue through a single identity-and-proctoring pipeline — currently PSI, at the time of writing. That is genuinely useful to you: booking, the ID rule, the room, the desk, check-in, and the proctor's authority over conduct are essentially identical whether you're sitting the associate-tier KCNA, the security-flavored KCSA, or the hands-on CKA, CKAD, and CKS. What differs is everything that happens after the proctor releases the exam: the interface, the permitted resources, and how the result is graded.

The week before: the system check, your ID, and the eligibility clock

☺ Like you're 10: Test your camera, microphone, and internet a week early, not on the day. And double-check your ID matches your account, letter for letter.

The Linux Foundation portal offers a system-compatibility check before you ever book a slot. Run it the week before, on the exact machine, in the exact room, on the exact network you intend to use — then run it again the night before. Running it for the first time twenty minutes before your slot is how people discover their webcam driver broke in an OS update, or that a locked-down work laptop's endpoint security blocks the proctoring client outright.

Raw bandwidth is rarely the problem; stability is. A remote desktop is an interactive stream — every keystroke is a round trip — so a connection that stutters for a few seconds every couple of minutes will cost you more than a slow-but-steady one. These commands touch nothing exam-related; they just tell you what your own link actually does at the time of day you've booked:

# run this about a week out, then again the night before, at your actual exam time
ping -c 30 8.8.8.8

curl -o /dev/null -s -w 'dns=%{time_namelookup}s connect=%{time_connect}s tls=%{time_appconnect}s total=%{time_total}s\n' https://kubernetes.io/docs/

# sample stability across a window as long as the exam itself, not a few seconds
for i in $(seq 1 900); do
  date +%H:%M:%S
  ping -c 1 -W 2 8.8.8.8 2>/dev/null | grep -o 'time=[0-9.]*' || echo DROPPED
  sleep 2
done | tee ~/k8s-exam-link-check.log

grep -c DROPPED ~/k8s-exam-link-check.log

If that drop count isn't zero, fix it before exam day: plug into ethernet, move closer to the router, or move the slot to a quieter hour. On the day itself, close every other application, pause cloud sync and OS updates, and ask your household to stay off video calls for the window.

The identity rule is the same across the whole Linux Foundation catalogue, and it's binary — there is no appeal at check-in. Your ID must be government-issued (a student card or employee badge doesn't count), must carry a photo and a signature (with one carve-out: government-issued biometric IDs without a signature are accepted), must be currently valid, and the name on your Linux Foundation profile must match it exactly — in the ID's own script. If your passport reads in Kanji or Chinese characters, your profile entry needs to as well; romanising it to "help" is exactly what manufactures the mismatch that turns candidates away who otherwise had everything in order. Full detail lives in the Linux Foundation's own Candidate Identification and Authentication policy.

Separately, keep two clocks straight: an eligibility window that starts the moment you purchase the exam (how long you have to schedule and sit it, including any retake) and a certification validity period that starts the day you pass. Both figures are published on each exam's own page and both have been revised more than once across the CNCF programme — confirm them at checkout rather than trusting a number from any third-party site, this one included.

The room, the desk, and the room scan

☺ Like you're 10: An empty table, a room with a door you can close, nobody else inside, and a slow camera tour so the proctor can see nothing is hidden.

The environment rules exist to make cheating hard, and the proctor enforces them literally rather than reasonably — the good news is that they're easy to satisfy if you prepare the room the night before instead of improvising at check-in. Your room needs to be private, with a door you can close — not a café, not an open-plan office, not a car — and nobody else may enter for the whole session, even briefly. It needs to be well lit with your face clearly visible (a bright window directly behind you turns you into a silhouette, and you'll be asked to move), and quiet, because the microphone stays live the entire time.

That last row surprises even experienced engineers: physical scratch paper is not permitted. If your study habit is to sketch a manifest on paper before typing it, break that habit before exam day — for CKA, CKAD, and CKS the in-exam notepad is your only scratch space, and there is no equivalent at all for KCNA or KCSA.

Before the exam is released, the proctor asks for a slow 360° pan of the room: the desk surface and underneath it, the walls, the ceiling, and often the front and back of your monitor. Make it fast by making it boring — clear the desk the night before, take anything readable off the walls, put your phone in another room, and rehearse the pan once so you aren't fumbling live on camera.

Check-in, the queue, and the timeline

☺ Like you're 10: Start check-in about thirty minutes early. It's a queue, not a door — and none of that time counts against your exam clock, so being early is completely free.

Check-in typically opens thirty minutes before your scheduled start, and you should use all of it: launch from the portal → the proctoring client runs a system and network check and asks for camera, microphone, and screen-share permissions → you're placed in a queue for a proctor → identity verification → the room and desk scan → the proctor confirms the rules and releases the exam → the timer starts. The queue is the part people forget about — at busy times you may wait, and that wait is on the proctor's side of the clock, not yours, which is precisely why starting at T-minus-30 rather than T-minus-5 is the difference between a calm start and a frantic one.

Plan for no scheduled breaks, and assume the clock never stops. Some exams permit a short unscheduled break, but where they do it's on your time, must be cleared with the proctor first, and typically triggers re-verification — sometimes another room scan. Handle the practicalities before check-in: use the bathroom, have your permitted drink already on the desk, and don't load up on coffee an hour beforehand.

Once you're in: how the two screens differ

☺ Like you're 10: One screen looks like a quiz with buttons for next, previous, and flag. The other looks like a real computer with a black terminal window and a list of jobs to do.

This is where the two formats stop resembling each other at all. Rehearse the layout you'll actually see, because fumbling the interface in the first five minutes is pure waste either way.

For KCNA and KCSA, that's the entire interface: a question, four options, previous/next, a flag control, and a review screen listing every question's answered/unanswered/flagged state before you submit. There is no terminal, no cluster, and — worth repeating — no documentation of any kind. Never leave a question blank; nothing published indicates a penalty for a wrong answer, so an educated guess always beats a guaranteed zero.

For CKA, CKAD, and CKS, the browser gives you a Linux remote desktop containing a terminal and a browser, connected to one or more live clusters, plus a task pane, an on-screen notepad, and a task navigator for jumping around and flagging items. Two habits are worth drilling until they're reflex. First, run the context-switch command printed with every task before you touch anything else — solving a task perfectly against the wrong cluster scores zero, and it's the single most repeated regret in candidate write-ups. Second, verify before you move on: a fifteen-second kubectl get or rollout status catches the typo that would otherwise silently cost you the whole task.

Inside that remote desktop, clipboard shortcuts are Ctrl+Shift+C and Ctrl+Shift+V rather than the plain Ctrl+C/Ctrl+V your terminal already claims for something else — and pasted YAML will stagger under vim's auto-indent unless you turn it off first or skip the editor with a quoted heredoc. That mechanic is identical to the CNPE, because both run on the same remote-desktop product; Platform Engineering's exam-day page walks the exact keystrokes and a working .vimrc if you want the full drill.

The documentation allowlist is narrower than most candidates expect, and it differs by exam rather than being one fixed list. kubernetes.io/docs, including its translations, is permitted for all three performance exams — CKA and CKAD additionally permit helm.sh/docs, and CKS additionally permits the security-tooling docs its own curriculum names (Falco, etcd, Cilium, and Istio, at the time of writing). Search on a permitted site is fine; following a link off it is not, and there is no "extra tab" allowance to spend regardless of exam. Confirm the exact row for your exam on the official Resources Allowed page before you sit — this list is exactly the kind of thing that gets revised.

When it misbehaves

☺ Like you're 10: If your internet blips or the person watching says something, don't panic — stop, listen, and reconnect. Your progress usually isn't the thing at risk. Your time is.

It happens, and for all five exams it's survivable if you know what to expect instead of guessing under pressure.

What's true today — and what only the official page can tell you

☺ Like you're 10: The numbers below are generally accurate right now, but this site isn't the Linux Foundation — always check the real page before you pay for anything.

This course is an independent, unofficial study resource and is not affiliated with the CNCF or the Linux Foundation. Format and rough duration are stable enough to plan around; price, exact task or question counts, and retake terms move more often and are deliberately not repeated here as fixed numbers.

One free retake has historically been bundled with each of these exams, and pass/fail results are typically emailed within a day or so of finishing — performance exams (CKA/CKAD/CKS) are graded after the fact against the cluster's end state, so nothing appears on screen the moment you click finish. None of that is a promise from this page.

None of this is the hard part — the hard part is the actual Kubernetes, and this page is the cheapest hour you'll spend on the whole journey to protect it. Work through the exam-prep checklist, follow the study method in how to study for a CNCF exam, drill recall with flashcards and the self-check quiz, and confirm every volatile number on the exam's own official page before you book.