The certification ceiling: why passing the CKA won't make you a Kubernetes engineer
Certifications open doors. They don't fix clusters at 3am. The gap between the exam and production is wider than most candidates realise, and the industry is quietly hiring around it.
A LinkedIn message lands every week. Someone has passed their CKA, sometimes their CKS, and they want to know if we are hiring. The certification badge is there, the study hours are real, and the motivation is genuine. I respect it. But the message almost always reveals the same assumption: that the certificate is the qualification.
It is not. It was never meant to be.
What the CKA actually tests
The Certified Kubernetes Administrator exam is a well-designed, hands-on test. You are given a cluster, a set of tasks, and two hours. You need to configure networking, fix a broken pod, set up RBAC, configure a storage class, troubleshoot a node that has gone NotReady. The tasks are real. The environment is a live cluster. You cannot fake your way through it.
But the exam is also a closed world. The cluster is small. The failure mode is known. The task is scoped. You are working inside a sandbox where someone has already decided what the problem is, and your job is to find the solution they have in mind.
Production is not that.
The gap nobody talks about
In the exam, a pod is CrashLoopBackOff because the command is wrong. You fix it, the pod runs, you move on. In production, a pod is CrashLoopBackOff because the secrets were rotated by a pipeline that ran in the wrong order, the application cannot handle the new token format, the liveness probe is too aggressive, the node is under memory pressure, and the alert fired seventeen minutes ago but nobody saw it because the alerting rule was misconfigured during the last Helm upgrade.
The exam tests whether you can find the problem. Production tests whether you can find the right problem, among six problems, while three people are asking you for status updates, and the rollback is failing because the image tag was overwritten.
That gap, between scoped troubleshooting and live incident response, is where certifications stop being useful.
What we actually hire for
When I review infrastructure for clients, the first thing I look at is not what tools they use. It is how they handle failure. The same is true when I think about engineers.
The engineers I trust in production are the ones who:
- Can read a situation before touching it. They look at events, logs, metrics, and the deployment history before running a single kubectl command.
- Understand the blast radius of their actions. They know that a kubectl delete in the wrong namespace is not a mistake, it is an incident.
- Communicate during incidents. Not after. During. They write what they see, what they are trying, and what they need, while the clock is running.
- Are honest about what they do not know. The most dangerous engineer in a production incident is the one who guesses quietly.
- Treat the cluster as a system, not a collection of resources. They understand that a ConfigMap change can break a deployment, that a PDB can prevent a node drain, that a NetworkPolicy that worked yesterday might not work today because the CNI was upgraded.
None of these are on the CKA exam.
The certification as a floor, not a ceiling
I am not anti-certification. I hold OCI Architect Associate, OCI DevOps Professional, and KCSA. I have seen the CKA open doors for engineers who would otherwise be filtered out by keyword-based screening. In a market where everyone claims Kubernetes experience, a certification is proof that someone at least sat down and tried.
But it is a floor. It is the minimum evidence that you have touched the tool. It is not evidence that you can operate it under pressure, at scale, or in a system where the failure is not scoped to a task.
The engineers who pass the CKA and then spend six months running a real cluster, breaking it, fixing it, and breaking it again in a different way, those are the engineers I want on call. The certification gave them the vocabulary. The production time gave them the judgment.
What this means for hiring
If you are hiring DevOps engineers and filtering on certifications, you are filtering for effort, not for capability. That is not nothing, effort matters, but it will not tell you whether the person can keep their head when the cluster is down and the phone is ringing.
Ask them about a production incident they were part of. Ask them what they did first. Ask them what they wish they had done differently. Ask them how they would drain a node that has a PodDisruptionBudget preventing eviction. Ask them what happens to a Deployment with three replicas when the node it is running on goes NotReady and the cluster autoscaler is enabled.
If they can talk through those scenarios, the certification does not matter. If they cannot, the certification did not do its job.
The honest path
If you are studying for the CKA right now, good. Take the exam. Pass it. Put it on your LinkedIn. Then go find a cluster that real users depend on and offer to help operate it. Break things in staging. Fix them. Write about what broke and why. Build the muscle that no exam can test: the ability to hold a complex system in your head while it is actively failing and make decisions that reduce the blast radius instead of expanding it.
That is the skill clients pay for. That is the skill that keeps systems quiet. And it is not on any exam.