Exam Day — Proctoring, ID & Environment

Almost nobody fails a Linux Foundation exam because of the thing they were afraid of. They fail because their driving licence had expired, because a second monitor was still plugged in behind them, because check-in started nine minutes before the slot instead of thirty, or because they assumed the Argo CD documentation would be one tab away and it wasn’t. This page is the procedural half of your preparation — the rules that the performance-based CNPE and the knowledge-based CNPA genuinely share, the places where they diverge, and the handful of details that are volatile enough that you must confirm them on the official page before you book. Read it once now, and again the week before you sit.

Two exams, one rulebook — and where it diverges

☺ Like you’re 10: Both tests are taken at home with someone watching. One asks you to do things on real computers; the other asks you to pick answers. The watching part is nearly identical; the screen in front of you is not.

The Linux Foundation runs its whole certification catalogue on a single proctoring and identity process. That is genuinely useful to you: everything about booking, ID, the room, the room scan, check-in, the proctor’s authority and the conduct rules is essentially the same whether you are sitting the professional CNPE or the associate CNPA. What differs is what happens after the proctor releases you into the exam — the interface, the allowed resources, the pacing, and how you are graded.

Keep those two halves separate in your head, because prep advice found online constantly blurs them. “You get the Kubernetes docs” is true for the CNPE and false for the CNPA. “You can flag a question and come back” is true in the multiple-choice sense for the CNPA and true in a completely different sense for the CNPE.

The shared column and the different column

The two CNPA numbers in that table are published, not folklore. The Linux Foundation’s Multiple Choice Exam FAQ states that candidates are allowed 90 minutes for multiple-choice exams with the exception of the CNPA, which is allowed 120 minutes, and that 75% or above must be earned to pass a multiple-choice exam. That exception matters more than it looks: drilling a CNPA paper at 90 minutes trains you at 1.5 minutes per question when the real exam gives you 2.0. Rehearse at 120. (As always, re-read the FAQ before you book — these figures do get revised.)

Booking, the two clocks, and the pre-flight check

☺ Like you’re 10: You buy the exam first and pick the day later — but the “buy” has an expiry date, so don’t forget about it. And test your internet and webcam before the day, not on it.

Registration and scheduling are two separate acts. You buy the exam from the Linux Foundation training portal, which creates an eligibility period; only later do you go into the portal and pick an actual date and time slot. People routinely buy on a promotion, get busy, and discover months later that they have three weeks left to sit an exam they haven’t studied for.

The two clocks — don’t confuse them

Every Linux Foundation certification has two independent timers, and mixing them up is the single most common planning error.

For the CNPA, both figures are published on the official page and this site deliberately does not quote them. Associate-tier exams across the Linux Foundation catalogue have historically followed a similar shape, but a pattern is not a promise. Verify on the official page before you book.

Scheduling the slot itself

Three practical rules, learned the expensive way by other people.

• Pick a time when your household is predictable. A proctor can terminate your exam if another person enters the room — even for a second, even by accident. Two hours of guaranteed solitude is a harder constraint than most candidates plan for.
• Pick a time when your internet is boring. If four people stream in the evening, sit the exam in the morning. See the bandwidth section below for how to actually measure this rather than guess.
• Know the reschedule cut-off. There is a deadline before your slot after which rescheduling is no longer free (or no longer possible), and it is stated in the candidate handbook. Look it up the day you book, not the day you panic.

Run the pre-flight a week early, not an hour early

The portal offers a system-compatibility check. Run it the week before, on the exact machine, in the exact room, on the exact network you will use — and then again the day before. Running it for the first time twenty minutes before your slot is how people discover their webcam driver broke in an OS update.

Alongside the official check, measure your own link. These are ordinary commands on your own laptop; none of them touch the exam.

ping -c 20 1.1.1.1

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

mtr --report --report-cycles 50 1.1.1.1

Raw speed is rarely the problem; stability is. A remote desktop that stutters for four seconds every two minutes will cost you more time than a slow-but-steady link. So sample your connection across a window as long as the exam, at the same time of day you have booked:

# log one latency sample per second for 30 minutes, then count the drops
for i in $(seq 1 1800); do
  printf '%s ' "$(date +%H:%M:%S)"
  ping -c 1 -W 2 1.1.1.1 2>/dev/null | awk -F'time=' '/time=/{print $2; ok=1} END{if(!ok) print "PACKET-LOSS"}'
  sleep 1
done | tee ~/exam-link-check.log

grep -c 'PACKET-LOSS' ~/exam-link-check.log

If that count is anything but zero, fix it before exam day: plug into ethernet, move the router, or change the slot. And on the day itself, take the obvious precautions — close every other application, pause cloud sync and backups, turn off automatic updates, and ask the household to stay off the video calls.

Identity — the check that ends more attempts than any technical fault

☺ Like you’re 10: You need one real ID card, made by a government, with your photo and your signature on it, that hasn’t expired — and the name you signed up with has to be spelled exactly the way it is spelled on the card, in the same letters the card uses. A photo of the card on your phone doesn’t count.

The ID check happens before anything else and it is binary. There is no appeal at the desk, no “I can email you a scan,” no “my colleague can vouch for me.” If the ID does not satisfy the policy, the proctor cannot let you start, and you have burned the attempt. Treat it with the seriousness you would give a boarding pass.

What is accepted

The requirement, as the Linux Foundation states it, has four parts, and all four must hold at once:

• Government-issued. Passport, driving licence, national identity card, residence permit. A student card, an employee badge, a gym membership or a club card is not government-issued.
• Photo and signature. The handbook is explicit that IDs must include the candidate’s name, photo and signature. The proctor compares your face to the card on camera, so an ID with no signature strip is a problem — with one carve-out: government-issued biometric IDs that do not contain a signature are accepted. If your national ID card is biometric and unsigned, you are fine; if your card is an ordinary one that happens to have no signature, take the passport instead.
• Currently valid. Expired is rejected, however recently. Check the expiry date the week you book, and again the night before.
• Name spelled exactly as it appears on the ID — in the ID’s own script. The handbook’s instruction is to enter your name exactly as it is spelled on your ID, and it says so in both directions: if the name on your ID is spelled in your local language, the name in the Identity Verification section must also be spelled in your local language. A Chinese candidate enters Chinese characters, not pinyin; a Japanese candidate enters Kanji, not Rōmaji. No second ID is required, and romanising your profile name to “help” is what manufactures the mismatch that gets you turned away.

What gets rejected

The name-match rule, which trips up more people than anything technical

Your Linux Foundation profile name must match your ID exactly. Not “close enough.” If you registered as Sam Rivera and your passport says Samuel J. Rivera, fix the profile — not on the day, but weeks ahead, because a name change in the portal may need a support ticket and human review. The same applies to a recently changed surname, a middle name your ID includes and your profile omits, and diacritics your keyboard didn’t produce when you signed up.

The half of this rule that gets stated backwards everywhere is the script. Matching “exactly” includes matching the writing system: the handbook tells you that if the name on your ID is spelled in your local language, the name you enter in the Identity Verification section must be spelled in your local language too. So if your national ID reads 王小明, your profile should read 王小明 — not Wang Xiaoming. A Japanese passport in Kanji wants Kanji, not Rōmaji. You do not need to produce a second, Latin-script ID, and you should not romanise the profile in the hope of being helpful; that is precisely how a candidate whose documents were fine arrives at check-in with a name mismatch they created themselves. Source: the Linux Foundation candidate handbook, Candidate Identification and Authentication.

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 tour with the camera so the person watching can see there are no notes hidden anywhere.

The environment rules exist to make cheating hard, and the proctor enforces them literally rather than reasonably. The good news is that they are easy to satisfy if you prepare the room the night before instead of improvising at check-in.

The room

• Private and walled, with a door you can close. Not a café, not a co-working hot desk, not an open-plan office, not a car.
• Nobody else may be present for the whole session. If a family member walks in to ask a question, that is an interruption the proctor must act on.
• Well lit, with your face clearly visible and no strong backlight — a bright window directly behind you turns you into a silhouette and the proctor will ask you to move.
• Quiet. The microphone stays on. Reading questions aloud, muttering to yourself, and background conversation are all things the proctor can query.
• No second person on any screen — close every chat, call and meeting application before you launch.

What may and may not be on the desk

The default is a completely clear desk: your computer, one monitor, keyboard, mouse, and nothing else. Additions are the exception, not the rule.

Two of those deserve emphasis because they surprise experienced engineers. Physical scratch paper is not permitted — the in-exam notepad replaces it, and if your study habit is “sketch the YAML on paper first,” you need to break that habit before exam day, not during it. And headphones are usually prohibited, which means you will be listening to the proctor on your speakers in a quiet room. Verify both against the current handbook; the permitted-items list is exactly the kind of thing that gets revised.

The room scan

Before the exam is released, the proctor asks you to show them the space: a slow 360° pan of the room, the desk surface and underneath it, the walls, the ceiling above you, and often the front and back of your monitor and the area behind it. If you have a laptop this is easy; with a fixed desktop webcam you may need to unclip it or use the phone-based check-in flow the platform offers.

Make it fast by making it boring. Clear the desk the night before, remove anything from the walls in shot, put your phone in another room, and rehearse the pan once so you are not fumbling on camera. A scan that takes ninety seconds is ninety seconds you are not spending flustered.

Check-in — the sequence, the clock, and breaks

☺ Like you’re 10: Start the check-in half an hour early. It is a queue, not a door — and being late can cost you the whole test.

Check-in usually opens a set period before your scheduled start — commonly thirty minutes — and you should use all of it. Nothing in the check-in flow eats into your exam time, so being early is free; being late is not. If you arrive after the lateness tolerance stated in your handbook, you can be marked a no-show and forfeit the attempt.

The sequence, step by step

Concretely, expect this order: launch the exam from the Linux Foundation portal → the proctoring client runs a system and network check and asks for camera, microphone and screen-share permissions → you are placed in a queue for a proctor → identity verification (hold the ID to the camera; often a headshot capture too) → the room and desk scan → the proctor confirms the rules and releases the exam → the timer starts.

The queue is the part people forget. At busy times you may wait, and that wait is on their side of the clock, not yours — which is precisely why starting at T−30 rather than T−5 is the difference between a calm start and a frantic one.

The break policy — plan as if there are none

Two hours is long enough that this matters. The safe planning assumption for both exams is: there are no scheduled breaks, and the clock does not stop. Some Linux Foundation exams permit a short unscheduled break, but where they do, it is on your time, it must be cleared with the proctor first, and you will typically be re-verified — possibly including another room scan — before you can resume. That is several minutes of a 120-minute budget for the CNPE.

So handle it before check-in: use the bathroom, have your drink already on the desk if permitted, and don’t load up on coffee an hour beforehand. And never simply stand up and walk out of frame — leaving the camera without permission is the fastest way to have a session flagged.

The environment — browser, proctoring client, bandwidth and disconnects

☺ Like you’re 10: The test runs inside your web browser, and the watching software runs on your computer next to it. If your internet blips, don’t panic — reconnect and carry on. But the clock probably kept running.

Both exams are delivered in the browser, with the proctoring platform (PSI, at the time of writing) handling identity, streaming and screen share. Two consequences follow. First, the machine must satisfy the published system requirements — a supported operating system and browser, a working webcam and microphone, and permission for the platform to see your whole screen. Second, the machine must be yours to control: a locked-down corporate laptop with restrictive endpoint security, mandatory VPN, or blocked outbound ports is a genuinely common cause of check-in failure. If your only machine is a work machine, run the official system check early enough to arrange an alternative.

What the CNPE environment actually is

For the performance exam, the browser gives you a Linux remote desktop containing a terminal and a browser, connected to one or more live Kubernetes clusters. Tasks are performed on designated SSH hosts rather than on the base desktop, and the usual tooling is pre-installed — kubectl (aliased to k), yq, curl, wget, vim and man pages. Component versions are stated in the official Important Instructions and change over time, so check which Kubernetes version is in force on your exam date and practise against it. The CNPA needs none of that: it is a question-and-answer interface, so its system requirements are lighter.

The bandwidth reality

The published minimum bandwidth is modest — the constraint is not throughput, it is consistency. A remote desktop is an interactive stream: every keystroke is a round trip, so latency and packet loss hurt far more than a low megabit number. Practical advice that costs nothing:

• Use ethernet if you possibly can. Wi-Fi that is perfect for video calls can still produce the micro-stutters that make a remote terminal miserable.
• Kill everything else on the link. Cloud sync, backups, OS updates, game launchers, other people’s streaming.
• Prefer a lower screen resolution if the remote desktop feels sluggish — less pixel data per frame is often the fastest fix available to you mid-exam.
• Have a tethering fallback ready (and know that using it means touching your phone, which you should clear with the proctor first).

What happens if you disconnect

It happens, and it is survivable. The behaviour to plan for is: the exam timer keeps running, your work in the cluster persists (you are graded on cluster state, and the clusters are not on your laptop), and you should reconnect immediately by relaunching from the same portal link. The proctor may need to re-verify you, and may repeat the room scan. If you cannot get back in at all, contact Linux Foundation support straight away and open a ticket describing exactly what happened, with times — a case made during or immediately after the session is taken far more seriously than one made the next day.

The screen in front of you

☺ Like you’re 10: One exam looks like a computer with a black terminal window and a task list. The other looks like a quiz with questions, little flags, and a “check everything before you finish” page.

This is where the two exams stop resembling each other. Rehearse the layout you will actually see, because interface fumbling in the first five minutes is pure waste.

CNPE — terminal, task pane, notepad, Quick Reference

The performance interface is a single browser window divided into panes: the task pane with the current task’s text, the remote desktop with your terminal and browser, a notepad, a task list or navigator letting you jump between tasks and flag them, and — critically — a Quick Reference box.

Three habits, drilled until they are reflex:

• Run the context command first, every single time. Each task begins with a kubectl config use-context … line. Solving task 11 perfectly in task 10’s cluster scores zero, and it is the most-repeated regret in every set of field notes ever written.
• Read the Quick Reference box before you touch the keyboard. It is a permitted resource, it is task-specific, and for anything that is not Kubernetes-core it is frequently the only documentation you will be given.
• Use the notepad as a ledger, not a scratchpad. One line per task: number, cluster context, status, and what remains. Physical paper is not allowed, so this is your memory.

T01 k8s-a  DONE
T02 k8s-a  DONE  (verified: rollout status ok)
T03 gitops ⚑ PART — Application created, selfHeal not set yet
T04 k8s-b  DONE
T05 obs    ⚑ SKIP — ServiceMonitor, came back at 0:20 left
T06 k8s-a  DONE

CNPA — flagging, back-navigation and the review screen

The multiple-choice interface is the familiar one: a question, a set of options, next and previous, a flag for review control, and — before you submit — a review screen listing every question with its answered/unanswered/flagged state. Back-navigation is normally available, which means the correct strategy is different from the CNPE’s:

• Never leave a question blank. Nothing published indicates that Linux Foundation multiple-choice exams deduct marks for a wrong answer — treat that as an assumption to confirm in the candidate handbook rather than a fact you got here — but the advice survives either way: eliminate down to two and take the coin flip, because a blank is a guaranteed zero. Answer, then flag it, then move.
• First pass fast. Answer everything you know in one sweep, flagging as you go. Then work the flags with the time that remains.
• Use the review screen deliberately, with enough time left to actually act on it — five minutes is not enough to revisit twelve flags.
• Beware the re-read trap. Changing an answer on a second look is right when you spotted a misread qualifier (“NOT”, “least”, “first”), and usually wrong when it is just anxiety. Change on evidence, not on nerves.

And remember what does not apply: there is no terminal, no cluster, no notepad full of contexts, and no documentation of any kind. The CNPA is closed-book. Its preparation is retrieval practice — see how to study and the CNPA hub.

Copy and paste — the mechanics that waste people’s time (CNPE only)

Inside the CNPE’s remote desktop, terminal copy/paste uses Ctrl+Shift+C and Ctrl+Shift+V, not the plain Ctrl+C/Ctrl+V you use everywhere else — plain Ctrl+C in a terminal still means “interrupt.” Copying from the task pane into the terminal generally works; copying exam content anywhere outside the exam does not, and attempting it is a conduct issue.

The real trap is pasting YAML into vim, where auto-indent cascades your indentation into an unusable staircase. Two fixes, both worth rehearsing until they are automatic:

# fix 1 — turn off auto-indent before pasting, turn it back on after
# inside vim, in normal mode:
#   :set paste
#   i  … paste …  Esc
#   :set nopaste

# fix 2 — skip the editor entirely with a quoted heredoc
cat <<'EOF' | kubectl apply -f -
apiVersion: v1
kind: Namespace
metadata:
  name: team-a
  labels:
    pod-security.kubernetes.io/enforce: baseline
EOF

While you are at it, spend twenty seconds making the editor behave the way YAML needs. Do this on the host where you will actually be editing:

cat >> ~/.vimrc <<'EOF'
set expandtab
set tabstop=2
set shiftwidth=2
set number
EOF

And the four aliases that pay for themselves within the first three tasks:

alias k=kubectl
export do='--dry-run=client -o yaml'
export now='--force --grace-period=0'
complete -o default -F __start_kubectl k

kubectl config get-contexts

The documentation allowlist — narrower than almost everyone expects (CNPE only — the CNPA is closed-book)

☺ Like you’re 10: During the hands-on exam you are allowed only a few websites — mostly the Kubernetes one. The websites for Argo CD, Crossplane, Prometheus and the rest are blocked, even though the exam asks you about them. During the multiple-choice exam you get no websites at all.

If you take one thing from this page, take this. The CNPE is not a broadly open-book exam. Candidates arrive with a CKA-era assumption — “I can look things up” — and discover at minute twenty that the project doc site they were counting on is not reachable.

The four permitted sources, for the CNPE

The official allowance names three web sources and nothing else: kubernetes.io/docs including its translations, kubernetes.io/blog, and task-specific documentation provided in the Quick Reference box. The Important Instructions add the sentence people skip — the allowed sites above may contain links that point to other external sites, and candidates will be prohibited from accessing these sites. Row 4 below is not a website at all; it is what is already on the exam machine, which is why it survives the allowlist.

What is NOT permitted — the list that costs people the exam

Two mechanics on top of the list itself. Search is allowed; leaving is not. You may use the search box on a permitted site, but you must not open external search-engine results and must not follow an outbound link off a permitted site — the Important Instructions say in as many words that the allowed sites may contain links pointing to other external sites and that candidates are prohibited from accessing those sites, so a kubernetes.io page linking to helm.sh does not make helm.sh permitted. And there is no “extra tab” allowance to spend — this is a myth worth killing, because people plan around it. The official Important Instructions: CNPE puts it flatly: candidates are not allowed to have other applications or browser windows running except the one on which the exam is being shown. There is no number to look up. Plan on working inside the exam’s own window, with the permitted documentation reached from the browser inside the remote desktop, and nothing else open anywhere.

What this means for how you prepare

The allowlist splits your preparation cleanly in two, and the split is the study strategy:

• Kubernetes-native objects — Deployments, Services, Ingress, NetworkPolicy, RBAC, storage, quotas, Pod Security Standards, HPA, scheduling, CRDs, admission webhooks. Here your skill is retrieval speed: find the example on kubernetes.io, change the three fields that matter, apply, verify. Drill this with a browser open and a stopwatch. The Docs Map is that drill.
• Everything else — every CRD shipped by Argo CD, Flux, Tekton, Crossplane, Prometheus, OpenTelemetry, Kyverno, Gatekeeper or Istio. Here your skill is recall, backed by the Quick Reference box and kubectl explain. Drill this with a blank editor and no browser at all. Know It Cold is that drill.

The in-exam fallback deserves its own rehearsal, because it works and most candidates never learned it. Once a CRD is installed in the cluster, its entire schema is in the cluster:

kubectl api-resources | grep -i rollout

kubectl explain rollout.spec.strategy.canary --recursive | head -40

kubectl explain composition.spec --recursive | head -60

kubectl get crd applications.argoproj.io -o jsonpath='{.spec.versions[0].name}{"\n"}'

That is an authoritative, version-correct field list with no browser involved. For non-Kubernetes-core resources it is often the only reference you will have, which makes it the single highest-value command on this page.

The clock — flag-and-move, results, retakes, and the proctor interrupting

☺ Like you’re 10: Don’t get stuck. If something is fighting you, mark it and go to the next one — you don’t need to get everything right to pass. And if the person watching says something, stop and listen; it isn’t a trap.

Time is the CNPE’s real adversary. 15–20 tasks in 120 minutes is roughly six to eight minutes each, and that average is a lie in both directions: some tasks take ninety seconds, and one or two will happily consume twenty minutes if you let them.

The budget, and the discipline that protects it (CNPE only)

The number that changes your behaviour is the pass mark: 64%. You do not need to finish. Plenty of people pass with tasks untouched. That single fact converts the correct strategy from “solve everything” to “harvest every point that is cheap, and never let one expensive task eat the cheap ones behind it.”

The mechanism that makes it work is a ceiling, decided in advance: pick a number — six or seven minutes is typical — and when a task hits it and you are not clearly two edits from done, you flag it and move, mid-thought, without negotiating with yourself. Gizmo will tell you that you are so close. Gizmo does not have to pass this exam.

Two supporting habits. Partial credit is real on performance tasks, so leave a half-solved task in its best partial state rather than reverting it, and record in the notepad exactly what remains. And verify before you move — a fifteen-second kubectl get or rollout status catches the typo that would otherwise silently cost you the whole task.

kubectl -n team-a get deploy,svc,ingress

kubectl -n team-a rollout status deploy/checkout --timeout=30s

kubectl -n argocd get applications.argoproj.io -o wide

kubectl auth can-i list pods --as=system:serviceaccount:team-a:ci -n team-a

On the CNPA the same discipline appears in a gentler form: answer, flag, move; sweep the flags from the review screen; leave nothing blank.

If the proctor interrupts you

It will feel like an accusation. It usually isn’t — proctors query far more things than they escalate, and the overwhelming majority of interruptions are “please move your face back into frame” or “could you re-scan the desk.” What matters is how you respond.

• Stop and read or listen. Interruptions arrive in the chat panel or over audio. Ignoring one, or continuing to type through it, escalates a nothing into a something.
• Comply immediately and without arguing. Move the water bottle, tilt the camera, do the second scan. Debate the policy afterwards through support, never with the proctor mid-exam.
• Ask before you act if you need anything unusual — to stand, to adjust hardware, to touch your phone for tethering. Asking is fine; doing it unannounced is what gets flagged.
• Note the time. If an interruption or a platform fault cost you real minutes, write it in the notepad and raise a support ticket immediately afterwards with times and specifics.
• Then get back to the task. Do not spend the next ten minutes replaying it. The clock did not pause for your feelings.

Results and the retake entitlement (CNPE figures)

For the CNPE, results are emailed within 24 hours of finishing, per the official FAQ — the Important Instructions phrase it as “24 hours from the time that the exam is completed,” so treat it as the expected turnaround rather than a guaranteed maximum. You will get a pass/fail and a domain-level breakdown, not your marked answers or task-by-task grading; performance exams are graded after the fact, so nothing appears on screen when you click finish. Knowledge-based associate exams are often faster to report — check the CNPA page for its own stated turnaround.

The CNPE fee — US$445 at the time of writing, and the Linux Foundation runs frequent promotions and regional pricing, so verify at checkout — includes one free retake. Three things about that entitlement are worth knowing before you need it:

• The retake is one. Beyond that you buy another exam.
• The retake lives inside your eligibility window, not outside it. Failing in month eleven of twelve leaves you very little room.
• There is typically a waiting period before you can re-sit, and the retake terms are stated in the handbook. Check them the day you register, so that a fail is a scheduling decision rather than a shock.

And if you do fail: the domain breakdown in that email is the most honest study plan you will ever be handed. Take it to how to study, rebuild the two weakest domains with the lab track and the practice bank, and book the retake while the environment is still fresh in your hands.

None of this is the hard part — the hard part is the manifests, the docs and the reps. But procedure is the cheapest place on the whole journey to lose an exam, and the only one you can eliminate entirely with an hour of preparation. Work the exam-prep checklist, follow the study plan in how to study, and confirm every volatile number on the official CNPE and CNPA pages before you book.