The three previous lessons covered what each certification includes. This one covers how you pass it. It is the technique lesson, and it is common to the CKA, the CKAD and the CKS, because all three share the same format: a browser-based terminal, a remote proctor watching, about fifteen tasks and a clock that keeps running.

There are people who know Kubernetes inside out and still fail. The causes are almost always the same and none of them is technical: not switching context, typing YAML by hand, getting stuck for fifteen minutes on a four-point task, not verifying what you did, or turning up with a webcam that does not work. All of that can be prevented, and preventing it is precisely what this lesson is for.

Notice. The proctoring environment requirements, the retake policy, the length of validity and the identification procedure change over time. What follows is indicative. Always check the Candidate Handbook and the current conditions on the Linux Foundation / CNCF website before booking your exam.

1. Before the exam: environment, identification and booking a date
2. The first 60 seconds: preparing the terminal
3. Making effective use of the allowed documentation
4. Managing time during the exam
5. The mistakes that cost the most points
6. The habit of verifying every task
7. Mental and physical preparation
8. If something goes wrong during the exam
9. After the exam: result, review, renewal and how to prove it

The exam is taken on your own computer, with a human proctor watching over webcam throughout. The requirements are strict and they are checked before you start. If something fails, the exam does not begin and you may lose the session.

The proctoring provider offers a system check that can be run at any time. It is free and detects camera, microphone, bandwidth and browser-blocking problems.

Do it twice:

1. The day you book the date, so you have room to manoeuvre if something fails.
2. The day before the exam, in the same place, with the same equipment and at the same time of day as your slot (a home network does not behave the same at 09:00 as at 22:00).

Common problems and their fixes:

Book in 30 minutes ahead of the official time. Check-in usually takes 10-15 minutes and the exam clock does not start until the proctor lets you in, but arriving in a rush is the worst possible way to begin.

Typical sequence:

1. You enter the virtual room from your Linux Foundation account.
2. You show your identity document to the camera.
3. You show the room with the webcam: desk, floor under the desk, walls, ceiling.
4. You show your wrists and ears (no smartwatches or earphones allowed).
5. You close every application except the exam browser.
6. The proctor gives you access to the terminal and the clock starts.

Enrolment usually includes one free retake if you fail the first attempt. Check the current conditions: there may be deadlines and limitations.

Why you should book the date before you feel ready:

This is probably the single most useful piece of advice in the whole lesson. The reason is structural, not psychological:

• No date, no plan. Studying without a date drags on indefinitely. With a date, the six-week plan from lesson 12-01 becomes a real calendar.
• The feeling of "being ready" never arrives. The exam is hands-on and there will always be a procedure you have not fully mastered. If you wait for certainty, you never sit it.
• The second attempt exists. The cost of failing the first one is time, not money. And a failed first attempt is the best study session there is: you come out knowing exactly what you are missing.
• The date can be moved. You can usually reschedule with enough notice (check the exact deadline, it is normally around 24 hours). Booking is not an irreversible commitment.

Recommended strategy: book the date six to eight weeks out on the day you start studying seriously. And if halfway through you see you are not going to make it, you move it.

Time of day: pick a slot when you are awake and the house is quiet. Two hours of continuous concentration with no breaks is not trivial. Avoid straight after lunch.

The moment you see the terminal, before reading the first task, type this block. It is about 40 seconds that gives you back between 15 and 25 minutes over the course of the exam.

What each line does:

Important note: in the CKA and the CKS you may end up working on several nodes over ssh. The alias does not travel with the ssh session. When you get onto a node, either repeat the block or simply type kubectl in full. Bear in mind that $do does not exist there either.

If that comes out right, the arsenal is ready.

A second block, just as profitable. Type it before you open the first YAML:

Quick alternative with no file: if you would rather not create ~/.vimrc, inside vim you can type:

But doing it once in ~/.vimrc is safer than remembering it for every file.

Practise this the week before the exam. Exam day is not the moment to remember how to delete five lines.

Two valid strategies. Pick one and be consistent:

A saves time but requires changing it at the start of every new task. B is impossible to forget but costs seconds. Many candidates use A and, in the final review, check every object with an explicit -n.

The exam interface includes a notepad. Use it from minute one to keep your task list:

Without this list, at minute 100 you will not remember what you left pending or which one was worth more.

Forbidden in all of them: general search engines, forums, GitHub, your own notes, other websites, AI tools, any local file that does not belong to the cluster. Only one additional tab is allowed besides the exam one.

Verify the exact list of allowed domains in the official handbook: it has changed between programme revisions.

The site's own search is slow and often returns unhelpful results. Two better techniques:

Technique 1 — direct URL. Many pages have predictable paths:

Technique 2 — Ctrl+F inside the page. Once you are on the right page, search for the field name you need (fsGroup, startingDeadlineSeconds, emptyDir) instead of reading the whole thing.

This is your mental cheat sheet. Memorise the search term, not the URL.

Compare the two routes for a NetworkPolicy:

Route A — typing it by hand:

Route B — copying and adapting:

Three times faster and a fraction of the risk. And the grader cannot tell whether you typed it or copied it: it only looks at the state of the cluster.

The objects that benefit most from this approach (the ones with no imperative generator):

• PersistentVolume and PersistentVolumeClaim
• NetworkPolicy
• StorageClass
• A full securityContext
• Probes with all their fields
• Audit policy
• EncryptionConfiguration
• RuntimeClass
• seccomp profiles

For one-off doubts about a field, this is quicker than going to the browser:

And to recall the correct API version:

k api-resources answers "what was the apiVersion for this again?" in two seconds.

Spend the first 4-5 minutes reading ALL the tasks without solving any of them. It feels counter-intuitive, but it is the most profitable investment in the exam.

As you read, note down in the notepad, for each task:

A typical result:

Now you have a map. Without it, you are flying blind.

Phase 1 (minutes 5-40): the cheap ones. All the Es, in the order they appear. They are quick, guaranteed points and they get you into rhythm. Psychologically, starting by stacking up wins changes the whole exam.

Phase 2 (minutes 40-95): the central block. The Ms and the Hs, prioritised by weight. This is where the pass is decided. The heaviest ones go in this block because you need time and a fresh head, but not so late that the clock catches you.

Phase 3 (minutes 95-110): the outstanding ones. You go back to the skipped and half-finished ones. With what you learned on the other tasks, the solution is often obvious by now.

Phase 4 (minutes 110-120): review. Not a single new task. Checking only.

Hard rule: if a task overruns its target time by more than 50 %, you flag it and leave it.

Why this works: a 4 % task you have spent 12 minutes on has cost you the equivalent of two 5 % tasks you would have solved. The arithmetic is merciless: the exam does not reward perseverance, it rewards output per minute.

How to skip well:

1. Leave in place whatever you managed to do (partial marks).
2. Note it in the notepad with a remark about where you got stuck.
3. Move to the next one without dwelling on it.

Coming back later with a clear head solves half of the blockages.

Starting a new task is forbidden. That time is for:

Concrete review checks:

Finding a single object in the wrong namespace during this review already pays for the ten minutes.

In order of damage caused.

Mistake number one, and the most expensive: zero marks on a perfectly solved task.

Every task starts with its context command. Copy it and run it always, even if you believe it is the same as the previous task's.

Habit to train: the use-context is the first command, before you have even finished reading the statement. Make it automatic.

The second most expensive mistake, for the same reason: the object is created in default and the grader cannot find it.

Or -n on every command. But one of the two, always.

Special case: cluster-scoped objects (PersistentVolume, StorageClass, ClusterRole, ClusterRoleBinding, Namespace, RuntimeClass, PriorityClass, IngressClass) take no namespace. Giving them one does not raise an error, it is simply ignored, but knowing which ones they are avoids confusion.

A typical situation: you create the Deployment, get distracted by the Service, and the Deployment is left with the wrong image. Or you apply a YAML with an error and do not look at the result.

If it had said error validating data: ValidationError..., the task is not done. Read the output of every command.

An object existing does not mean it works. The cases that cost the most points:

The rule: one check per task, always.

This is already covered in section 3.4, but it bears repeating because it is the mistake that most quietly ruins exams. You do not fail because of it directly: you fail because you had three tasks left undone.

The speed hierarchy, fastest to slowest:

Every task must follow this sequence, without exception:

Step 3 is not optional. It costs 5-10 seconds and catches half your mistakes before it is too late.

Beyond verifying for yourself, some tasks explicitly ask you to save a result into a file. Those are direct marks and they get missed through carelessness:

Classic mistake: the command fails, the redirection creates an empty file, and you never look at it. A one-second cat prevents it.

Do not study new content in the last 48 hours. It does not stick and it raises anxiety. What you already know is what you take in with you.

Mock exams only help if they are realistic:

• Two straight hours, no breaks, no phone, no getting up.
• Only the allowed documentation open. No googling "how did this go again".
• In the same place, with the same equipment you will use on exam day.
• Marked at the end, not as you go.

Lesson 12-05 of this course is exactly that: a complete mock exam with fifteen timed tasks and its solutions.

What to measure in each mock exam:

Details that look minor and are not:

• The same keyboard. If you practise on one keyboard and sit the exam on another, you lose speed and make typos.
• The same keyboard layout (Spanish, English). The characters |, \, {, }, " and - appear constantly in YAML and commands.
• The same browser and the same resolution.
• Practise copy and paste in a web terminal. The shortcuts (Ctrl+Shift+C/Ctrl+Shift+V) differ from those of a native terminal, and exam day is not the moment to find that out.
• Practise with a split screen: terminal on the left, documentation on the right. That is how you will be working.

• The first few minutes are the worst. That is normal. The initial reading pass helps precisely here: it gives you control before you start typing.
• If a task blocks you, skip it. It is not a failure, it is the correct strategy.
• Do not calculate your score in your head during the exam. It distracts you and it is almost always pessimistic.
• Breathe before touching anything critical. Above all before editing the apiserver in the CKS.
• Accept imperfection. With a threshold around 66 %, you can get a third of the exam wrong and still pass.

Important: if something fails because of the platform, tell the proctor at that moment, not at the end. Get it on record. Complaining after you have finished, with no record from during the session, has little chance.

Throughout the exam there is a chat in the interface. That is the official channel.

Write in English and be specific: task number and symptom. The proctor cannot give you hints about the content, but they can solve platform problems.

You can also use the chat to:

• Ask permission to drink water (subject to the rules).
• Report an unavoidable noise in your environment.
• Report any external interruption.

Never: ask anything about the content of the tasks. The answer will be no and it eats your time.

Breaches that can invalidate the exam and that people commit with no bad intent:

• Speaking out loud or muttering the statements as you read them. The microphone picks it up.
• Looking away from the screen repeatedly.
• Getting up without permission.
• Someone walking into the room.
• Having your phone in sight, even switched off.
• Wearing earphones or a smartwatch.
• Taking notes on paper.

Warn whoever lives with you, close the door and leave the phone in another room.

• The result arrives by email, usually within 24 hours (indicative; check the current turnaround).
• You get the overall score and, if you fail, a breakdown by domain with your performance in each one.
• If you pass, you receive the PDF certificate and a verifiable digital badge.

It is not a disaster and it is more common than it looks. Enrolment usually includes one free retake.

Action plan:

1. Write down what you remember the same day. Which kinds of task appeared, which ones blocked you, where you lost time. That information evaporates within 48 hours and it is pure gold.
2. Read the breakdown by domain. It tells you exactly where you fell short.
3. Diagnose the real cause, which is almost always one of these three:

4. Book the second attempt 3-4 weeks out. Not sooner (no time to fix things) and not much later (you lose your form).
5. Work only on what failed. Do not redo the whole syllabus.

Calendar tip: note the expiry date the same day you pass, with a reminder four months beforehand. That gives you room to prepare the renewal without pressure.

And bear in mind that renewal is not just bureaucracy: Kubernetes changes fast, and the exam curriculum is updated with each version. Renewing is a way of staying current.

Practical tip: always include the verification link. It separates a real certification from a claim, and technical recruiters appreciate it.

Passing is not the end of the road:

• Apply it. A certification without practice rusts within months. Keep operating clusters.
• Chain them. If you hold the CKAD, the CKA is one step away. If you hold the CKA, the CKS is the natural specialisation.
• Extend into the ecosystem. The CNCF offers other certifications (Prometheus, Istio, Argo, GitOps, and introductory ones such as KCNA and KCSA). Revisit module 10 to see where each tool fits.
• Keep a cluster of your own. A kind or minikube on your laptop is enough to keep your reflexes sharp.

1. Book the date before you feel ready. No date, no plan.
2. The first 60 seconds are worth 20 minutes: aliases, $do, completion, .vimrc.
3. Read every task before solving any of them. Five minutes that organise the two hours.
4. Copying from the documentation is the correct strategy, not a shameful shortcut.
5. The cycle is context → solve → verify. All three steps, always.
6. Skipping is a strategic decision, not a surrender.
7. The last 10 minutes are for reviewing, never for a new task.
8. Simulate the whole exam at least twice before the real day.
9. If you fail, write down what you remember the same day and use the retake in 3-4 weeks.
10. Note the expiry date the day you pass.

In a clean terminal (container, VM or new session), and with a timer:

1. Type from memory the complete block of aliases, variables and completion.
2. Create the ~/.vimrc with the seven settings.
3. Prove that it works: generate a pod's YAML with $do, open it in vim, paste in a securityContext block copied from the documentation, save it and apply it.

Target: under 3 minutes in total, with no reference material.

Repeat it five days running until it comes out without thinking.

You are given this task list from an imaginary exam. Without solving them, draw up your plan of attack: order, time allocated to each one and which phase you would tackle it in.

Build your own "I need X → I search for Y on kubernetes.io" table, with at least 20 entries, ordered by the frequency you expect in your exam (CKA, CKAD or CKS).

Then verify every entry: open kubernetes.io, search for the term you wrote down and check that the first or second result is the page you need. Fix any terms that do not work.

Solution to Exercise 1

Inside vim, pasting the block copied from the documentation:

Self-assessment: if it took you more than 3 minutes, work out where. The usual culprits are hesitating on the complete -o default line or wrestling with vim. Both are fixed by repetition.

The trap in this exercise: if the YAML comes out as a staircase when you paste it into vim, set paste was not active. Check it with :set paste? inside vim.

Solution to Exercise 2

Total: 100 %, 15 tasks, 120 minutes.

Classification by typical difficulty and target time:

Time allocation:

Analysis of the plan:

• Phase 1 secures 23 points in 22 minutes, a little over a point a minute. It is the best return in the exam and that is why it goes first.
• The four heaviest tasks (2, 5, 9, 14) add up to 35 points and about 44 minutes. They are the deciding ones. They go in the central block, not at the end.
• With 23 (phase 1) + 35 (the four big ones) = 58 points, you still do not pass. You also need the medium ones: 7, 12, 15, 11 and 4 add another 32 points. That is your real margin.
• If tasks 5 (etcd) and 14 (upgrade) get stuck, the hard 15-minute limit stops the two of them eating 40 minutes.

The mistake this exercise prevents: starting at task 1 and carrying on in order. You would reach task 5 (10 %) around minute 30 with a fresh head —that part is fine— but task 9 (9 %) and task 14 (8 %) would fall at the end, rushed and tired. And the easy ones at the end (10, 13) might go undone, giving away 7 points that cost 7 minutes.

Solution to Exercise 3

An extract from a CKA cheat sheet, ordered by expected frequency:

The value of the exercise is in the verification step. Terms that look obvious often do not lead to the right page: searching for "backup etcd" gives scattered results, whereas "operating etcd clusters" goes straight there. Discovering that now is worth minutes on exam day.

Extra tip: for the CKS, add a second table with falco.org/docs (rule syntax, the list of %evt.* and %container.* fields) and aquasecurity.github.io/trivy (severity flags and output formats).

Technical knowledge is a necessary condition for passing the CKA, the CKAD or the CKS, but not a sufficient one. The exam format —hands-on, timed, with several clusters and remote proctoring— adds a layer of difficulty that is prepared for separately, and that is exactly what you have worked on in this lesson.

What to take away:

• Before: run the system check twice, prepare the room and the identity document, and book the date before you feel ready —no date, no plan, and the retake exists.
• The first 60 seconds: the k alias, $do, $now, completion and ~/.vimrc with set paste. Forty seconds that give you back twenty minutes.
• The allowed documentation is a tool, not a crutch: copying an example and adapting it is three times faster and far safer than writing a manifest from scratch.
• Time is managed in four phases: read everything, solve the cheap ones, attack the central block by weight, and review. With a hard limit per task and no regrets about skipping.
• The costliest mistakes are not technical: not switching context, not setting the namespace, leaving objects half-done, not checking that they work, and typing YAML by hand.
• The cycle for every task is always the same: context → solve → verify. All three steps, without exception.
• Prepare physically and mentally too: realistic mock exams, an identical environment, rest, and no new topics in the last 48 hours.
• If something goes wrong, tell the proctor at the time, through the chat and in English.
• Afterwards: read the domain breakdown if you fail, diagnose whether the problem was knowledge, speed or process, and note the expiry date the same day you pass.
• Always check the Candidate Handbook and the current conditions before booking: requirements, deadlines and policies change.

Only one thing remains: putting it all to the test. The next and final lesson of the course is the final mock exam: fifteen timed tasks on the Rutas Norte platform, with their scoring, a complete solution set and a self-assessment table that will tell you whether you are ready to book the date or which modules are worth revising first. Get the timer and a clean cluster ready.