github.com/rbstp/heed

brew install --cask rbstp/tap/heed

That is the whole setup. Grant Accessibility when macOS asks and it runs as a login agent, no Dock icon and no window of its own. A menu bar cube switches it off, ⌃⌘H does the same from the keyboard. macOS 14 or newer, Apple Silicon, MIT.

Knowing when to leave you alone is the whole job

Following the pointer is the easy part. Almost all of the work went into the moments where focus must not move, because getting those wrong makes the idea unusable rather than merely annoying.

Type a sentence and let the mouse drift over another window. The rest of the sentence stays where you started it. Focus also holds still while a mouse button is down, while a menu or a drag image is on screen, while you are in a password field, and while ⌘ is held for Cmd-Tab. Open a new window and it keeps focus until you actually come to rest somewhere else, so you can walk over to it across two displays without losing it to everything you cross on the way.

It stops sampling when the pointer stops, which is what keeps it off your battery.

This is the other half.

cnpe.rbstp.dev

Twenty-nine sections across the five exam domains, one evening each, covering every competency in the official curriculum PDF. Concepts, exercises against the lab, then a self-check. It is a static site with no build step, so curriculum/index.html opens straight out of the clone and make study does it for you. Thirteen of the figures are interactive, because dragging a pod's memory request until the QoS class flips beats reading about eviction order.

Every exercise ends in a command

The lab's rule carries over. Never trust "the pod is Running", make it do something. All 123 exercises finish with a command whose output proves the thing worked.

Seventy-one of those command blocks carry a collapsed drawer holding the real output. I ran every one against a freshly built lab on 26 August 2026 and captured what it printed, the failures included. Predict the output first, then open the drawer. Chart versions float on purpose, so yours will drift from mine, and working out why is the exercise.

Two hours is the whole design constraint

The exam is 120 minutes of performance-based tasks on a remote desktop. 15 to 20 tasks in two hours is 6 to 8 minutes each, and everything here falls out of that number. make break runs a 7-minute clock. Both mock exams carry a 120-minute clock and a grading block you run with make grade, fifteen tasks each, no task shape shared between the papers. The first exam-day tactic on the dashboard is to flag and move on, because a stuck task costs you two easy ones.

Documentation is tighter than people expect. The instructions allow kubernetes.io/docs plus the task-specific links in each question's Quick Reference panel, and prohibit the rest. Tool documentation reaches you only through those links. So kubectl explain --recursive, kubectl api-resources | grep <tool> and --help are your real references, and every section leans on them rather than on a URL you will not be able to open.

Domain weights are not study time. Domains 2 and 3 are half the exam and mostly mechanical skills that improve with reps. Domain 1 and half of domain 5 are things you already know if you run Kubernetes for a living. Check yourself against the exercises before spending evenings there.

The drill

The 148 self-check questions double as flashcards on an expanding review interval, scaled by how often you miss the card. First review a day later, then four days, then multiply. Miss one and it comes back immediately, a rung lower. Nothing rests longer than 21 days, because the exam is weeks away and not years. A weak-spots panel splits lifetime accuracy by domain and wants five answers in a domain before calling it weak, since one bad card is noise.

Using it

git clone https://github.com/rbstp/cnpe-exam-prep.git && cd cnpe-exam-prep
make study          # opens curriculum/index.html, no server, no build
make grade EXAM=1   # runs mock exam 1's grading block against your lab

Or read it at cnpe.rbstp.dev. There is a single-file build at cnpe.rbstp.dev/console.html too, all 33 pages and the fonts inlined into one 1.1 MB document that works offline. Progress lives in local storage, Export and Import move it as JSON, and signing in with GitHub is optional, off by default and identity only. The OAuth scope is empty, so the token opens nothing.

github.com/rbstp/cnpe-exam-prep

A full internal developer platform on kind, as layered make targets you install and remove one at a time. Cilium, Gitea, Argo CD, Flux, Argo Rollouts, Tekton, Crossplane, CloudNativePG, Prometheus, Grafana, OpenTelemetry, Jaeger, Loki, OpenCost, Kyverno, Gatekeeper, SPIRE, Istio ambient, and Backstage.

Checking behaviour instead of pod status

make validate runs 69 checks, and none of them ask whether a pod is Running. It does not ask "is Crossplane installed". It applies an XR and asserts a real namespace appeared with the quota values patched from its spec. It does not ask "is Cilium up". It runs a pod that has to fail to reach the internet, and the check fails if that egress works.

That distinction is the whole point. kindnet does not enforce NetworkPolicy, so on most kind-based labs every network-policy exercise silently passes and you learn nothing at all. Use Cilium, then prove enforcement.

Four things that cost me real time

The audit policy filename stops the cluster from booting. kube-apiserver is started with --audit-policy-file=/etc/kubernetes/audit/policy.yaml, so the mounted directory has to contain a file called exactly that. Get it wrong and the API server refuses to start. It looks like a cluster that never boots, not a config error.

You cannot break DNS by adding a NetworkPolicy. They are additive allow-lists, so a new restrictive policy cannot revoke an allowance another policy already granted. My fault-injection drill "blocked DNS" by adding one, and it never blocked anything. To actually break resolution you have to remove the rule that permitted it.

An ipBlock on the API server ClusterIP does not work. CloudNativePG hangs forever in a default-deny namespace because its instance manager cannot reach the API server. The obvious fix, allowing egress to 10.96.0.1/32:443, still fails. The ClusterIP is DNAT'd to a node's :6443 before policy evaluation. With Cilium you want toEntities: [kube-apiserver].

Gateway API v1.5 and later blocks older Gateway API CRDs. It ships a policy that rejects any CRD before v1.5.0, and cloud-provider-kind embeds an older bundle it installs at startup. It gets denied, its service controller dies, and no LoadBalancer ever gets an IP. Start it with --gateway-channel=disabled.

Running it

Tested on a 2019 Intel MacBook Pro, i9-9880H with 32 GB, running Arch. Roughly 70 minutes for everything, about 25 for a useful subset. At rest it is two clusters, around 100 pods and 21 GB of RAM. CPU is the bottleneck, never memory.

git clone https://github.com/rbstp/cnpe-exam-prep.git && cd cnpe-exam-prep
cp lab.env.example lab.env
make host tools core
make validate

The part I will use to study with is make break. It injects one of seven realistic faults into a tenant namespace and starts a seven minute clock, which is about exam pace. make break-fix diagnoses it from cluster state and tells you where the evidence was. Incident response is a third of the observability domain and the hardest thing to practise alone.

MIT licensed. I am still working through the material, so the repo will keep moving.

Gene Kim and Steve Yegge’s audiobook on vibe coding has excellent narration, but I’d recommend checking out their YouTube channel instead. Most of the book’s examples were already covered in their promotional videos, and the high-level approach makes you wonder how long the advice will stay relevant in this fast-moving space.

The core framework they present, the Three Developer Loops, is genuinely useful though:

Inner Loop (Seconds to Minutes)

This is where AI shines brightest. Get AI to write specifications and tests, use it as your “Git maestro” for quick iterations. The speed here is incredible.

Middle Loop (Hours to Days)

Focus on getting code into users’ hands quickly, working with AI on real issues, and maintaining that human collaboration element. It’s about keeping your development cycle tight while staying grounded in actual user needs.

Outer Loop (Weeks to Months)

The bigger picture stuff: preventing “kitchen fires” through stress tests and automation, detecting issues with proper CI/CD pipelines, and correcting problems systematically. This is where the Prevent-Detect-Correct cycle really matters.

Other Notes

Parts 3 and 4 had some solid insights, but nothing groundbreaking if you’re already working with AI tools. The kitchen analogy gets overused pretty quickly, which doesn’t help.

If you’re new to AI-assisted development, the YouTube series gives you the essentials without the time commitment. If you’re already familiar with these concepts, you won’t find much new here beyond the well-produced audio experience.